CLI tools don't preserve v:progname, v:progpath

[lilyball]

Describe the bug Vim exposes the name of the binary that was executed in the v:progname variable. Unfortunately, invoking the various vim CLI tools installed by MacVim always reports v:progname as being Vim. This is because they're all symlinks of the embedded mvim script, which ultimately invokes

exec "$binary" $opts …

In particular, it's not providing the -a flag, so the binary is always invoked with the executable name of Vim.

The same issue also affects v:progpath (for obvious reasons), wherein it always points to the absolute path to the MacVim.app/Contents/MacOS/Vim binary.

This is an issue because v:progname and v:progpath are potentially useful to use in my vimrc to customize based on what binary I used to invoke it.

Replacing this with exec -a "$0" "$binary" … should solve the problem.

On a related note, launching MacVim from the Finder also sets v:progname to Vim. I can't decide if this matters.

To Reproduce Detailed steps to reproduce the behavior:

1. Run ex
2. Type echo v:progname or echo v:progpath

Expected behavior It should print "ex" as the progname and either "ex" or the absolute path to ex as the progpath.

Observed behavior It always prints Vim as the progname and the absolute path to MacVim.app/Contents/MacOS/Vim as the progpath.

Environment (please complete the following information):

• Vim version 8.2.1719
• OS: macOS 11.2.3 (20D91)
• Terminal: Apple Terminal.app or GUI

[lilyball]

Experimenting right now with the proposed exec -a solution, this actually seems to fail in a few cases:

• If I pass exec -a gvim, Vim exits instantly (unless I pass -f as well). exec -a gvim ./Vim -g also exits instantly. exec ./Vim -g works (as this is what the mvim script is doing), so something is rather broken with its handling of the gvim name.
• The -g flag is broken with other arbitrary names too, e.g. exec -a foo ./Vim -g does nothing, though it works (and preserves the progname) when used without the -g flag, unless of course the name starts with "g". For example, exec -a gfoo ./Vim -g fails (as does the version without -g).

It looks like the gvim issue could be worked around with an explicit fork+disown, something like ( exec -a "$0" "$binary" --nofork ) & disown. This should only be done for jobs with $gui set of course. And the logic that clears $gui when SSH_COMMAND is set will want to reset the binary name too (it could try to trim any leading "g"s from the front, after skipping a single leading "r", this way e.g. gview will still be interpreted as view)

Unfortunately we still need to peek at the binary name to set flags, as all of this fails if the Vim binary itself is replaced with a shell script (which is what happens in the Nix package when using the vim configuration feature, as we need to pass a custom vimrc). This is because bash seems to ignore argv[0] when passed a filename.

[lilyball]

Another wrinkle: Spawning several vim processes with the --nofork + disown combo all produces windows in the same MacVim GUI process, but spawning a process without this (e.g. invoking mvim) produces a separate GUI process. This is strange.

[ychin]

Huh, seems like this requires some thought since as you pointed out it's not that easy to pass it in. It does feel like it should be fixed. Let me think about it a little bit (feel free to keep experimenting).

That said, I'm just curious by how come you need to access v:progname? Are you trying to tell if you are launching from e.g. view or vim?

[lilyball]

I was actually experimenting to see if I could figure out how to detect ex -s, as I'm replicating the normal initialization routine in a custom vimrc provided with -u. v:progname is not actually helpful here, as it doesn't tell me about the -s flag or tell me if I used vim -e, but it's theoretically useful if I want to detect view. I'm also pondering the idea of making a new alias that I detect in my vimrc to disable a bunch of stuff, e.g. for a faster-launching more minimal setup.

[lilyball]

@ichizok c143fa0778fa0d8744867318bb7f7a2e63cf37d7 appears to be unrelated, I think perhaps it referenced the wrong issue number?

[ichizok]

Oh... the issue number in upstream vim matches this.

[eirnym]

I detect in my vimrc to disable a bunch of stuff, e.g. for a faster-launching more minimal setup.

hm, nice! However I personally usually never use these aliases even with normal vim in other OSes.

I usually did this with VimPlug by adding { 'on': 'TableModeEnable' } or { 'for': 'python' } to a plugin definition to not enable a plugin before I really need it. Thus most plugins are off when I edit a new empty buffer