Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Command Line Interface Guidelines

clig.dev

Post reply on HN
Print view View original

51–55 of 55 posts

Re: Command Line Interface Guidelines

#51

Post by kps »

roundabout-host wrote: post #45
kps wrote: post #40

Colour addendum: If the user hasn't configured anything, don't use a colour other than red without checking whether the terminal has a light or dark background. Don't hardcode colours.

If you use the 14 standard colours (the plain old colours minus black and white), shouldn't they be set to something readable in the terminal emulator configuration? Of course, the 256-colour mode should not be used. And how do you check the background?

No, not simultaneously usable as foreground and background colours. For instance, on a light background, the default yellow is a good ‘highlighter’ background. If yellow is reconfigured to be dark enough to be usable as a foreground colour (i.e. brown), it's no longer usable as a background. You can't have both, and you can't assume the user has picked one or the other.

> And how do you check the background?

OSC 11

Re: Command Line Interface Guidelines

#52

Post by jodrellblank »

roundabout-host wrote: post #49
jodrellblank wrote: post #41

Earlier quoted context omitted.

It's awful UX for a program to know that you used it wrong, to be able to print the help there and then, and instead to tell you off and instruct you to ask politely (with --help). People who think that's okay in CLI world hate that kind of uppity-C3PO-servant behaviour from an LLM. $ thing usage: -lscekm4urytmvjpq9i8u3o54ernymctpwi8eruymgv ah ah ah, , ask nicely for: --help $ thing -h ERROR! There is no option -h Wh…

You are comparing CLIs to GUIs. Anyways, there are GNU/Linux GUIs with the help manual (often still F1), but I would attribute the lack of manuals in some newer GUIs to a general trend against manuals, which can be seen well in Android/iOS apps, where everything has to be "engagement-optimised" and "flow-based" and with lots of blob illustrations, because otherwise people are too lazy to read even a page about how to…

> You are comparing CLIs to GUIs.

Yes, and GUIs are winning again as they so often do, but also no I'm not; you can be in PowerShell CLI and run `Get-Help thing -Online` and have it launch a GUI web browser to the URI that `thing` declared as its help page. You can run `gci | out-gridview` and get a PowerShell object stream input to a GUI item picker. And on other machines you can run `ls | gvim -` and get a GUI that's reading from command line stdin.

But also no I'm not: look in this thread, part of the distinction is composability, part is interactive vs non-interactive use, part is whether the workflow gets paused, part is whether the output is desired by default or should be requested on demand, and part is whether the output stays on screen or is cleared. There can be no answer from all of these differing desires which pleases everyone, and that's a total failure of imagination.

CLIs can have jobs and background jobs and there's no official standard or de-facto standard for having the running job go into the background to display the help or paged output in the foreground. CLIs can have multiplexors, screen and tmux, and editors EMACS and VIM which have buffers and windows, and there's no official or de-facto standards for different output streams to open in either different buffers or split-windows, or in tiling window manager windows. There's options to export PAGER= but there's no standard way to indicate interactive vs non-interactive use, only trying to divine intent on a tool-by-tool basis by checking if a TTY is attached. Rustc and Elm and Odin and other language compilers have stretched to provide helpful error messages which make pretty good guesses what the user was trying to do, explain why it won't work, and suggest what to do instead, but shells and CLI tools in general have none of that.

Even without going to Alan Kay and Brett Victor extremes, Linux/Unix world has this widespread lack of imagination for what computers could be and do, and only this fruitless status bickering where computers are just another way to compete in the Suffering/Purity Olympics.

Re: Command Line Interface Guidelines

#53

Post by kazinator »

matheusmoreira wrote: post #35
procflora wrote: post #4

Earlier quoted context omitted.

Isn't this basically how more modern "chatty" CLIs use stderr? Put all the nice progress bars and emojis behind `if isatty(2)`? I thought so anyway, but I'll admit I've never actually looked at what npm, uv, etc. do.

That's the right approach. Output goes to standard output, and user facing messages go to standard error. That way output can still be piped or redirected while the program talks to the user, and messages can also be suppressed by redirecting to the null device. I've always been annoyed by the fact file descriptor 2 is called the "error" stream. Should have been called the "user" stream.

If a tool unconditionally produces diagnostics on standard error, whether there is an exceptional situation or not, I consider that poor behavior, contrary to the quiet tool philosophy from Unix.

Standard error is special output that the user should be able to somehow see (e.g. on a terminal) even if the regular output is redirected (as you note above).

That doesn't mean standard error is above the quiet tool guideline.

Re: Command Line Interface Guidelines

#54

Post by eikenberry »

jpitz wrote: post #13
ventana wrote: post #12

Earlier quoted context omitted.

This is a common approach, CLI tools often use isatty [1] to check if the output fd is a TTY or not. Try running "git log" for example; if you have many commits, it will page through "less" or $PAGER only if it sees that you're on a real TTY; but if not, it will not. Try this: git log # PAGER undefined; uses less PAGER=/usr/bin/head git log # pages through head, you get 10 lines PAGER= git log # PAGER is empty; does…

I'm bothered by it because whatever git command that I'm executing will put its output in a pager and when I quit the pager it's not there anymore. I want the output on the screen when I start typing the next command. Oh my God, this is such a frustrating pattern.

`git config --global core.pager cat` will fix this.

Re: Command Line Interface Guidelines

#55

Post by hankbond »

roundabout-host wrote: post #46
hankbond wrote: post #5

> Whatever software you’re building, you can be absolutely certain that people will use it in ways you didn’t anticipate. Your software will become a part in a larger system—your only choice is over whether it will be a well-behaved part. good advice

It is, but then why does the "guide" contradict it tens of times?

I'm in a charitable mood so I will just say that we rarely live up to our ideals.
Post reply on HN