@notclacke@hipsterelectron Exactly. And it's so stupid that Microsoft hasn't fixed this artifact of DOS. Current drive should be locked at C: and \ should thereby always be relative to that. And C: should be a virtual absolute root, not the first hard drive.
@dalias@notclacke@hipsterelectron Windows drives are the source of so much inconsistency! They really should've gotten rid of this nonsense. DOS compatibility is already all over the place anyway.
Besides the whole "absolute" path with additional state nonsense, there's also the whole thing with inconsistent working directory handling, where they inject messed up pseudo env vars to keep behaviour "compatible" with DOS. That's a fun one to look into, for anyone wanting to be *more* horrified.
@lunarood Horrify us! I grew up fighting the "com bat files", as some of us called them, and moved up from there through Windows 3.0, 3.1, 95 and XP, but this quirk sounds new to me.
@notclacke@hipsterelectron@lunarood You don't remember typing A:, doing some stuff on floppy, then typing C: and getting back to the same dir you were in on the HDD?
That wasn't just COMMAND.COM shell behavior, but actual OS state in DOS that Windows preserved as local to the process. 🤮
@dalias Yes! I described that elsewhere in the thread. Each drive has a current directory, and your actual current directory is determined by your current drive and the current directory of that drive. Is that state what you mean by pseudo environment variable?
@notclacke@dalias@hipsterelectron Not quite. What I was referencing, which Cassandrich expanded upon, is the particular way in which this DOS behaviour was "ported" to Windows.
It's handled in the process environment, rather than at the OS level. Technically they are actual environment variables, so my "pseudo" was kinda misleading, but they use a mangled naming scheme to avoid collisions with other vars.
The link I posted in another reply goes into more detail (some of it in the comments).
@lunarood Aha! Gotcha. Making them actual environment variables with special names rather than process attributes is an "interesting" choice. They do affect the behavior of native Windows processes, right?
@notclacke@hipsterelectron@lunarood Wow this is even more cursed than I expected. So what does d:foo mean when d: isn't the drive of the real current working directory? Same as d:\foo?
And what does \foo mean? Is it relative to the root of the drive letter of the current working directory? Or what?
@dalias@notclacke@hipsterelectron Now, tying this all back to d@nny's original issue... taking all the variations in behaviour into account... I think we can all confidently say that the full, definitive, exhaustive answer is: 🤷♀️
As for those two questions about the paths... my assumption is that, on Windows (without cmd.exe), the answer is "yes" in both cases. Though I can't verify this... it's been years since I had to deal with a Windows box.