Command Line Interface Guidelines
77 points
3 days ago
| 6 comments
| clig.dev
| HN
esalman
5 minutes ago
[-]
I have used click/typer packages to build some python-based CLI programs. It's easy and user-friendly way to build, but the amount of time it takes for python to start the environment followed by the actual program to do anything is annoying.
reply
eikenberry
1 hour ago
[-]
> Use a pager (e.g. less) if you are outputting a lot of text.

If I wanted to use a pager I'd pipe the output to a pager, no pipe to pager means I want it all dumped to STDOUT. So annoying.

reply
keithnz
1 hour ago
[-]
100% - I want to use whatever pager I might prefer at the moment, this advice violates their core principle "you make programs that are modular enough to be recombined as needed"
reply
Grom_PE
1 hour ago
[-]
For comfortable reading, I just had to figure out what on this webpage causes Chromium to drop subpixel rendering, and it's not this:

    html { -webkit-font-smoothing: antialiased; }
it's this:

    #TableOfContents { backdrop-filter: blur(3px); }
A panel that overlaps content only on narrow screens disables subpixel rendering for the entire text. Thanks Chromium. Not an issue on Firefox, btw.
reply
inetknght
2 hours ago
[-]
reply
hankbond
2 hours ago
[-]
> 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

reply
kazinator
4 hours ago
[-]
> A command is saying too little when it hangs for several minutes and the user starts to wonder if it’s broken.

Nope. For debugging the program, it is nice to have some debug tracing option, but if it's not the program's specification to produce output, it should not produce any. If the program's specification is that it produces a certain output after a certain calculation, then it shall not produce any other output, even if that calculation takes three weeks.

"cp -r from to" is supposed to be quiet until it's done or hits an error.

It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such). It's not bad; but fluff like this can't be in band with the output, or at least not by default.

reply
procflora
2 hours ago
[-]
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.
reply
yjftsjthsd-h
3 hours ago
[-]
> It would be nice to have an agreed-upon protocol for progress reporting. For instance, imagine of we had file descriptor 3 as "stdprogress". Programs could dump specially formatted messages there which the parent job control shell could intercept and turn into a progress display (with multiple rows for pipeline elements and such).

Different thing, but I am reminded of the BSDs having SIGINFO.

> It's not bad; but fluff like this can't be in band with the output, or at least not by default.

FWIW, I would describe stderr as being out of band. IIRC that's how e.g. pv works; `<file.img pv | dd of=/dev/foo` sends data along stdout while giving status info to the user since stderr isn't being piped.

reply
IgorPartola
2 hours ago
[-]
Lots of programs report progress when you send SIGUSR1 or SIGUSR2.
reply