The article is interesting up to a point, but what really struck me is that this blog claims to be written by a 15 year old. I think the topics and depth of the other articles on the blog spell great things for this guy's future!
Designing command-line interfaces
71–80 of 81 posts
Re: Designing command-line interfaces
#72See the paper by Rob Pike and Brian Kernighan 'Program Design in the UNIX Environment' (aka 'cat -v considered harmful'):
Re: Designing command-line interfaces
#73Earlier quoted context omitted.
When I have to compile your program which uses that oh-so-useful Boost library, I curse you to the skies.
I haven't used C++ since college so I don't understand why this would be an issue.
If you don't have an easy way of installing boost, it becomes complicated - just to compile one program.
That said, boost is a dependency that pays off in terms of programmer time if what you're doing is complicated enough (in other words, if you think you might reimplement some part of boost, you're better off using it as a dependency instead.)
Re: Designing command-line interfaces
#74Earlier quoted context omitted.
Yeah, I was thinking of the people who are violently opposed to it. And, man, I have to admit I really don't get that attitude. There are some well-designed libraries in there, and you can pick-and-choose which libraries you want to use. I respect people's decision, I guess I just don't understand it.
When I have to compile your program which uses that oh-so-useful Boost library, I curse you to the skies.
Boost is installed standard with most Linux distributions now.
Re: Designing command-line interfaces
#75Earlier quoted context omitted.
there's "find ./ -type d", also (find directories only.)
'find' is an interesting animal: it* really only has a handful of traditional option parameters, and these are of the single-dash-single-letter variety. The single-dash-word parameters are all part of its expression language for selecting filesystem objects. * checked against /usr/bin/find on OS X 10.6.8 (which seems to lack an option parameter for printing its own version number) and GNU find 4.2.27
'find' is one of the oldest Unix programs still in common use. Its standardized arguments predate modern conventions for command line arguments.
Re: Designing command-line interfaces
#76Earlier quoted context omitted.
Besides the technical details, there are good practices which should be followed, but I don't know of any document which lists them. This is a pity, because though text-based interfaces are often designed in a much more efficient way than GUI interfaces, they are seldom consistent between themselves, and often get something wrong. A few common ones: - Don't make the user reach for distant keys like escape or pagedown…
> For one-line text entry, support readline bindings (^W, ^U, ^Y, ^B, ^F, etc.) Better yet, don't try to emulate readline--just use readline itself. > spawn $PAGER to show text and $EDITOR to edit text. If you're old school enough, honor $VISUAL and fall back to $EDITOR if it's not set.
linenoise[1] is a fairly small readline alternative which seems to be gaining some traction. I know that one of the more common objections I've seen to using readline in some smallish utility is that it's a pretty big library, so that might help out.
Re: Designing command-line interfaces
#77Do you really want to do this (y/n)? i would rather see this as Do you really want to do this (y/N)? capitalize the option that will be used by default if you hit enter with no other input.
I'm also used to seeing
Do you want to do this? [n]:
Re: Designing command-line interfaces
#78One cool feature of the juniper junos CLI is that all the CLI commands have an option for XML output, making parsing of the CLI output in scripts a little more sane.
I talked some folks into using JSON output for a tool, and am now in the midst of fixing both ends so that the output is valid JSON, instead of a newline delimited file with JSON on each line.......
Re: Designing command-line interfaces
#79Earlier quoted context omitted.
Problem with "silence" and "no news" is they are indistinguishable from many failure modes. I vastly prefer confirmation of action(s) as default and -q flag. At very lest there needs to be -v flag that provides confirmation of action(s)
Configure your shell to report nonzero exit statuses. joey@gnu:~>true joey@gnu:~>false zsh: exit 1 In zsh this is done by "setopt print_exit_value". It's a pity shells don't do it by default.
Good hint, but it's value is very niche. Waiting until exit for status is fail. Many commands take seconds if not minutes/hours to complete. I wanna see some indication that they are working and not hung/etc.
Re: Designing command-line interfaces
#80One thing that always infuriates me: If I go to --help or the man page for your command, and don't see a real example of how to use it immediately, you've failed me as a user. Seeing your syntax tree and a list of every option and its description doesn't help me when I'm first trying to use your program. I just want to see one or two quick examples of real commands with a short sentence explaining each. After that I'…
man docs have a specific format, a followed by b followed by c, etc. Examples are towards the end, near bugs and author.
It may not be how you want it, but at least it's consistent. shift-G will take you straight to the end, with hopefully some examples.