-
-
Notifications
You must be signed in to change notification settings - Fork 379
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Engines do not honor system paths on Linux #695
Comments
Thanks for the investigation! You're right about the commit that caused this, but unfortunately, it is needed to make relative paths work on the portable version. I'm not sure how to resolve this properly... |
The problem apparently is that
Indeed "ssh" works if I execute Sabaki from "/usr/bin". Maybe it's possible to use the "shell" spawn option (in conjunction with the already apparent "cwd") [2]. This should pass all name resolution duties over to the shell. [1] https://nodejs.org/api/path.html#path_path_resolve_paths |
This won't really solve the problem. In the portable version, if we don't have an explicit filename resolution, relative paths to engines don't work (relative to Sabaki path). |
One idea is to use the absolute path of a given executable file if it exists, and to use the relative path if the absolute path does not exist. |
Sounds sensible; the only problem I see is that the file extension can't be omitted for relative paths, but that is probably just a minor detail and only affects Windows. |
Another idea is to call spawn in the relative path, and if it fails, call spawn again in the absolute path. But we need to write a little dirty code related 'spawn' to determine that an error occurred due to a specification problem. I think a simpler way would be better, and if the path is relative, it's the specification that even the extension has to be matched. I've written the code. Can I PR it? |
Sounds good, please do 😊 |
I use ssh to run my engines remotely on a more powerful machine.
For v0.43.3 and v0.50.0 I used "ssh" as my engine, works fine.
For v0.51.1 "ssh" doesn't work anymore, "/usr/bin/ssh" has to be specified.
Basically this is the same problem as pointed out in issue 117.
Sabaki version: v0.51.1
OS: Linux (SparkyLinux based on Debian testing branch, Kernel 5.6.0)
I think the issue has been introduced in this commit.
The text was updated successfully, but these errors were encountered: