This is true today, and it was true as well "in the 1980s", to use the same time frame as TFA. The difference is that today there are more people than ever who know what the command line is, and who can use it. At least an order of magnitude more people; maybe two. We can certainly say that we live in the CLI golden age!

If done right it can also encourage Functional Core, Imperative Shell, because a sensible Unix-philosophy command line needs lots of actions without side effects and a few with. You can write a little command that generates and dumps out the system state just before a (bad) decision is made, and do so against production systems with virtual impunity. And that means you can hand these tools to someone who you need to become part of a bus number, even if they are otherwise hesitant to do so.

If you want to judge the shift in quality in a thing that grew in quantity, then you should look at percentages — otherwise you end up creating statements that are true, but don't say anything meaningful.

E.g. there are probably more absolute listeners of Jazz music today than back at the height of the cultural bloom of the genre. But that isn't because Jazz is more popular today than it once was, but because there are more absolute listeners of any kind of music. Would you say that Jazz in the US is now more important, influential etc. than it was at its peak?

Whether from that quantity new qualities emerged is a different question. E.g. the new quantity of diverse jazz listeners probably has lead to an explosion of new sub-genres, that might have never emerged otherwise.

Still, just because there is more different Jazz now does not mean Jazz has become more relevant overall. This was the factor we discussed btw.

[1]: https://prettier.io

I'll go further. PowerShell covers a lot of the concerns in the OP out of the box. It is extremely well thought out and is one of my favorite cli models to buy into.

I feel it’s safer for scripts that have irreversible (or difficult to reverse) actions.

Instead of

    myprog           # see what would happen
    myprog --commit  # alright, do it

    myprog           # see what would happen
    myprog | sh      # alright, do it

    myprog > x
    vi x
    cat x | sh

    myprog | parallel -j 16

If you call an API to retrieve data, how can that be a dry run? Are you suppose to give fake examples with fake output?

Calling an API to retrieve data is not really the type of program that requires a dry-run flag. It's mainly useful for commands that change the state of something in ways that could potentially be destructive, unwanted and/or hard to revert.

https://docs.aws.amazon.com/cli/latest/userguide/cli-usage-h...

But at that point you could just handle —dry-run directly

You can do that. Possibly not from all languages but for anything that can call functions in the c standard library, that’s what isatty() is for (among other uses). It takes a file descriptor and returns whether it is a terminal or not. If you do this with stdout, this tells you whether it goes to a terminal or whether it is redirected in a way.

As the parent suspects, though, this won’t tell you anything about what is on the other side of the redirection.

The output sent to tee is usually not the same as the output from the command to the terminal, so you are getting something different than most human users expect from original command... the reason is that terminal escape codes and other formatting for humans may need to be omitted from output to a pipe. You do this by asking the OS, "is this thing a terminal?".

Python example

"terminal" if sys.stdout.isatty() else "something else"

C is very similar:

if (isatty (1)) fprintf (stdout, "Terminal."); else fprintf (stdout, "Not Terminal.");

(printf works, too).

Even ls outputs a tabular format by default when it's on a terminal and a list one file/dir per line when it's not on a terminal (if it's piped to cat for example or why ls | wc -l correctly counts the entries).

But the (essential) behavior of the command remains the same. ls still lists files/dirs... scp still copies files, etc.

-

What if there wasa 'deep-pipe' '||' which would be based on a set env/docker/blah - which would launch an env and execute your '||'d code in it, and output some log/metrics/whatever?

One approach could be something like “set -x” after setting a confirmation with “trap” command.

    confirm_execution() {
        echo -n "Execute $BASH_COMMAND? [y/N] "
        read response
        if [[ $response != [yY] ]]; then
            echo "Skipped."
            return 1
        fi
    }

    trap 'confirm_execution' DEBUG
    set -x
    user_command
    set +x

draw_heart() { cat http://www.w3.org/2000/svg" viewBox="0 0 24 24" width="100" height="100"> EOF }

trap 'confirm_execution' DEBUG set -x draw_heart set +x

https://github.com/binpash/try

Never display animations in stdout! I quite liked TFA in general, but I was skimming around looking for where they were going to advise on the difference between stderr & stdout until I saw that and realised they weren't.

stderr should be all (not just 'errors') of your logging, informational type stuff, the bits that maybe you might animate (and some people will hate) if tty, etc.

stdout should be the useful output - which you may or may not have - regardless of whether tty or not, primarily because an inconsistency like that is just confusing.

e.g.

    echo foo | mysed 's/oo/aa/' | cat
    # mysed should:
    # stdout: faa
    # stderr: mysed version 1 here hello\nfound oo\nprinting aa (or whatever)

To add a small tweak to this rule... "stdout should be what you ask for". If I ask for --help, that should go to stdout. If I ask for logs, they should go to stdout. If I don't ask for it, stderr.

If we could go back in time and make it stdin, stdout, and stdext (because UNIX so six letters, but standard_extra, or standard_extended), we might have a prayer of getting people to follow that convention.

But it's called stderr, so devs think, quite reasonably, that it should be used for error reporting, and conversely, if it isn't an error, it goes in stdout.

But I agree with you that this is the better way to structure a program. You might confuse more people with it, but they'll be able to do more useful things with its output, so that's a win.

(Ok, sure, I'd probably change the name too!)

for the love of god please don't. the yubikey-agent example provided exemplifies everything i dislike about github READMEs and whimsical user interfaces.

on the technical side, symbols and emojis can render inconsistently among terminals, leading to potentially confusing messaging. on the artistic side, personal tolerances towards whimsy and playfulness vary wildly and should only be used very sparingly and ONLY if you know what you're doing (if you have to ask, you probably don't)

Not everyone is like that, and that's ok. I don't expect my whims to be catered to, and you shouldn't either.

So it's scriptable and useful by multiple levels of skill.

Grepping through a large list of options is also painful, seems ther needs to be a balance here.

There is a web analogy for this in how people organize FAQs. Some have a list of section links, and you have to click on a section to get the FAQs for that topic. Others just put everything on one giant page.

Here's the problem scenario with splitting things up into section pages: You think you see the appropriate section, but then you don't see your concern answered. There are two possibilities: either the organization was counter-intuitive and your concern was answered in one of the other sections, or your concern wasn't answered anywhere. And what's the only way to be sure? Visit every single section page and search through all of them.

Much, much less painful to just have it all on one page and search it.

e.g. `git stash <sub>--help` just reports `git stash --help` which includes each ``</sub>

Why is it incredible useful?

Just imagine how long it would take to write the following in C or Rust:

    curl -sS https://go.dev/doc/devel/release |
      html2text |
      grep -o -P '\bgo\d+\.\d+\.\d+\b' |
      sort -V |
      uniq |
      tail -1

Read this: https://news.ycombinator.com/item?id=29747034

The problem: a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem.

Since the computer is there to serve us, ultimately the solution must be for the machine to read as well as humans.

Sure, but that will just be one aspect of an integrated and wholistic AI, which can configure the parameters input to the automated theorem proving component, and act on the results.

It's not really the "same time". Usually, human and machine use the same command, but at different times. And there are many ways to enable different outputs, even at the same time. But this all depends on having some standard which everyone follows. And that's where it becomes complicated.

* Powershell has entered the chat

I think your example self-explains why it's broken by design. It's a good example.

> a command line interface must be human readable and machine readable at the same time. There is no canonical way to solve this problem.

And you know, there could be one. Apple has Human Interface Guidelines to reify the meaning of the visual abstractions in its desktop UI. The problem is that the command line didn't come from people who think like Apple designers; it came from people who think "How can I express what I want using the least code possible, because laziness, impatience, and hubris are virtues?" And they weren't wrong for the time (especially because every byte matters), but the design decisions they made got baked into tooling that can't now be moved.

I think at this point we'd have to punt the POSIX toolchain to get something better; it's hard for me to imagine how we'd build discoverable, conceptually-consistent UX atop what we currently have.

Posix could potentially do this. It already has a bit about conventions and could be expanded. Problem is getting things to adhere to it, plus I doubt the posix authors could be convinced to add a lot more to it.

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

The snarky answer is "By writing it in source code, in a GUI text editor", a thing I do frequently. But the problem is that I have no idea what you're getting at in the first place, so that's just an attempt to recover some meaning from what you wrote.

By and large, GUIs do not. There is no such thing as a universal shell for GUIs, and attempts to layer automation atop the GUI abstraction are generally spotty and unreliable (certainly when compared to CLI and shells). This is both for technical reasons (i.e. it's much easier to clearly delineate the two ends of a pipe than to clearly delineate "I want to click on the red square inside the 'diagram' window inside the drawing app") and for ecosystem reasons (since GUIs aren't thought of as automatable, GUI designers are free to move pieces around version-to-version of software, making it extremely challenging to describe a GUI structurally).

I've seen some neat attempts at GUI automation (Sikuli is my favorite) but it's never been a core feature like it is in the CLIs-glued-together-by-shells world.

Yeah, sometimes there's functionality stuck behind a button or menu select which I want exposed in a more textual way, in macOS that's when you break out Automator, Alfred, or Hammerspoon (the only one I've ever used fwiw), Linux and Windows have their own equivalents.

I don't think the distinction you're pointing to is nearly so stark or clear-cut as it's often made out to be. Ecosystems converge towards the tasks which are amenable to batching and pipelining being equipped to do so.

The specific kind of task you described is frequently exposed as macros in programs complex enough to deserve it.

Great for discoverability though, and that doesn't require graphics, just context.

There should be a button I can push in my shell that lets me ask "what does the token at cursor mean," and a button that lets me type a plain language search string that wires down to a contextual search (i.e. I'm in the middle of typing out "grep" I should be able to ask "how do I search folders?").

We didn't have the tools to build this when grep was invented; we have them now.

> Since very few implementations of ls allow you to terminate filenames with NUL characters instead of newlines

In fact the solution to this issue seems to be so obvious that I might be missing something ? (Rejection by shell interfaces for some reason ??)

> Secrets should only be accepted via credential files, pipes, AF_UNIX sockets, secret management services, or another IPC mechanism.

Which one of these is the most convenient and portable to use?

Do you use secret management services for work only, or do you use them in your personal projects too?

See my post https://smallstep.com/blog/command-line-secrets/ for a bit more of a deep dive about using secrets on the command line.

Credential files are a good, simple, portable option. Files have permissions already. They don't depend on an external service or a proprietary API.

And, if your program accepts a credential file, it will be compatible with systemd credentials. systemd credentials offer more security than an unencrypted credential file. They are encrypted and can be TPM-bound, but they don't require the software using the credential to have native TPM support.

Not quite. They were primarily intended for interactive use within a login shell. There are the programs which generate output on stdout (ls, cat, find, tty, who, date), and there are the "silent" text filters (tr, grep, cut, uniq, sort, wc). A one-liner would enable you to do basic computing tasks in that era. Any complex program would be written in C. After the appearance of DSLs like sed and AWK, certain string-heavy programs were offloaded to the shell.

The shell is not a sane programming environment and was never intended as such.

There are 10kloc C programs that could be 10 lines of shell and there are 1kloc shell programs that could've been 100 lines of C.

Both kinds are nowadays probably better done in Python or Lua, but the shell and C are what's most universally available.

Only when the shell calls other external C programs. Ten lines of calling ffmpeg or curl is not shell programming.

> there are 1kloc shell programs that could've been 100 lines of C

The 1kloc shell programs are fragile spaghetti that breaks in weird ways. Any invocation of an external program can fail for a variety of reasons, and the shell doesn't provide adequate mechanisms for dealing with it, apart from exit codes and filtering error text output.

100% wrong. this is what the shell was designed to do and where it is at it's best.

often shell "scripts" are used like "macros" or power-tools, shortcuts to save off a complex invocation or workflow. error handling isn't as important in a one-off and "adequate" is whatever gets the job done for the user, which it does.

it's rare that 1kloc shell script is the best engineering choice vs. (in the ancient days) Perl or (today) Python. e.g. "real" programming languages. you mostly should not write large programs in shell. and you really should not glue together pipelines of external programs using, for example, Python or C, which is onerous.

ah, the HN crowd: where everything is either black or white, great or terrible. how about "each to his own" and "use the right tool for the job"

I get that in a dev shop that's not the case, but most businesses employ 0 devs. So people end up being forced into shell scripting because it's the only approved option.

Ten lines of calling ffmpeg or curl is shell programming in precisely the same sense that 100 lines of C that `#include ` are C programming.

If your code isn't standing on the shoulders of giants, you're probably wasting everyone's time.

To me it makes total sense to think of the standard POSIX toolkit as the standard library of the various shell languages, that seems basically correct in fact.

Command Line Interface Guidelines - https://news.ycombinator.com/item?id=38053692 - Oct 2023 (1 comment)

Command Line Interface Guidelines - https://news.ycombinator.com/item?id=31651161 - June 2022 (1 comment)

Command Line Interface Guidelines - https://news.ycombinator.com/item?id=25492119 - Dec 2020 (5 comments)

https://www.goodreads.com/book/show/104745.The_Art_of_UNIX_P...

https://www.catb.org/esr/writings/taoup/

It has been a while since I read that book, but after skimming through clig.dev I gather opinions have changed over time quite a bit.

Example: Something I did a few months back ago for a tiny personal project @ https://github.com/hiAndrewQuinn/finstem was implement `--format CSV`, `TSV` and `JSON` flags. I haven't had need for any of these myself, but they exist so any future people who want to use `csvkit`, `awk` and `jq` respectively to wrap around my program have easy ways to do so. That's not stuff I would have had the instincts to do if I wasn't myself a user of all 3 of those programs.

Please avoid the use of short arguments in scripts. It makes the least sense there. The short arguments (along with aliases, abbreviations, and whatnot) are a convenience for human usage, to reduce the amount of manual typing. In scripts you can be explicit with minimal cost (and you also should, considering the ratio of writes vs. reads).

[1]: https://github.com/spf13/cobra

# pizza --cheese

Ordering...

Success.

#

https://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1...

Like, why does tar get to be so special that it takes command line flags with or without leading dashes?

now we got lots of mega-cli programs, each one with its own distinct option language.

Examples: kubectl, docker, openssl, git - (git got two command line languages: plumbing and porcelain)

https://danluu.com/cli-complexity/

... ls had 11 command line options in 1979, in 2017 it got 58.

So you just have to design the UI perfectly on the first try. That’s possible for small tools but what about larger ones? Past a certain point it becomes a truism that do-it-once perfectly without iteration is impossible.

This would be analogical, if commands always included their version. For example:

    rm-2.44.287-SNAPSHOT -r /

Then those terminal programs get upgraded on the next system update because hey, you’re supposed to the get latest version right?

Terminal programs can do the same (`-v1`) in principle. Few do.

    - $package-manager install $program 
    - which $program
    - cp $program ~/my/own/directories
    - $package-manager uninstall $program

[0]: https://github.com/greenpau/statifier

I find that guis have worse discoverability and cli better. It's pretty hard to search for a gui affordance. Plus they are essentially unscriptable.

See the manual page's [1] "STANDARDS" section, which reads:

    getopt()
        POSIX.1-2008.

    getopt_long()
    getopt_long_only()
        GNU.

        The use of '+' and '-' in optstring is a GNU extension.

It is probably a feature which isn’t necessary for the languages itself but Linux/POSIX.

TUIs have the same drawbacks as GUIs and then some. Their big advantage is to work seamlessly over SSH but that’s pretty much it. They are not more discoverable and they are not more efficient than GUIs. There is nothing preventing you from having a decent GUI along the same lines as Midnight Commander to have a file manager without the metaphors you dislike, for example (as a matter of fact, there are several).

When designing TUIs I found this to be limiting in a creative sense -- I have to really think about how I arrange the TUI elements and information because I cannot put as many elements as I can on a GUI in the same screen space.

Also, TUIs seem to be mostely unaffected by the trend to make every GUI element “touch-friendly” large which is an advantage for me as a Desktop user.

Full rant here: https://masysma.net/37/why_terminal.xhtml>

TUIs are ideal (sometimes) where a command needs to be interactive. Many commands lend themselves well to batch processing or require no interactivity at all. In many cases, a script piped into a text editor (which is a TUI) is all that is needed, sparing apps from having to embed a text editor and deal with all of the design choices. Other times GUI will work a lot better.

My biggest beef is total lack of CLI exit code.

Makes it useless for bash programming with systemd utils.

    bind 'set enable-bracketed-paste on'

https://wiki.archlinux.org/title/Readline#Bracketed_paste

https://en.wikipedia.org/wiki/Bracketed-paste

Put in .inputrc:

https://wiki.archlinux.org/title/Readline#Bracketed_paste

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

I still find it a rather shocking order of priority, honestly.

https://clig.dev/#documentation

A good option package should support long options being both command line flags and environment variables. The really good ones support them in init files as well (I'm partial to the JSON-ish HOCON format, though .INI works too).

I always spec (later overrides previous settings):

    - system default   (/etc/foo.conf)
    - user defaults    (~/.foo.conf)
    - local defaults   (${CWD}/foo.conf)
    - user-specified init file (overrides local default)
    - environment vars (FOO_OUTPUT=JSON)
    - command line var (--output=json)

Writing a replacement utility seems a bit like overkill.

... but we didn't, so now you have to memorize whether recursion is capital or lowercase R, restart is capital or lowercase R, poweroff is capital or lowercase P, etc.

Let some legacy programs like ls and sync keep their single-hyphen combinations. Most new programs should just accept separate flags, and allow either single or double hyphens.

Edit: Yeah, this opinion collects downvotes, doesn’t it? Y’all love it when you accidentally type -recursive instead of --recursive, and it turns out that it means the same thing as -r -e -c -u -s -i -v? That never made any sense to me, for the vast majority of tools out there. It sucks, to be honest.

You must like `find`.

I think the answer to that is just to stop designing argument parsers that way—if you want -a 0 then maybe -a 0 is acceptable, maybe -a=0 is acceptable, but -a0 should not be. I don’t see how this part is controversial.

For the same reason, -all should not be parsed as -a -l -l.

>I favour everything being --long --anyway --to-make-it=really-clear.

Yeah—I think it would be equally clear to write it like -long -anyway -to-make-it=really-clear, if we decided to make more parsers that worked that way. Some parsers do work that way.

>You must like `find`.

I have to assume that this is just sarcasm. The `find` command gives you a DSL for writing queries, and for some reason, the tokens in that DSL are option flags starting with -. Bizarre. I don’t think anybody wants to design something like that, and I don’t think there’s really anything to learn from find except maybe “sometimes, for historical reasons, the command-line arguments for standardized tools just plain suck.”

There is a lot of value on understanding the context and trying to parse what you meant in a mangled command. For the foreseeable future, that value will fall entirely on documentation and search procedures, and chat will keep a steady negative value for actual interaction.

Early AI shells will ask for confirmation like "ansible --check" or "terraform plan". Running commands in a disposable virtual environment will inspire confidence. When they are trusted enough, direct execution.

Soon after you're able to say "Set up a k8s cluster for me!" you'll decide you don't need k8s anymore, you'll just introduce your AI model to your data-lake and be done. The days of thinking about how many nodes do I need, which immutable linux distro, t5g vs m4.xlarge are almost gone.

Read the lyrics to Graham Nash's "Teach Your Children", substituting "model" for "children" as necessary. :-)

It's inefficient for even the simplest AI model to use a CLI, so API's are the future. But using API's to create a k8s cluster are pretty primitive too. The nearish future is things like unikernels running LLM's and rule-based logic engines and data-lakes. LLM's can help you create rule-based logic engines and data-lakes, so win-win.

Window desktops are dead. MacOS is a zombie with lipstick. Linux desktops are like playing an electronic harpsichord. Linux servers and Windows servers are dead too. Who cares? CEO's ask "How many widgets did we sell this quarter and will I get a bonus?" Regular people ask "When is my next dental appointment, how do I get wine stains out of my rug, what's good on TV? " [There are more important questions but people probably won't ask their device and expect a useful answer]

All of these things current LLM AI can answer with 90% accurancy, which is better than human accuracy. General AI is not necessary for pretty significant changes in the status quo. The IT sector's only future purpose is to help train models, IMHO. And future means now, not in 10/20/50/ years.

But then I realized that you're probably right. I'm kinda looking forward to looking back with bewilderment on those decades of doing CLI stuff with remembering all those commands and shell intricacies and whatnot.

Maybe the proles will one day be permanently denied the CLI, but even if only as a lowest common denominator administration tool of last resort, I predict there will be a CLI somewhere.