Unable to Save Files Due to spawn cppcheck ENOENT Error


I’m getting a strange error message while trying to save c++ files I’ve been working on:

Error: spawn cppcheck ENOENT
at exports._errnoException (util.js:856:11)
at Process.ChildProcess._handle.onexit (internal/child_process.js:178:32)
at onErrorNT (internal/child_process.js:344:16)
at doNTCallback2 (node.js:465:9)
at process._tickCallback (node.js:379:17)

This message only recently began cropping up today after I was attempting to ‘fix’ the atom-linter package, which was presenting erroneous error messages regarding missing standard c++ libraries (I believed these messages were in error because of my ability to compile and run c++ programs manually from windows terminal via g++. Errors were presented by lines like #include < string > and #include < iostream > in a basic cpp file). Having tried uninstalling linter, which occurred unsuccessfully, I subsequently resigned myself to simply coding in atom, ignoring the frustrating error messages, and compiling/debugging using the terminal exclusively. Unfortunately, for reasons I don’t understand, I now cannot save my files in atom at all. Any advice would be appreciated, thanks in advance for helping me out of this rabbit hole.


Does this behavior occur when you completely close Atom and reopen it with atom --safe?

If Atom is giving you errors around uninstalling a package, you can always delete the package folder from your .atom/packages directory.


Uninstalling atom and reinstalling (after following your advice regarding packages) seems to have solved the issue. Unfortunately, I’m doing a project with arduino which relies on the platformio package which in turn relies on the linter package to function. Looks like I’ll be dealing with odd errors, unless you have some idea as to how to address these as well?


Why did you resort to an extreme action (removing Atom completely) as your first course of action? I can’t have an idea of how to fix the errors if you aren’t going to take incremental steps and report back on what changes.

So, for clarity, you’re now at a point where the linter package is complaining about missing C++ libraries and that’s the only error you see?


My apologies, its been a long day and I failed to explain that I opted first to try your advice. As per your suggestion I deleted the linter package folder in .atom/packages as well as a number of linter-related extensions. However, upon restarting atom, I discovered that (apparently) platformio re-installs/checks the installation of all components necessary for its functionality upon atom launch. I then tried deleting all linter related packages and platformio. After restarting atom and noting that linter/platformio remained inactive/uninstalled, I went back to platformio’s website and reinstalled the package. Unfortunately, a number of residual platformio files apparently remained after my uninstall attempt as platformio failed to launch/install after re-installation. I then decided to reinstall atom to achieve a clean slate.

So after all that, yes, I’m back to square one with linter complaining about missing/unavailable string/iostream c++ libraries. However, as noted previously, compiling with g++ works just fine and produces a functional .exe file. Linter does, however, recognize string.h though I’ve been made aware that that’s a c header file and thus irrelevant to this issue.


Okay, so it’s almost certainly the linter-gcc package that’s at fault. It’s probable that your g++ installation is in a different location than linter-gcc expects it to be. You should go to the Packages pane and search for linter-gcc, then click on the package and you’ll get to its config pane.


After doing some research I found a guide for windows set up of linter-gcc. I followed the setup requirements to the t and am still getting errors on my ‘includes.’ Any suggestions? My GCC Executable Path is set to g++.exe and I’ve changed my path to include C:\MinGW\bin as the final entry (https://github.com/hebaishi/linter-gcc/wiki/Windows-Users-Guide).


Only one. Shut down Atom completely and restart it from the command line. It might not have picked up on the changed environment variables.


Unfortunately no luck, I’d tried that as well and just gave it another go for good measure. Thanks for your help, I have requests out on a couple of similar issues people have written about on the developer’s GitHub page. Hopefully they can help me sort it out.