-
Notifications
You must be signed in to change notification settings - Fork 359
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
Quote all the paths to OPAMROOT when creating the init scripts on Unix #5841
Conversation
505b01f
to
c0521ea
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The code changes are good for me!
It would be better to have in the shell files unix-like paths (transformed via cygpath) instead of windows ones, even if it is understandable by cygwin.
ab0714c
to
5043433
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated accordingly, it then needs another review :)
Why did you remove the calls to |
There is no need to escape them for printing, as cygpath will output the path with slashes. And cygpath function don't need to have a single escaped input. |
what happens on unix though? (when cygpath is not present) |
tested on cygwin shell
reminds me of #5036, that tried to add init scripts tests |
|
in that case this is a problem and |
Oh, i didn't see that it was an addition for the quoting. Yes, it is needed! |
5043433
to
0b380f5
Compare
Updated |
0b380f5
to
e353c49
Compare
Co-authored-by: Kate <kit-ty-kate@outlook.com>
e353c49
to
3b8e0ce
Compare
thanks! |
Bench tests failing as service was on available. |
Fixes #5804
I personally think keeping the Windows style paths on Windows when using cygwin shell is fine, however none of the paths were previously quoted which is a big issue and the reason why the user in #5804 looked in the file in the first place as such command will always fail on Windows.
On cmd and powershell double quoting is apparently enough to make sure the string can't escape its context (?) (e.g.
"
and$
are not valid file characters)