Absolute path on Windows changes working dir

[Ben Fritz]

This bit me while getting my TOhtml tests working on Windows with a Visual Studio build environment. I'm not sure if it's a bug or not, but I can't find any description of it in the help and it isn't acting as I'd expect. Vim seems to change path to the directory containing a file, if it is passed the absolute path WITH DRIVE LETTER to a file. I expect Vim to keep its working directory the same as the directory it was launched from, unless 'autochdir' is set or the directory is changed manually or with an autocmd. I expect that using "-u NONE" should avoid any automatic methods.

C:\Users\me\path\to\vim-src> .\vim.exe -u NONE rel\path\to\file.txt

:pwd

C:\Users\me\path\to\vim-src

C:\Users\me\path\to\vim-src> .\vim.exe -u NONE C:\Users\me\path\to\vim-src\rel\path\to\file.txt

:pwd

C:\Users\me\path\to\vim-src\path\to

Interestingly:

C:\Users\me\path\to\vim-src> .\vim.exe -u NONE \Users\me\path\to\vim-src\rel\path\to\file.txt

:pwd

C:\Users\me\path\to\vim-src

Right now, I can't easily compile any Windows Vim version prior to the introduction of Visual Studio 2022 support in v9.0.0528. The same behavior occurs in that version.

I downloaded zip file releases from https://github.com/vim/vim-win32-installer/ for the following older versions which also exhibit the same behavior, so it has been around for a long time:

 - 8.0.0003

 - 7.4.1185 (the oldest tag available which has prebuilt binaries)

[Enan Ajmain]

On Mon, 4 Sep 2023 20:16:09 -0700 (PDT)
Ben Fritz <fritzo...@gmail.com> wrote:
> This bit me while getting my TOhtml tests working on Windows with a Visual
> Studio build environment. I'm not sure if it's a bug or not, but I can't
> find any description of it in the help and it isn't acting as I'd expect.
> Vim seems to change path to the directory containing a file, if it is
> passed the absolute path WITH DRIVE LETTER to a file. I expect Vim to keep
> its working directory the same as the directory it was launched from,
> unless 'autochdir' is set or the directory is changed manually or with an
> autocmd. I expect that using "-u NONE" should avoid any automatic methods.
>
> C:\Users\me\path\to\vim-src> .\vim.exe -u NONE rel\path\to\file.txt
> :pwd
> C:\Users\me\path\to\vim-src
>
> C:\Users\me\path\to\vim-src> .\vim.exe -u NONE
> C:\Users\me\path\to\vim-src\rel\path\to\file.txt
> :pwd
> C:\Users\me\path\to\vim-src\path\to

I assume "C:\path\to\file.txt" was a commandline argument to Vim. If
true, then that is a weird but documented behaviour.

See ":h win32-curdir":
> If Vim is started with a single file name argument, and it has a full path
> (starts with "x:\"), Vim assumes it was started from the file explorer and
> will set the current directory to where that file is. To avoid this when
> typing a command to start Vim, use a forward slash instead of a backslash.
> Example:
>
> vim c:\text\files\foo.txt
>
> Will change to the "C:\text\files" directory.
>
> vim c:/text\files\foo.txt
>
> Will use the current directory.

[Ben Fritz]

Perfect, thanks! I was poring over :help startup and :help vim-arguments
without finding anything at all. I think I might do some experimenting
to find where in the startup sequence that path is set, it might be
relevant for some plugins or autocmd debugging. Probably it's worth a
mention or a link in one of those two places!

I figured it has been around long enough it was probably intentional but
was confused not to find any mention of it.