This just shows the command line was badly designed to begin with.
If CLI programs received already-opened file handles instead of pathname strings, most programs would have no need to have the concept of a "current directory" at all. It could be something purely internal to the command-line shell.
It would also be more fitting for a capability-based OS instead of one where every program has an ambient permission to access anything in the whole file system.
So am I, as a terminal user, supposed to track file handles now?
CLI programs might be used by an actual human, not necessarily called by a script.
UNIX/Linux already has a compromise here with stdin/stdout/stderr, the convention that those are fds 0, 1, and 2, and stream redirection in shells. You can already redirect raw fds in bash on linux, that's exactly what "something > something.stdout.txt 2> something.stderr.txt" does.
When there's a retail-grade desktop os built with capabilities as a foundational feature, it will want a shell with appropriate primitives and an ergonomic syntax for them.
Pwsh is not the last word on shells, but it does have automatic cast from string to FileInfo. Ergonomically, it kicks the shit out of legacy shells.
JOIN US. FEEL THE POWER OF THE DARK SIDE.
Too bad every command takes a full second to execute. At some point, just use Python.
Total FUD. Nobody would tolerate that. I would not tolerate that.
If it adds more than 2ms to invocations, post your $profile script.
> UNIX/Linux already has a compromise here with stdin/stdout/stderr, the convention that those are fds 0, 1, and 2, and stream redirection in shells.
DOS provides the same