On windows, using something like "vendor/bin/phpcs" does not work because the code tries to run "where vendor/bin/phpcs" which fails badly. So instead, when we try to test for a binary on windows, we first check if a file exists locally with that name. If it does, just use that. If someone has a file in their project with the same name as a linter, but that is not the actual linter, this could fail, but I can't imagine a case where that would happen.
Details
- Reviewers
epriestley - Group Reviewers
Blessed Reviewers - Commits
- rPHU6c3160d2b6f0: Fixing so that on windows local paths to binaries can be used
On windows, run arc lint with a linter configured that is local e.g. "vendor/bin/phpcs"
Diff Detail
- Repository
- rPHU libphutil
- Branch
- local-lint-bin
- Lint
Lint Skipped - Unit
Tests Skipped - Build Status
Buildable 1035 Build 1035: [Placeholder Plan] Wait for 30 Seconds
Event Timeline
I'm pretty sure the unit tests failed because I'm on windows. The change itself is fairly simple and shouldn't have affected them, but I don't have a system to easily test the unit tests on that isn't windows.
Sorry, thought of one more issue.
src/filesystem/Filesystem.php | ||
---|---|---|
915 | Oh, sorry -- this should also probably have an is_executable() check, too. |
src/filesystem/Filesystem.php | ||
---|---|---|
915 | That sounds totally reasonable, but when I add that it stops working. Not sure why... $path is string(26) "F:\Work\TestRepo\bin\phpcs" is_executable($path) is bool(false) Maybe it's because I'm in a MinGW environment? the phpcs file is a shell script, so maybe windows or php doesn't understand that it's executable. |
Is that actual file an executable, or is it something like a symlink?
Maybe it needs, like: is_executable($path) || (is_link($path) && is_executable(readlink($path)))?
It's not a symlink. It's a bash file.
$ cat bin/phpcs #!/usr/bin/env sh SRC_DIR="`pwd`" cd "`dirname "$0"`" cd "../vendor/squizlabs/php_codesniffer/scripts" BIN_TARGET="`pwd`/phpcs" cd "$SRC_DIR" "$BIN_TARGET" "$@"
Oh, gross. Okay, let's go with this for now and we'll see if it's a problem.
We could also try running which unconditionally (which should work in Unix-like Windows shells) and then fall back to where only if it's not available.
Thanks!
Oh, although to figure out if we can run which or not we'd have to start by running which which.
Anyway, hopefully this is good enough in all real scenarios.