Snap Package Cannot Access Editor Executables

[Harris Lummis]

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:

export EDITOR=vim

Or using gh config commands:

gh config set editor vim

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

1. Install the gh snap
2. Set the editor to something like vim: gh config set editor vim
3. Try creating and editing an issue: gh issue create
4. 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

[Casper da Costa-Luis]

I think the only way around this would be to request classic confinement for the snap /cc @popey

[Harris Lummis]

@casperdcl It might also be possible to do this without reverting to classic confinement by creating a "system-files" plug and either...

1. Allow read access to a few specific common editors (e.g. vi, vim).
2. Allow read and write access to some directory like /etc/gh-snap/ where a user can create symlinks to editors that they might use.

I haven't tried either of these solutions but it's worth a shot. Not sure of the best way to go about testing this though.