v:progname and fnamemodify(v:progpath, ':t') differ

[Konfekt]

Steps to reproduce

1. xterm (or any other terminal)
2. /usr/bin/vim --clean -u NONE
3. :echo v:progpath

Expected behaviour

output is /usr/bin/gvim, expected is /usr/bin/vim.
v:progname shows vim.

Version of Vim

9.1.151

Environment

Opensuse 15.5, $TERM=xterm-256color, shell = zsh

Logs and stack traces

No response

[zeertzjq]

According to :h v:progpath:

		If the command has a relative path it will be expanded to the
		full path, so that it still works after `:cd`. Thus starting
		"./vim" results in "/home/user/path/to/vim/src/vim".
		On Linux and other systems it will always be the full path.

"The full path" usually means resolving symlinks, so this is working as intended.

[Konfekt]

Thank you, indeed a chain of symlinks resolves to gvim, so this latter part works as indeed. This issue refers to the start of :h v:progpath that says

v:progpath	Contains the command with which Vim was invoked, in a form
		that when passed to the shell will run the same Vim executable
		as the current one (if $PATH remains unchanged).

The command with which Vim was invoked was not /usr/bin/gvim, but rather /usr/bin/vim.
Also /usr/bin/gvim opens a new window and does not stay in the terminal, as does /usr/bin/vim, the path of v:progname.
(The instance opened by /usr/bin/gvim has gvim as v:progname, so they ought to differ?)

[chrisbra]

I guess that is a consequence of resolving the symlinks

[Konfekt]

I wonder why $(realpath /usr/bin/vim) and /usr/bin/vim start different programs. If the documentation said

v:progpath	Contains the real path of the command which Vim was invoked

than at least v:progpath would deliver as documented

[zeertzjq]

There is also the -v argument:

							*-v*
-v		Start Ex in Vi mode.  Only makes a difference when the
		executable is called "ex" or "gvim".  For gvim the GUI is not
		started if possible.

[chrisbra]

$(realpath /usr/bin/vim)

This one makes the shell expand the complete path. The problem is, If you use e.g. view or vimdiff. I think Vim wouldn't behave as being started in read-only or diff mode, since it only knows it has been started as vim (For me it would be vim.nox)

/usr/bin/vim

Here Vim knows as what command is has been called and can behave differently.

I think, at least this would make a difference.

[Konfekt]

For the user, how about adding some caveat around

when passed to the shell will run the same Vim executable as the current one

that starting an instance of vim similar to the one the user is looking at is rather achieved by exepath(v:progname) since Vim seems to look at v:progname to determine its behavior.
This difference matters when launching Vim from a terminal inside Vim, where instead of opening a file in the same instance, v:progpath spawns a new Gvim

[zeertzjq]

v:progname may not actually be the name of an executable. For example, if Vim is run with exec -a foo vim --clean in Bash, the value of v:progname is foo.

[Konfekt]

Well, neither solution works in general, but symlinked vim executables are perhaps more common than running it by exec -a foo

[Konfekt]

One could propose these workarounds with their respective shortcomings