> Are we still in the world where the interactive text-based environment (not programming environment) with the best available ergonomics is based on a general framework set in 1979?
Yes, because it's not broken (certainly not for interactive use), so it's not in a need for fixing. People who don't understand it are doomed to reinvent it poorly (vide curl/wget aliases in powershell).
People who don't understand PowerShell are doomed to bikeshed two aliases from an entire shell, programming language, and ecosystem of OS integration and tooling.
> "Yes, because it's not broken (certainly not for interactive use)"
It's not /broken/, it's dated, limited in the way "turn everything to CSV or JSON and turn it back" is becoming common as a clunky workaround, limited and weak as a programming/scripting environment with hard boundaries making it difficult to extend or build on without having to switch to a completely different thing like Python/Perl, inconsistent and arbitrary with all commands doing their own thing for argument parsing and input/output formatting and style of human interface, and all being isolated silos, it's easy to do badly and difficult to do well.
PowerShell parses command parameters at the shell level. So they're all consistently handled, there isn't the same "this command has weird argument parsing". That means the engine can look into the cmdlets and interrogate them in standard ways and present hints about usage from their help comments. PowerShell is a scripting language and lets you reach for the .NET framework when its builtin commands aren't enough, and then lets you build commands in C# still for more flexibility or performance but still using the PowerShell engine for parameter processing and from there lets you build modules for ease of deployment to different machines. PowerShell engine has scriptable tokeniser, AST, meaning your code can process PowerShell code and editors can lean on the engine for syntax highlighting and autocompletion instead of using regexes from before LSPs.
Powershell is very cool and the object model and .NET integration is awesome. I just wish that Microsoft adapted Lua or Javascript or massaged Python or whatever something instead of inventing a language with yet another weird syntax.
It's not two aliases, it's also that Verb-Noun two word rule instead more sane two letter rule, which is better suited for interactive use. That this decision was made for the purpose of noise abatement (every character was loudly hammered into a paper by a printer) doesn't make it any less valid today and we still prefer less keystrokes, even on today's silent terminals.
I don't care much about parsing CLI parameters, because after some time they get into muscle memory. Yes, I know `ps` and `tar` have some different legacy conventions but I don't care. I just type what I've remembered. In this area, only the number of keystrokes (corrected for tab completion) counts.
Also, does "consistent argument parsing" work for regular programs written in normal (non-.NET) programming languages like C, Python or Rust? Because if not, then it's not really consistent, only consistent within a specific ecosystem, which can also be said about `getopt(1)`, `getopt(3)`, click or any other language's argv parser.
A ton of common pwsh commands have built-in short aliases, sometimes even two-letter ones. They're intended for interactive use, with the verbose forms expected in scripts.
New-Item -> ni
Set-Location -> sl
Get-ChildItem -> gci
Invoke-WebRequest -> iwr
Get-Help -> help
Select-Object -> select
The what rule? The one that "printf", "curl", "tar", "gunzip" and pretty much every other command don't follow except for "cd", "ls", "cp", "mv", and "rm"? Those two-letter commands are only really needed because UNIX started on paper ttys and follows "ed" in its "don't show current context to the user" philosophy; launch "mc", or use "fzf", and you can forget about them as if they were a scary dream.
bc, cc, dd, df, du, ip, jq, nc, ps, ss, su, tr, wc, xz are some I use regularly. There are others. But it's not coincidence that the basic file operations you've mentioned are very short: they're the most common used commands in the interactive shell.
> Those two-letter commands are only really needed because UNIX started on paper ttys and follows "ed" in its "don't show current context to the user" philosophy
Today they need to be short so they're just quick to type. You can set $PS1 just fine and it shows you as much (or as little) context as you'd like.
It's only scary to people watching over the shoulder, because it's just faster than anything else. Close second place is Windows 95/98 "Start" menu and "Explorer", both of which also can be operated with keyboard, thought only for browsing directories deeper — and some Linux DEs like Cinnamon menu can also be worked in similar fashion.
> [Bourne shell is] not broken (certainly not for interactive use), so it's not in a need for fixing.
From the perspective of writing command-line utilities, it’s kind of broken though?
Builtin or forked pagers gated on isatty(), similar situation with syntax highlighting, a dozen line editors (from the readline juggernaut to whatever less has inside it), most programs rolling their own command systems rather than reuse the shell—all of that stinks of wrong factoring at the terminal layer.
(To be clear, I’ve used Emacs, Acme, and the Plan 9 not-a-terminal; they served to point out some of these problems, but I don’t believe any of them counts as a full solution.)
Move away from the terminal, and you still see individual programs being much larger that they need to be, up to and including plugin systems and embedded scripting. Because—and I hate to say it—moving structured data across the process boundary is a pain!
It’s certainly possible; if you dumb it down enough and resign yourself to writing bad half-parsers, you can get qbe or noweb or perhaps even roff (although that one’s got a scripting language inside it). But most probably you’ll turn each part into a library, link everything into a hulking monolith and call it good design. Maybe it is! But it’s working around the environment instead of taking advantage of it. Which means the environment is not doing so great.
I think the table stakes should be ls. Can the proposed model make ls simple, but allow the user to easily do most of the things that the current humongous ls is forced to have inside (at the very least, table layout, multicolumn display, colouring, ls -l, ls -t, ls -R)? PowerShell can, admittedly, but it’ll make my fingers bleed in the process. And it’ll still, as far as I know, throw up its hands at stitching together (not as a single program!) something like lstree or ncdu, let alone wget -r.
I don’t mean to say any of this is simple. A full solution would probably end up saying interesting things about hypertext, component systems, incremental programming, and other theoretically nifty things people have tried and mostly failed to make work. But I don’t see progress towards a solution, either, and if what we have is the best possible option, it still sucks.
> Writing bash is fun the same way as doing cross words are fun. And I say that as someone who enjoys writing bash scripts.
Most of the time people who say they think the Unix shell and tools are difficult haven’t bothered to learn them. But not all the time, and that small minority makes me distinctly uncomfortable, because I simply can’t understand how that can be.
Given you say you’re part of that minority, can you try to explain or demonstrate the problem? Perhaps give me a problem I can try my hand at, if you have one that makes sense out of context? Because while I’ll admit there are plenty of tasks for which I’ve found shell scripting unsuitable, for those it does work on I’ve rarely found it difficult.
(I feel like I also have to point out that “writing bash scripts”, especially writing them to last, is very much not what my original comment was about. What it was about is more like this thing I just typed at the terminal because I couldn’t be bothered to write a script:
It doesn’t do things Properly™ and wouldn’t work with an arbitrary $URL, but I knew which one I meant, and it was certainly simpler and faster than digging up requests and beautifulsoup and whatnot.)
Yes, because it's not broken (certainly not for interactive use), so it's not in a need for fixing. People who don't understand it are doomed to reinvent it poorly (vide curl/wget aliases in powershell).