With drive letters, a neat functionality in DOS/Windows command prompts (don't ask me about Powershell) is that each letter can have its own "current directory".
So if you have ffmpeg.exe in C:\Program Files\FFMpeg\bin, and you have some source files in D:\SourceVideos, and you want to process them in ffmpeg and output them to E:\Output you can do:
C: (to navigate to the C: drive)
cd "C:\Program Files\FFMpeg\bin"
E: (to navigate to the E:\ drive)
cd D:\SourceVideos (you remain in E:\, but the "current directory" for D: has been changed).
cd Output (to enter E:\Output)
You can now do C:ffmpeg.exe -i D:scene1.mp4 output-scene1.mp4
and Windows accesses the files in the "current" directory on each drive letter.
I don't think that's good, I think that's horrible, got to hate invisible state.
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.
A neat functionality in bash and other common Unix based shells is that you can have variables. So you can do:
(navigate to one directory)
src=$PWD
(navigate to another directory)
dst=$PWD
(navigate wherever you like)
You can now do: ffmpeg -i "$src/scene1.mp4" "$dst/output-scene.mp4"
If you avoid spaces and other special characters in directory and file names, then you can skip the quotes.
This is conveniently not limited to a system wide partitioning scheme.
command.com also has variables. Syntax not so great though.
There is also “subst” (https://en.wikipedia.org/wiki/SUBST)
It allow you to pretend a directory is a drive, and thus gives you multiple current directories on a drive.
An interesting quirk of how this works: https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14...
Yes officer, This post right here.
> You can now do C:ffmpeg.exe -i D:scene1.mp4 output-scene1.mp4
This won't actually work because multiple current directories are a fiction of cmd.exe
Interestingly, this blog post says it is implemented in the Win32 and kernel API (in RtlGetFullPathName) and thus should also work outside of cmd.exe: <https://projectzero.google/2016/02/the-definitive-guide-on-w...>
A “fiction” implemented as environment variables, which the ffmpeg process would inherit, so there's nothing stopping ffmpeg from “indulging the fiction”. Depending on how frequently users expect this behavior to work, I might even call it a bug in ffmpeg (or whatever file handling library it relies on) that isn't even all that hard to fix.
More here <https://devblogs.microsoft.com/oldnewthing/20100506-00/?p=14...>
I produced a fork of the Cygwin DLL in which the POSIX chdir() provides this same feature: the "currently logged drive" and per-drive current directory.
https://www.kylheku.com/cygnal/
It's behind quite a bit; haven't done a rebase in a while.
This is just one of the features (Issue 7); the idea is to provide a POSIX run-time for easily porting programs to Windows, but follow the conventions of the Windows environment.
>With drive letters, a neat functionality in DOS/Windows command prompts (don't ask me about Powershell) is that each letter can have its own "current directory".
I remember that NT4 did not have "current directory" context for each process. But but apparently[1] windows 2000 had it already. So what you write above is per process and not per logged in user right?
Asking, because I remember that Citrix which did Terminal Server 4.0 for NT4 had to license windows source code to be enable to make changes for their product at least somehow working with NT4. Up till that time Winddows did not keep current directory per process or at least user, but it was a global state.
So if you changed with "cd" current directory it changed for all processes which was a big issue for Citrox as they did look a way to make Windows a server class system, where each user had distinct environments with distinct default directories etc.
For me as I heard that then I did not understand what was Microsoft thinking letting still with NT such misfeatures remain shipped product and especially when they had real talent Dave Cutler been working on it.
I haven't been using windows besides using Visio a separate local VM since turn of century. So is Windows been since 2000 etc. a real multitasking multiuser system or does it still suffer such handicaps it had at least before?
[1] Microsoft licensed Citrix made changes and RDP protocol they had developed, then brought Server 2000 with terminal server product to compete with Citrix Terminal Server.
is this cmd or does it also work with pwsh / Powershell?
[dead]
I barfed a bit in my mouth
So you can be at A, run a successful absolute path cd, then do something bad like a bulk remove in the current directory, and you nuke A?
What a footgun.
`cd` does not travel to an "absolute path". It changes the working directory for the specified drive. Your prompt will still show you the old path (at A:), because you've not changed the folder for the current working drive, which yes, is kind of an insane concept.
If you want to actually change the working directory and drive at the same time (which is the "absolute path" idea you have), you do `cd /d D:\whatever\`.
Yeah I understood how it actually works, I'm just saying it's a potential huge footgun for someone writing a script coming from unix derivates.
At least if I had to write one, I saw cd is available and seemingly working as expected, and wrote a cd to an arbitrary target I would not expect it to behave that way at all - my expectation would be that either the next command always runs in the cd'd path, or at least that cd errors on a path in a different drive.
It was certainly weird for me coming from RISC OS. In that case, even though each drive has its own namespace (like with DOS/Windows), there's not just one "current directory" per session - there is in fact only one "current directory" per drive over the entire OS! As such, changing the current directory in one place would affect all relative path accesses using that drive, even in other programs.
It was common practice when writing RISC OS programs (and recommended by Acorn) to store your application's directory path into a system variable, and then use that to refer to all the ancillary files you needed.
I get the foot gun concern. But it's true going the other direction too.
Whether or not the gun fires comes down to what you're most accustomed to