4 ms·

> drive letters are essentially just a convention borne out of the conversion of a Win32 path into a NT path CMD also has the concept of a current drive, and o

by layer8 11mo ago

> drive letters are essentially just a convention borne out of the conversion of a Win32 path into a NT path CMD also has the concept of a current drive, and of a per-drive current directory. (While “X:\” references the root directory of drive X, “X:” references whatever the current directory of drive X is. And the current directory, i.e. “.”, is the current directory of the current drive.) I wonder how those mesh with non-standard drive letters.

squeek502 11mo ago
They work just fine, as the drive-specific CWD is stored in the environment as a normally-hidden =<drive-letter>: environment variable which has all the same WTF-16 and case-insensitive properties as drive letters: C:\> cd /D λ:\ λ:\> cd bar λ:\bar> cd /D C:\ C:\> echo %=Λ:% λ:\bar C:\> cd /D Λ: λ:\bar>
- o11c 11mo ago
  Hm, what about using `%` itself?
  - squeek502 11mo ago
    That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try. And indeed, it looks like using `=` as a drive letter breaks things in an interesting way: =:\> cd bar Not enough memory resources are available to process this command. =:\bar> `cd` exits with error code 1, but the directory change still goes through. With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way: Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo): =C:=C:\foo After `cd /D =:\`, that was unexpectedly modified to: =C:==:\ Funnily enough, that line means that the "working directory" of the C drive is `=:\`, and that actually is acted upon: =:\foo> cd /D C: =:\> --- You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331 https://github.com/ziglang/zig/issues/23331

by layer8 11mo ago

squeek502 11mo ago

They work just fine, as the drive-specific CWD is stored in the environment as a normally-hidden =<drive-letter>: environment variable which has all the same WTF-16 and case-insensitive properties as drive letters: C:\> cd /D λ:\ λ:\> cd bar λ:\bar> cd /D C:\ C:\> echo %=Λ:% λ:\bar C:\> cd /D Λ: λ:\bar>

o11c 11mo ago
Hm, what about using `%` itself?
- squeek502 11mo ago
  That would only interact with the shell, as `%` is not actually part of the environment variable name, it's just a way to tell the shell you want it to get the value of an environment variable. The environment block itself is a NULL terminated list of NULL terminated WTF-16 strings of the format <key>=<value>, so `=` would be the more interesting thing to try. And indeed, it looks like using `=` as a drive letter breaks things in an interesting way: =:\> cd bar Not enough memory resources are available to process this command. =:\bar> `cd` exits with error code 1, but the directory change still goes through. With a program that dumps the NULL terminated <key>=<value> lines of the environment block, it looks like it does still modify the environment, but in an unexpected way: Before `cd /D =:\`, I had a line that looked like this (i.e. the per-drive CWD for C:\ was C:\foo): =C:=C:\foo After `cd /D =:\`, that was unexpectedly modified to: =C:==:\ Funnily enough, that line means that the "working directory" of the C drive is `=:\`, and that actually is acted upon: =:\foo> cd /D C: =:\> --- You might also be interested to know that '= in the name of an environment variable' is a more general edge case that is handled inconsistently on more than just Windows: https://github.com/ziglang/zig/issues/23331 https://github.com/ziglang/zig/issues/23331