Powershell made 2 things gospel and I'm just sad it's going to take 20 years for other operating systems to realize that's the way to do it and something that replaces linux to see it in practice (i.e. it just won't)

1. Auto-complete is by-design part of the language/shell

1. Pre-approved Verb list that prefix commands helps discoverability and usability no end. Still learning? Get-<anything> will literally never cause a problem.

Because of the above get-help <function> can automatically create some fairly useful documentation right away and whoever wrote the code didn't need to do anything. They can significantly add to to help though. Because that mechanism is part of the language it's worth doing literally every user is going to access it, not some blog your wrote 5 years ago I hope is still online.

Passing objects rather than string, whatever maybe it's not the best way, I think it's great. But That's not the only thing PS has to learn from.

If anyone uses the cli and doesn't know how the PS help system works, it's certainly a breath of fresh air to learn.

I never really found the verb list to be entirely satisfactory. It's great that they gave boundaries but I find it too verbose. There are other kinds of syntactic ergonomics with concise vocabulary (lisp has ! xxx p$ for instance, they're a bit harder to swallow but I find the code a bit more poetic and easier to remember as a pattern).

About the objects vs strings, Kalman Reti (of Symbolics IIRC) talked [1] about how an OS passing pointers could enjoy a much easier time instead of serializing everything as strings then deserializing, especially when done ad-hoc through sed/grep/perl/whatever .. It pains me to see this. It pains me to see how linux basic utils are 30% --usage, 30% output formatting (and they all share this).

MS did a great thing with PS.

[1] https://www.youtube.com/watch?v=o4-YnLpLgtk

I like it. Nowadays CLIs got out of hand with verbs, every CLI assigns a very specific meaning to their verbs and it's not clear at all. Just look at kubectl: https://kubernetes.io/docs/reference/generated/kubectl/kubec... What is the difference between "get" and "describe"? It's totally not obvious what "drain", "cordon", "taint", "scale" or "expose" do. Something like Set-KubeReplicaCount describes way more accurately what scale actually does. Or New-KubeService for "expose".

Remember that you can always use and create aliases, so you could still use kube-scale or kube-expose in the terminal if you want. But for scripts readability is the most important thing. Any newcomer can look at any PowerShell script and know what it does. And any newcomer could type in New-Kube, hit tab, and see what new things you can create in Kubernetes, instead of having to google what the command for creating a service is.

You're right, these are completely obscure, and part of the friendly neologism fad we're seeing. Please note that the examples I showed about lisps aren't short sighted concepts but very generic ones (predicates, side effects, global variables), hence the limited scope of confusion here.

The verb list is, in practice, 90% Get-* and Set-* , so for most users that will cover the case where they need to read and modify some system state in a script.

It may not cover your particular use case (I want to foo this bar), but as restriction on the language it helps your users not have to discover esoteric commands.

I find PS tab complete to be sub par compared to fish. It’s too aggressive when there are multiple completions.

What do you mean by aggressive?

I don't know what they mean, but I know that I really dislike how PS's autocomplete works.

If the possible commands are (for the sake of discussion) `Get-AppLockerFileInformation` and `Get-AppLockerPolicy`.

If you type `Get-App` and hit Tab, it will autofill to `Get-AppLockerFileInformation` which I just really don't like, and I need to keep hitting tab to cycle through all other possible `Get-App*` commands.

What I want is some UI that when I hit tab it autocompletes as much as possible until there's a decision to make, and then shows me the options. So in my example case, it would look something like this:

Type `Get-App` -> hit tab -> shows `Get-AppLocker` -> type "P" -> hit tab -> `Get-AppLockerPolicy` is displayed

bash-ish systems nail this, and they even have the "double tab" to list all options from that point which is normally pretty nice.

The PS idea of "keep hitting tab or shift-tab while you cycle through all possible options" sucks in comparison. Especially with discoverability (There are about 20 commands on my windows system that start with "Get-App", and in order to figure them all out I just need to keep hitting tab until it cycles around)

With PSReadLine, you can change that:

  Set-PSReadLineOption -EditMode Emacs

Or

  Set-PSReadLineKeyHandler -Key Tab -Function Complete

The first one seems to change it how I want, but the second doesn't. And it doesn't stick around after closing the powershell prompt.

And while I'm sure there's a way to make it persist, a shell's power is in it's ubiquity. If i have to change settings on every machine I work with, i'm probably going to want to use that time to install a different shell.

I know that's an attitude that is pretty impossible for any new shell to solve for, but it's the truth. I'm not choosing the most powerful or "best" shell, i'm choosing the one that gets in my way the least. And for me, that's bash in 99% of cases. And until another comes along that really improves discoverability and makes it easy to learn and adjust to, i'm not going to switch.

I have a ton of knowledge built up over the years about bash and I'm not in a position where I'd be able to dump it all and painfully try to learn everything new from scratch by reading manuals, trying out syntaxes, searching around for if what I want to do is possible, figuring out the "right" way to do things, and more.

Even if it is better in the end, if I can't get over the initial hump, it's not very useful to me. Maybe this is just me getting old...

Making things like that persist is done through the powershell profile stored at $profile. It is the equivalent of a ~/.bashrc.

Actually, that isn't a PowerShell idea.

Firstly, that form of completion has existed in the Microsoft/IBM operating system world for significantly longer than PowerShell has, tabbing backwards and forwards around a list of matches being the way that one did filename completion with some MS/PC/DR-DOS tools back in the 1980s. Secondly, PowerShell ISE can do things differently, so this cannot be a PowerShell thing.

Crank up PowerShell ISE, enter "Get-App", then press Control+Space. For more, press Control+Space to complete an option after entering "-".

I didn't mean to imply that it was a PS creation, or that it was impossible to change, only that it's how PS handles tab completion, and that I dislike it.

Being able to change defaults is nice, but the power of PS or bash is that they are ubiquitous. So anything that has to change defaults to be usable makes it kind of pointless in a lot of ways (at least to me). Because if I need to change defaults on every system i'm on, then why not just use that time to install a different shell? (which is pretty much what I end up doing on windows machines)

Not sure what version you are using, but that is not how PowerShell does completion for me. If I type in `Get-Package` for example and hit tab, I get printed a grid of the possible completions. Then I keep typing until it's not ambiguous, at which point it will complete the whole command. If there are hundreds of suggestions, it will ask if I really want to see them all.

I am running PowerShell 6.1.0 (which I think uses PSReadline). PSReadline is also very customisable, but this is the default behaviour.

At this point I'm not really sure what makes command-line so great. We should have something like it in the GUI sapce that works much better but, like you said, "stolkholm syndrome".

Why can't a pipeline be a more complicated multi-io workflow? In a 2D GUI this would be trivial to construct and read, but in a 1D command line it would get confusing in a hurry. And the concept works much better with AV, I can easily construct and reason about complicated arrangements of audio and video inputs and outputs, with mixers, compositors, filters, shaders, splitters, etc. between them.

Instead we worship text. Is that because manipulating text is actually more useful, or because our tools are only good for working with text?

Text is exact, programmable, repeatable and transmissible.

exact: in many GUI tools, you can have non-default settings that you changed via menus. Where are they stored? Which ones are currently active? Does it matter that you selected four objects first, then a transform tool, then another object?

programmable: > find /var/spool/program/data -name foop* -mtime +3d -print

vs "open the file manager, go to /var/spool/program/data, sort by name, secondary-sort by last modification time, find the ones that are more than 3 days old, make sure you don't slip"

repeatable: OK, do that again but in a different directory.

transmissible: here's the one-liner that does that.

Now, your specific requests are about audio and video toolchains, where I will admit that reasoning about flows is easier with spatial cues -- but I'd really like the output of that GUI to be an editable text file.

Command line is not the only HCI that can use text. Also, no one (except immense mental inertia) stops developers from producing serializable graphical interfaces.

I think the macro language of WordPerfect 5.1 was one of the most awesome serializable interfaces ever.

And they scrapped it in WP6 for some shitty object oriented version that lacked all the "serializable workflow" of the previous one.

The command line is great because it makes it easy to automate tasks involving multiple arbitrary applications. It's why we still use it even after GUIs basically became mandatory on all user-facing computers.

Yes. IOW, GUI's are not as easily scriptable as CLI programs, to compose operations from combinations of other operations, even though some tools to do stuff like that do exist, e.g. AutoHotKey and others like it.

A classic CLI command composition (a.k.a. pipeline) example:

More shell, less egg:

http://www.leancrew.com/all-this/2011/12/more-shell-less-egg...

After reading that post, I wrote about it here:

https://jugad2.blogspot.com/2012/07/the-bentley-knuth-proble...

with a couple of solutions in Unix shell and Python.

Related:

Why you should learn just a little Awk (2010) (gregable.com)

https://news.ycombinator.com/item?id=17322412

A comment by me there:

https://news.ycombinator.com/item?id=17324572

I think we (cli advocates) worship text because language happens to be a very powerful user interface.

What we need is a ubiquitous command interface where the output of any command is a tree set of typed objects and any command is free to consume any of those sets of typed objects. The typed objects in this pattern would not be limited to text.

This paradigm removes the restraints of GUI applications but satisfies a great many use cases with the obvious exceptions being any program that requires a lot of mouse or pointing device input like photo manipulation.

The Art of Unix Programming by Eric Raymond is a good in-depth look at (not just) Unix CLI programs, covering both pros and cons, some:

http://www.catb.org/esr/writings/taoup/html/

https://en.wikipedia.org/wiki/The_Art_of_Unix_Programming

Anaconda and similar big data tools are moving into this space. They are for data exploration not general system tasks, but still it’s a nice higher level command line.

Most people who claim that command line is the best tool for power users know nothing about history of GUIs. They think that laughable garbage that Windows calls user interface is "how it's supposed to work", and proceed to smugly lecture everyone on how command line is the only interface that can be composed and easily recorded.

(The following paragraph is not directed at the author of the parent post. It's fully rhetorical.)

Did you know that icons were supposed to be live representations of in-memory objects? That objects were more fundamental for the OS than files? Did you know that windows were views onto those objects? Did you know that interactions to and between icons were synonymous with OOP polymorphism?

https://www.youtube.com/watch?v=Cn4vC80Pv6Q

And this isn't the best UI, it's simply the first modern UI.

And how you do operate on the data in those objects? How do you filter, project, sort, stash for later, combine with data from elsewhere, edit, etc? How do incrementally build up a composition of operations from repeated experimentation? How do you record that composition in a script?

>And how you do operate on the data in those objects?

You don't. Your question makes as much sense as asking how to do polymorphism in shell commands Not operating on data was the whole point of OOP. (Or at least one of the key points.)

http://userpage.fu-berlin.de/~ram/pub/pub_jf47ht81Ht/doc_kay...

  "I wanted to get rid of data. The B5000 almost did this via its 
  almost unbelievable HW architecture. I realized that the 
  cell/whole-computer metaphor would get rid of data, and that "<-" 
  would be just another message token (it took me quite a while to 
  think this out because I really thought of all these symbols as 
  names  for functions and procedures." -- Alan Kay

The way to integrate unrelated objects in fully OOP UI would be by making them send messages to one another, either directly or indirectly. The way to store this integration for later use would be by creating, modifying and serializing an object that represents it.

Look into Pharo or Squeak, at least watch some demos on YouTube.

> Sometimes I end up passing the help output through grep, then copy-pasting the flags from the output, and then hoping I got the right flag.

  man x | grep -P y -C 3 | less

...is my standard here (-C 3 includes the pre- and succeeding 3 lines). For all the delights of CLIs, man pages are by default opaque walls of text. And dear lord the number of regex variants... - at this point, if at all possible, I'll avoid application-specific flavours entirely, and just pipe to grep -P (perl-style regex).

I might suggest, however, that image/video manipulation is a case for which CLIs are uniquely unsuitable.

There surely are better ways (as you mentioned, Powershell appears to be a step or three in the right direction, though I have little familiarity with it), but it seems as though the greatest difficulty is in maintaining full backwords compatibility, while still encouraging new applications to make full use of novel features - not to mention the effort of modifying old applications to fit new standards that would need be expended.

If you're already piping to less, just use its search functionality; type '/', the regexp, and then enter.

For that, you might as well just use the regex functionality in man itself too. But that misses the point.

The goal of grepping in that snippet is that you're `less `ing through precisely the parts that matter, and no more, rather than wading through the whole man page, and you're using -C to control how much context you (think you) need around the search results. This is a much better setup for skimming through potential hits than going through the man page wall of text.

'man' has no regex functionality; on most Unix systems, it just uses 'less' as its pager.

sure, which means that it inherits regex support via less. You either have it on both, or neither.

IIRC you don't need to pipe to less at all for that - man already supports it. grep -C gives a good summary of the various options, then you can just pull up the man page and use that selfsame search to get details that might've been cut off.

You can also do that directly in 'man'.

No. All three of the responders so far have implied that this functionality is in man. It is not. It's in the pager that man invokes; ironically often, but not necessarily always, that very same less program.

Speaking for myself of ffmpeg and imagemagick, I don't find the CLI itself difficult, I find that their application domain is a bit complicated for a layman.

Meaning I usually struggle to comprehend what particular options mean rather than how they bind to CLI.

Maybe indeed a good intuitive UI would give more intuition about the more obscure options. But then again, a good intuitive UI is a quest of its own.

Merge a separate video and audio file without looking it up - I've got a document stored that lists all the different commands I've used and hopefully some context about what they do.

What is difficult with ffmpeg is the sub-language in each argument, which depends on the filter you’re using. I can learn to lookup the manual, but if I have to go to the internet to learn the syntax of the filter, I’m better off googling my usecas.

And using multiple filters in one call is even more funny. Getting the output and parse it too, as it can be different in different versions and it's terribly inconsistent between filters.

I think that the solution is clear, make a language server for the command line. Each and every single command line interface is its own language so they all need their own language server that can provide meaningful completions. Then bash and other shells can add support for language servers and we have the problem solved.

I imagine this to be a little bit over the top in most cases. A standard flag like --complete-rahyeiB1 (with a sufficiently long random string to avoid collisions with existing flags) which takes the already written argument list as an argument and prints possible completions would be nice though.

> I'm sure we all end up using google

Which is kinda a CLI application.

But done the right way. With autocompletion based on your frequent searches, recent searches, machine learning based suggestions using what the whole internet searches, etc.

It's qualitatively different from your average CLI experience. As such, I don't think you can actually compare the two.

It is a command-based line-input UI. Just because it is different in other ways doesn't mean it a comparison is unwarranted.

My argument was that the "other ways" it is different in are more important than the similarities.

Writing is GUI takes time. With CLI you can provide much more functionality with much less time. You're free to write GUIs for all CLIs in this world, however.

For a quick args reminder, without having to dig through man pages, try tldr: https://tldr.sh/

> I wonder if we all have a bit of an Stockholm syndrome

I used to agree with you on this point, but then came Bender. Chatbots singlehandedly liberated the CLI from the terminal and made them ubiquitous once again.

So yeah, it's not just the terminal where we're creating CLI applications anymore.

If your command line tool has a man page then fish shell can parse it to automatically know about command line arts for auto completion.