Every time you rely on the current working directory, that's invisible state then. Even without multiple single-letter directories each maintaining their own state.
Same with $PATH and other environment variables. You learn this the hard way with cron. I use full pathnames for everything in a cron script because it's too much work to reason about how the cron environment differs from my normal working environment or even a root shell's normal environment.
I think I could be ok with it, as long as I can query it. Preferable if I have a way to directly interact with it that isn't just moving things around; though honestly this is no different than many physical machines. Consider, what does the accelerator pedal do in a car that is not in gear? And consider that changing gears is done on a completely separate input mechanism.
(Really, people don't engage more with physical machines to consider programming. We insist that everything has to be distilled down to symbolic functions. Preferably limited inputs and a single output. If only life was so accommodating.)
> I think I could be ok with it, as long as I can query it. Preferable if I have a way to directly interact with it that isn't just moving things around;
`CD` without any arguments will display the current directory on the current drive.
`CD E:` will display the current directory on the `E:` drive.
I didn't say that; I think pointing out the difficulty and danger in maintaining more invisible state than one already does is a perfectly valid criticism. But that wasn't the argument being made, at least not how I read it.
In most shells, the prompt is configurable. So you have yours configured to display the current path, as most do. It would be trivial to change it to display the current path for all namespaces across which this state is managed.
But a lot of times, you also need to think about executing programs from within a script, where you don't have this prompt. Thus, it's invisible state.
Path names are always really complicated, hidden invisible state or not. Just let use the Operating System's APIs to expand the full paths for you.
Then there's Path Canonicalization. This is especially hairy, and only needed in certain circumstances where you need to know when two paths are really on the same filesystem or not (Mount points and symbolic links can cause "C:\dir\file" to be on a different drive than "C:\"). Not helping this is that path canonicalization is broken on Windows in some cases. When you mount a filesystem, you are able to register the volume with the mount manager. If you do register it, path canonicalization will work, but you also get some unwanted side effects (creating a "Recycle Bin" and "System Volume Information" directory). If you don't register it with mount manager, the files are still usable, but Path Canonicalization won't find the drive. You have to enumerate every drive letter to find it, and if you mounted it inside a directory, that's even harder.
Every time you rely on the current working directory, that's invisible state then. Even without multiple single-letter directories each maintaining their own state.
Same with $PATH and other environment variables. You learn this the hard way with cron. I use full pathnames for everything in a cron script because it's too much work to reason about how the cron environment differs from my normal working environment or even a root shell's normal environment.
I think I could be ok with it, as long as I can query it. Preferable if I have a way to directly interact with it that isn't just moving things around; though honestly this is no different than many physical machines. Consider, what does the accelerator pedal do in a car that is not in gear? And consider that changing gears is done on a completely separate input mechanism.
(Really, people don't engage more with physical machines to consider programming. We insist that everything has to be distilled down to symbolic functions. Preferably limited inputs and a single output. If only life was so accommodating.)
> I think I could be ok with it, as long as I can query it. Preferable if I have a way to directly interact with it that isn't just moving things around;
`CD` without any arguments will display the current directory on the current drive.
`CD E:` will display the current directory on the `E:` drive.
No state chnages for either case.
> Every time you rely on the current working directory, that's invisible state then.
And you think adding to it will improve things?
I didn't say that; I think pointing out the difficulty and danger in maintaining more invisible state than one already does is a perfectly valid criticism. But that wasn't the argument being made, at least not how I read it.
My shell displays the current path, how is that invisible?
In most shells, the prompt is configurable. So you have yours configured to display the current path, as most do. It would be trivial to change it to display the current path for all namespaces across which this state is managed.
But a lot of times, you also need to think about executing programs from within a script, where you don't have this prompt. Thus, it's invisible state.
yes, yes, $PATH is also invisible state then
I depend on this behavior frequently. It's been a thing since MS-DOS 2.0...
Why is it horrible? It's just basic and well-documented system behavior.
Path names are always really complicated, hidden invisible state or not. Just let use the Operating System's APIs to expand the full paths for you.
Then there's Path Canonicalization. This is especially hairy, and only needed in certain circumstances where you need to know when two paths are really on the same filesystem or not (Mount points and symbolic links can cause "C:\dir\file" to be on a different drive than "C:\"). Not helping this is that path canonicalization is broken on Windows in some cases. When you mount a filesystem, you are able to register the volume with the mount manager. If you do register it, path canonicalization will work, but you also get some unwanted side effects (creating a "Recycle Bin" and "System Volume Information" directory). If you don't register it with mount manager, the files are still usable, but Path Canonicalization won't find the drive. You have to enumerate every drive letter to find it, and if you mounted it inside a directory, that's even harder.