Why does current/shell directory change depending whether drive-letter is used in filename?

Question

Using VIM (v6.3) from a command-prompt (i.e. not gVIM) I'm getting different behaviour for the :shell command depending on whether I specify a drive-letter when editing a file or not.

Without Driver Letter

X:\>vi Directory\File.txt

(file opens; use :sh to open a command-prompt)

Microsoft Windows [Version 10.0.17763.379]
(c) 2018 Microsoft Corporation. All rights reserved.

X:\>

With Driver Letter

X:\>vi X:\Directory\File.txt

(file opens; use :sh to open a command-prompt)

Microsoft Windows [Version 10.0.17763.379]
(c) 2018 Microsoft Corporation. All rights reserved.

X:\Directory>

In both cases, I'm editing the same file (X:\Directory\File.txt), from the same location (X:) but if I don't specify the drive-letter I'm left in the original directory (what I want) whereas if I do specify the driver letter I'm left in the directory containing the file being edited.

Does anyone know (a) why this is happening, and (b) how to stop it? Ideally I'd like to be left in X:\ in both the above cases. Tested on both Windows 7 and Windows 10.

---

This also seems to affect the expansion of % ("the current filename") when executing a shell command. When the drive-letter is given, and the shell opens in the directory containing the file being edited, % expands to just the name of the file (File.txt). Without the driver-letter, % expands to the path as entered when starting VI (Directory\File.txt). However, I can handle this by using %:p which in both cases expands to the full drive/path/name (Directory\File.txt).

Answer 1

I can't say why it happens - I've reproduced the behaviour and it is strange indeed - but here is a work-around I found:

vi -c "cd %CD%" X:\Directory\File.txt

With -c, vi will execute the cd command as soon as it opens, taking you back to the working directory you launched vi from.

Caveat: when I'm at C:\ (rather than c:\some-other-dir), I get an error message as vi starts, but the working directory is set correctly despite that error message.