4 ms·
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 WT
by squeek502 10mo 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 10mo agoHm, what about using `%` itself?
- squeek502 10mo agoThat 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