Writing an article about best practices for command-line utilities, with a big topic being CLI accessibility (not to be confused with TUIs). Partly in response to a recent article I saw.
Wall of text that summarizes it before it's ready:
Including guidance for screen reader friendliness and pipe-friendliness, manpages versus short/long help, shell completions with help text, the NO_COLOR envvar, problems with spinners and decorative text, splitting functionality across subcommands and/or multiple executables, online docs generated from manpages, examples in manpages similar to tldr-pages, defining API stability (using Git's porcelain-friendly output modes as an example), short versus long flag options, POSIX-style short options, remember the trailing newline, be transparent about what's happening during execution (possibly with a verbose flag), documented exit statuses. Oh, and I'll give a shoutout to Emacspeak.
Anyone got more ideas?
Wall of text that summarizes it before it's ready:
Including guidance for screen reader friendliness and pipe-friendliness, manpages versus short/long help, shell completions with help text, the NO_COLOR envvar, problems with spinners and decorative text, splitting functionality across subcommands and/or multiple executables, online docs generated from manpages, examples in manpages similar to tldr-pages, defining API stability (using Git's porcelain-friendly output modes as an example), short versus long flag options, POSIX-style short options, remember the trailing newline, be transparent about what's happening during execution (possibly with a verbose flag), documented exit statuses. Oh, and I'll give a shoutout to Emacspeak.
Anyone got more ideas?
Follow
@Seirdy
I like to work with the following rules for simple utilities:
-V -> version
-v -> verbose
-h -> small help text, 20 lines or less. use man for longer text.
-V should print the program name and version number only. Avoid extra info or lines.
$ prog -V
prog 2.0.1
$ prog -V
prog 0.3.4-a7efb4c
