Describe the bug
When gh is installed via the snap package, users cannot specify an alternative editor at the path where said editor is normally found.
For example, let's use vim as gh's editor.
It doesn't matter whether we specify the editor in an environment variable:
Or using gh config commands:
Or even specifying the editor by its full path:
gh config set editor /usr/bin/vim
The end result is the same: we receive an error indicating that the executable could not be found.
The reason for this seems to be the manner in which snap isolates packages; by default, the gh package only has permissions to access files in the user's home folder and desktop, so an executable like vim would not be accessible. I'm not sure why nano doesn't cause similar problems.
Steps to reproduce the behavior
- Install the
gh snap
- Set the editor to something like vim:
gh config set editor vim
- Try creating and editing an issue:
gh issue create
- Notice the error
Expected vs actual behavior
Expected behavior: user can use non-default editor
Actual behavior: user cannot specify a non-default editor installed outside of user's home directory/desktop
Logs
$ gh config set editor vim
$ gh issue create
Creating issue in casperdcl/cli
? Title asdf
? Body [(e) to launch vim, enter to skip]
X operation failed. To restore: gh issue create --recover /tmp/gh135054005.json
exec: "vim": executable file not found in $PATH
Describe the bug
When
ghis installed via the snap package, users cannot specify an alternative editor at the path where said editor is normally found.For example, let's use
vimasgh's editor.It doesn't matter whether we specify the editor in an environment variable:
export EDITOR=vimOr using
ghconfig commands:gh config set editor vimOr even specifying the editor by its full path:
gh config set editor /usr/bin/vimThe end result is the same: we receive an error indicating that the executable could not be found.
The reason for this seems to be the manner in which snap isolates packages; by default, the
ghpackage only has permissions to access files in the user's home folder and desktop, so an executable likevimwould not be accessible. I'm not sure whynanodoesn't cause similar problems.Steps to reproduce the behavior
ghsnapgh config set editor vimgh issue createExpected vs actual behavior
Expected behavior: user can use non-default editor
Actual behavior: user cannot specify a non-default editor installed outside of user's home directory/desktop
Logs