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
When ever a commit message of some sort is required, sqitch will attempt to spawn an editor if the user hasn't already provided his commit message on the command line:
$ sqitch tag v0.0.1
"emacsclient -t" failed to start: "No such file or directory"
Sqitch seems to attempt to spawn the editor the user configured in his environment, which is great.
However, it also appears to attempt to do so by a plain exec, which is problematic in two ways:
$ echo $EDITOR
emacsclient -t
It won't do what you expect if $EDITOR contains more than just the name of an executable, such as an editor invocation that provides arguments to the editor
$ which emacsclient
emacsclient: aliased to TERM=xterm-256color emacsclient
And it won't resolve possible aliases configured in the user's shell either.
It'd be great if opening a visual editor would be performed through a shell rather than by a simple exec.
The text was updated successfully, but these errors were encountered:
Hrm. The two places that currently run the editor both do so like this:
$sqitch->run( $sqitch->editor, $file );
The run method uses IPC::System::Simple::runx. Maybe there should be a separate method for running things specified in the environment? I'm not sure. This will also be an issue for running other command-line clients (like psql).
When ever a commit message of some sort is required, sqitch will attempt to spawn an editor if the user hasn't already provided his commit message on the command line:
Sqitch seems to attempt to spawn the editor the user configured in his environment, which is great.
However, it also appears to attempt to do so by a plain exec, which is problematic in two ways:
It won't do what you expect if $EDITOR contains more than just the name of an executable, such as an editor invocation that provides arguments to the editor
And it won't resolve possible aliases configured in the user's shell either.
It'd be great if opening a visual editor would be performed through a shell rather than by a simple exec.
The text was updated successfully, but these errors were encountered: