Hacker News Reader

Comment by PaulHoule | Hacker News Reader

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?

View on HN

> 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?

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!

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.

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!

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.

> 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

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.

Reply on news.ycombinator.com