Well, there is no concept of "the current directory" in the UI of explorer.exe the way there is in CMD.EXE or Bash. You can have multiple directories open and none of them are privileged over the others.

I think of cultures of command line programs: the node ecosystem very much has the idea that a program "lives" in a a certain directory and you're always going to work with that program in that directory. This is convenient in a lot of ways but... say you are writing a data analysis program and you want to put it on your $PATH and then cd to the place where your data lives and do your work there?

▲

sidpatil 8 hours ago | parent | next [-]

> Well, there is no concept of "the current directory" in the UI of explorer.exe the way there is in CMD.EXE or Bash. You can have multiple directories open and none of them are privileged over the others.

Wouldn't you just have multiple explorer.exe windows open, each with a different folder open? Wouldn't that be similar to having multiple cmd.exe or Bash processes open, each with a different current directory?

▲

the__alchemist 7 hours ago | parent | prev | next [-]

I am using my own combination file browser/terminal. I landed somewhat arbitrarily at the each tab has its own CWD (PathBuf field), ie how terminals do it. Not the only right answer, but has not been a blocker, and simplifies some things knowing there is [for that tab] a single CWD which can be used to manage bookmarks, assess if the we're in* a git repo, rust project etc.

This approach may present limitations later; will change A/R. But simple = good for now!

▲

Dylan16807 8 hours ago | parent | prev | next [-]

The current directory in the UI is the directory open in whatever window you're clicking on.

That's a purer form of current directory than cmd, which has one per drive.

	▲	PaulHoule 7 hours ago \| parent [-]
		Yep, the first version of DOS wanted to be "like CP/M but on 8086 with a 640k address space" so it had drive letters and the second version wanted to be "like Unix but single user and with a funny memory model" so it had nested directories!

▲

pwdisswordfishq 8 hours ago | parent | prev [-]

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.

▲

RiverCrochet 6 hours ago | parent [-]

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.

	▲	autoexec 4 hours ago \| parent [-]
		> 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