Bug with shell command !{cmd} using cmd.exe

[Chainsaw]

Hello,

I just switched from Windows 10 to Windows 11, and found a strange bug
with Vim in Windows 11.
Steps to reproduce:
1) execute command :!start c:\windows\system32\cmd.exe (or
:!c:\windows\system32\cmd.exe)
2) in the opened cmd.exe window, cd to a directory that contains a .cmd
or .bat file, example cd c:\batch\test
3) run a .cmd or .bat file, say test.cmd, you will get 'test.cmd' is not
recognized as an internal or external command, operable program or batch
file
4) then in same window, run c:\batch\test\test.cmd and it will work ok

This only happens with a cmd.exe window opened from Vim using !.

Thanks

[Jürgen Krämer]

Hi,

have a look at

:help $NoDefaultCurrentDirectoryInExePath

I don't know if there is a way to disable this behavior in Vim. You might
need to

set NoDefaultCurrentDirectoryInExePath=

or

set PATH=.;%PATH%

in your cmd or get into the habit of explicitly prepending ".\" to the
names of executables from the current directory when you want to run them,
e.g.,

.\my-program-from-here.exe param1 param2


Regards,
Jürgen

--
~
~
~
:wq

[Chainsaw]

> --
The PATH variable does not matter for an executable if you are in the
directory of the executable, or using the absolute path. When a command
is issued at the CMD prompt, the Operating System will first look for an
executable file in the current folder, if not found it will scan %PATH%
to find it. In a CMD prompt window not launched from Vim, even if you
null the path with 'PATH ;' or set "PATH=", any executable in the
current directory will be found.

This odd behavior is only from a CMD window launched from Vim, and in
Windwso 10 I did not have this problem, it just worked.
Anyway, you did give me an idea for a workaround.

This works:
!start c:\windows\system32\cmd.exe /k path \%path\%;.

I still would like to know why this happens in Windows 11 (I do consider
this a bug because I should not have to include current directory in
path).

Thanks

[Christian Brabandt]

On Do, 18 Dez 2025, Chainsaw wrote:

> The PATH variable does not matter for an executable if you are in the
> directory of the executable, or using the absolute path. When a command is
> issued at the CMD prompt, the Operating System will first look for an
> executable file in the current folder, if not found it will scan %PATH% to

Which is a huge security issue by itself. There is a reason why almost
no other shell behaves like this and even powershell did not inherit
this behavior. In fact MS introduced the
$NoDefaultCurrentDirectoryInExePath environment variable to enable
customers to disable this behaviour.

And Vim does set this environment variable since patch 9.1.1947 (see
https://github.com/vim/vim/security/advisories/GHSA-g77q-xrww-p834 for
the reasoning).

I'd recommend not to rely on that behavior (e.g. what happens if you
have a malicious dir.cmd in your current directory)?

In any case, I suppose you could disable this behavior by unsetting
$NoDefaultCurrentDirectoryInExePath from your environment, like:
set NoDefaultCurrentDirectoryInExePath=

> (I do consider this a bug because I should not have to include current
> directory in path).

Well, I don't :)

Thanks,
Chris
--
And in the heartbreak years that lie ahead,
Be true to yourself and the Grateful Dead.
-- Joan Baez

[Salman Halim]

> > The PATH variable does not matter for an executable if you are in
> > the directory of the executable, or using the absolute path. When a
> > command is issued at the CMD prompt, the Operating System will first
> > look for an executable file in the current folder, if not found it
> > will scan %PATH% to
>
> Which is a huge security issue by itself. There is a reason why
> almost no other shell behaves like this and even powershell
> did not inherit this behavior. In fact MS introduced the
> $NoDefaultCurrentDirectoryInExePath environment variable to enable
> customers to disable this behaviour.
>

> > (I do consider this a bug because I should not have to include
> > current directory in path).
>
> Well, I don't :)
>
> Thanks, Chris

For a bit of context, Windows/DOS had a lot of built-in commands, such
as the previously-mentioned 'dir' and 'copy', 'del', etc. On Linux/Unix,
on the other hand, almost everything is a separate executable ('ls',
'cp', 'rm', to name three equivalents). So, in Linux, as root, you could
go into a user's subdirectory to look around and type 'ls' to see the
contents. The user, if malicious, could have created a simple shell
script or other executable executable file named 'ls' that did something
nasty ('rm -rf /' comes to mind), and when you typed 'ls', it would run
that file instead and not the /bin/ls you were hoping for. Consequently,
it would be disastrous to have the CURRENT directory in the PATH (after
all, you're probably in another user's home because you have been given
some reason to look around).

Windows is basically catching up a bit. This is definitely not a bug,
it's a security feature, albeit one that breaks backward compatibility
for Windows users.

Salman

[Chainsaw]

> --
Chris,

Thanks for the info. Sorry for calling it a bug, it was the sudden
change in Vims behavior that threw me off. I download the updates daily
and do read the description of changes, but 9.1.1947 happened right at
the time I was swithing over to a new Windows 11 machine, which is why I
never saw this in Win10, and accociated it with a Vim Win11 problem.
Guess I spoke too soon.

I do like the option to set NoDefaultCurrentDirectoryInExePath, however
a malicious executable could also be anywhere in your PATH, and so many
programs/scripts rely on the OS to search the current directory first.
This is one of those 'fixes' that has pros and cons.

Thanks again for everyones help, and thank you Chris and your team for
keeping Vim alive.

Chainsaw