Error: spawn phpcs ENOENT


#1

Just getting started with Atom and PHP and I’m getting this error every time I try to create/edit a .php document.

I have atom-autocomplete-php and Composer installed; when I setup Composer I got a message in Atom saying that it was installed correctly.

Any tips on how to resolve this?
Cheers,


#2

Does the error happen when you disable the Composer package?


#3

No, believe it or not, the errors ceased when I disabled linter-phpcs.

After posting, I disabled linter-phpcs and linter and tried to install phpcs again via ‘Homebrew’ following the tutorial by Jason Resnick -
https://rezzz.com/php-codesniffer-with-wordpress-coding-standards-and-atom/.

I’m new to Terminal andwas tracking along ok, but got stuck with filepaths, trying to link the ‘Wordpress Coding Standards’ ruleset to PHP Codesniffer. I used the wrong path and screwed it up. Despite uninstalling Homebrew and CS I’ve been unable to re-install either (keep getting errors).

Not sure what to try next to even return to the ‘baseline’ I had before opening Terminal.


#4

What errors? Did you uninstall Homebrew according to the instructions? Why did you uninstall Homebrew?

Not sure what to try next to even return to the ‘baseline’ I had before opening Terminal.

If you’re working with the command line, you either have to back things up ahead of time or keep a record of exactly what you do if you think that you might want to undo it.


#5

Yeah, got that; installing multiple “packages” and not fully understanding any of them, or the Terminal was a recipe for pain I could have done without. I just started to learn PHP this week and the concept of CodeSniffer/Atom and WP Coding Standards seems like a no-brainer for a newbie; but getting it all setup hasn’t been newbie friendly.

I really would like to get this going, so if you can see where I went wrong and have any suggestions, fantastic. Otherwise I’ll just run with Atom as is until my knowledge catches up.

Cheers, Paul


#6

This is the issue. You should have stopped right here and asked someone what that error meant. At the very least, you should have kept the Terminal output so that you could show it to someone.

From what you’ve said, it sounds like you told phpcs to look for a /wpcs directory, which means that it would be looking in the root of your filesystem (/), not wherever the WPCS repo was. The solution at this point was probably just to run phpcs --config-set again with the correct path.

I tried the process again from Step 3, but got an error- “wpcs is not an empty directory”.

With the git repo cloned successfully, that step is done. You wouldn’t have to repeat it unless you messed up that directory somehow.

At this point I didn’t know how to move forward or to undo what had been done, so the default was to abort and uninstall everything.

You responded rashly. Coming to here or any forum with users with a decent amount of Unix knowledge could have solved your problem very quickly. You most certainly didn’t need to uninstall Homebrew or delete the WPCS repo.

I just started to learn PHP this week and the concept of CodeSniffer/Atom and WP Coding Standards seems like a no-brainer for a newbie; but getting it all setup hasn’t been newbie friendly.

It’s not any of those packages that you’re getting hung up on. It appears to be just your understanding of Unix, and specifically Unix paths. Resnick’s instructions are pretty straightforward, but they assume that the user has a knowledge of where all of their files are.

What errors are you getting when you try to reinstall Homebrew? Have you deleted the WPCS repo? If not, where is it?


#7

Thanks for that, yes Unix is not something I’ve ever needed to work with directly, so I was ‘flying blind’. I’ll take another look at getting it going over the weekend, when I have a little more time.

Appreciate the assistance.


#8

I had another go at getting this setup this morning but I’m still having difficulties with file paths.

From scratch -

  1. I reinstalled Homebrew -
    /usr/bin/ruby -e “$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/master/install)”

  2. I reinstalled PHP CodeSniffer -
    brew install homebrew/php/php-code-sniffer

  3. I reinstalled the WP Coding Standards -
    git clone -b master https://github.com/WordPress-Coding-Standards/WordPress-Coding-Standards.git wpcs

  4. I ran phpcs -i and got the following back -
    The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz and Zend

  5. I tried to link the ruleset to PHP CodeSniffer by running -
    phpcs --config-set installed_paths Users/paulcarter/wpcs

a) I got this back -
Config value “installed_paths” updated successfully; old value was “/usr/local/etc/php-code-sniffer/Standards”

  1. I ran phpcs -i again and got the errors again -
PHP Fatal error:  Uncaught UnexpectedValueException: DirectoryIterator::__construct(Users/paulcarter/wpcs): failed to open dir: No such file or directory in /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer.php:2213
Stack trace:

#0 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer.php(2213): DirectoryIterator->__construct('Users/paulcarte...')
#1 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(1312): PHP_CodeSniffer::getInstalledStandards()
#2 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(478): PHP_CodeSniffer_CLI->printInstalledStandards()
#3 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(450): PHP_CodeSniffer_CLI->processShortArgument('i', 0)
#4 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(388): PHP_CodeSniffer_CLI->setCommandLineValues(Array)
#5 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(825): PHP_CodeSniffer_CLI->getCommandLineValues()
#6 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(106): PHP_CodeSniffer_CLI->process()
#7 /usr in /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer.php on line 2213

Fatal error: Uncaught UnexpectedValueException: DirectoryIterator::__construct(Users/paulcarter/wpcs): failed to open dir: No such file or directory in /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer.php:2213
Stack trace:
#0 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer.php(2213): DirectoryIterator->__construct('Users/paulcarte...')
#1 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(1312): PHP_CodeSniffer::getInstalledStandards()
#2 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(478): PHP_CodeSniffer_CLI->printInstalledStandards()
#3 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(450): PHP_CodeSniffer_CLI->processShortArgument('i', 0)
#4 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(388): PHP_CodeSniffer_CLI->setCommandLineValues(Array)
#5 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(825): PHP_CodeSniffer_CLI->getCommandLineValues()
#6 /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer/CLI.php(106): PHP_CodeSniffer_CLI->process()
#7 /usr in /usr/local/Cellar/php-code-sniffer/2.6.1/CodeSniffer.php on line 2213
  1. Guessing that the file path is wrong again, I entered the following to get back to where I was -
    phpcs --config-set installed_paths /usr/local/etc/php-code-sniffer/Standards

a) I got back -
Config value “installed_paths” updated successfully; old value was “Users/paulcarter/wpcs”

b) I ran phpcs -i again, and got back -
The installed coding standards are MySource, PEAR, PHPCS, PSR1, PSR2, Squiz and Zend

c) So it looks like I’m back where I was, before trying to link the WP ruleset.

  1. Homebrew installed wpcs in Macbook SSD/Users/paulcarter so I’m not sure where I went wrong this time. Do I need to move wpcs somewhere else or is there something else I’m missing?

Apologies in advance for not ‘getting this’, it’s really embarrassing.

Paul


#9

Can you open a Terminal directly into a directory via the context menu? If so, navigate to where WPCS is installed and open the Terminal there, then type readlink -f .. That will give you the absolute path to that directory.


#10

By right clicking wpcs in Finder I can open Terminal in that folder -
Last login: Fri Jul 15 11:01:59 on ttys000
Macintosh:wpcs paulcarter$

When I type readlink -f . I get the following -
readlink: illegal option – f
usage: readlink [-n] [file …]
Macintosh:wpcs paulcarter$


#11

Oh, damn. Today I learned that readlink is part of GNU coreutils and not included in OS X. There’s a fix for that, which might be useful in other contexts if you plan to use the command line much.

Let’s go with a bash command, then. echo $PWD should work, unless OS X has some weird behavior concerning its environment variables.

I’m riding this train because “Users/” is not a Unix path format. It’s a desktop abstraction that’s more readable for you, but it’s not how command-line tools find files on your computer. System directories are virtually always lowercase, and directions on how to get to config files in other directories will start with either /, ../, or ~/. The config setting that phpcs wants is something that’s formatted similarly to /usr/local/etc/php-code-sniffer/Standards.


#12

That did the trick.

It was this comment that made me take a real close look at the path I’d entered earlier. I failed to start the path with (/)! How embarrassing!! The actual path is /Users/paulcarter/wpcs.

I followed the rest of Jason’s tutorial no problems, and now it seems to be working - PHP errors everywhere, even in WordPress core .php files, which seems odd??

I need to get on with learning PHP now, before I can understand what all the errors mean.

Thanks for all of your help with this, I couldn’t have got this going without it, and I learned a lot from going through the process.

Cheers,

Paul.


#13

I have not looked at the core Wordpress files in ages, and this is beyond the scope of this forum, but if you share some of them, I might be able to help you suss out what’s up. What I can say is that web technologies tend to be more lenient than other code languages on what you can get away with. Web servers and browsers have fairly simple jobs and also don’t generally deal directly with critical transactions (anyone processing credit cards with PHP needs to be quietly removed from a position where they have the potential to cause harm), so minor errors aren’t a big deal and the software can make a lot of best guesses about the author’s intent.

It’s odder that Wordpress’ code would run up against their own standards, but they may not have completely rewritten it since they published those standards. I’ve been out of the WP game for a while.

Thanks for all of your help with this, I couldn’t have got this going without it, and I learned a lot from going through the process.

No problem. I enjoy helping people and you haven’t been difficult to aid aside from an initial misunderstanding. Being able to roll back to the previous point where things worked and set your frustration on a shelf in order to think through the problem again is an important skill.

I’d suggest also doodling around with the command line a bit. Back up some projects on GitHub (also great for sharing your code to get help); browse for fun-looking packages from Homebrew, NPM, Ruby, etc.; learn a bit about what bash does and customize your prompt (there are tools to help even the rawest newbie get started) so that it’s not as stark as it comes out of the box (it’s much more fun learning when the terminal window is something you feel comfortable in). iTerm2 would be a substantial livability improvement over the stock Terminal app. Before long, you’ll find yourself fluent in man and probably find that there are some tasks that are best performed as a series of “verbal” instructions (because they’re too tedious to perform within a desktop metaphor).