You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I recently tried to set OPAMEDITOR to something that contains spaces (that was on Windows, "Program Files" was part of the path). This failed because the first "word" was interpreted as a command and the rest as arguments.
This can be worked around by quoting the path (inside the variable). Here's an example on linux:
$ ln -s $(which vim)~/'v i m'
$ OPAMEDITOR="/home/etienne/v i m" opam pin add testpkg -
Package testpkg does not exist, create as a NEW package? [Y/n] y
[NOTE] No package definition found for testpkg.~dev: please complete the
template
Press enter to start "/home/etienne/v i m" (this can be customised by setting EDITOR or OPAMEDITOR)...
sh: 1: /home/etienne/v: not found
$ OPAMEDITOR="'/home/etienne/v i m'" opam pin add testpkg -
Package testpkg does not exist, create as a NEW package? [Y/n] y
[NOTE] No package definition found for testpkg.~dev: please complete the
template
Press enter to start "'/home/etienne/v i m'" (this can be customised by setting EDITOR or OPAMEDITOR)...
... vim starts...
I agree that this is the expected behaviour because it's consistent with how git uses EDITOR - in particular it allows passing arguments to the command. Just a note (or a pointer) in the doc for this variable would be useful to users trying to use spaces in the command I think.
Thanks!
The text was updated successfully, but these errors were encountered:
Actually, weird though it is, it would be better if opam followed the Windows convention here which is documented in MSDN.
For example:
set EDITOR=C:\Program Files\vim82\vim -y
the "correct" way is to try C:\Program, then C:\Program Files, then C:\Program Files\vim82\vim and, upon finding that C:\Program Files\vim82\vim is a program, run it.
That behaviour should probably be Windows-specific!
Hi,
I recently tried to set
OPAMEDITOR
to something that contains spaces (that was on Windows, "Program Files" was part of the path). This failed because the first "word" was interpreted as a command and the rest as arguments.This can be worked around by quoting the path (inside the variable). Here's an example on linux:
I agree that this is the expected behaviour because it's consistent with how
git
usesEDITOR
- in particular it allows passing arguments to the command. Just a note (or a pointer) in the doc for this variable would be useful to users trying to use spaces in the command I think.Thanks!
The text was updated successfully, but these errors were encountered: