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

Designing command-line interfaces

antoarts.com

Post reply on HN
Print view View original

21–30 of 81 posts

Re: Designing command-line interfaces

#21

Post by _delirium »

mcantor wrote: post #13
antoarts wrote: post #10

Earlier quoted context omitted.

I choose not to discuss implementation in that article, but you should never reinvent the wheel (poorly).

I think a lot of people don't even realize such libraries are out there, or don't understand that there's a wheel being reinvented. ("It's just command line options. Why would you need a whole library to do that?")

Some of the wheels are also very big and crufty--- I would only link GNU Getopt to a C program if it were a Real Program, either with complex option processing or need for industrial-strength polish. For simple one-offs it's a lot easier to have 3 lines of strcmp(), and Getopt feels like overkill.

Re: Designing command-line interfaces

#22

Post by asolove »

huhtenberg wrote: post #5

(edit) There is a bit of terminology substitution going on in linked article. Command line interface is a shell. That's where one types the commands. Calling command options and arguments an interface may be technically correct, but it is not what is conventionally understood under a term of CLI . --- Speaking from an experience writing CLIs for configuration-heavy embedded devices, the key design element of a functi…

zsh has an extensible command/expansion system much like what you are asking for, allowing users to implement plugins documenting how to autocomplete commands, options, and data types passed to options (files, yes/no, etc.). It is fantastical.

Re: Designing command-line interfaces

#24

Post by mcantor »

zwp wrote: post #18
mcantor wrote: post #12

One more: Keep your "usage" blurb succinct and clear. Don't clobber your users' terminals with two pages of output when they're not expecting it. If "yourapp", "yourapp -h" or "yourapp --invalid-flag" results in two screenfuls of information containing your app's license, installation instructions, contribution notes, an exhaustive listing of every single one of the 100 available subcommands, and a verbose representa…

Also tedious: $ ls -Q ls: illegal option -- Q usage: ls -aAbBcCdeEfFghHiklLmnopqrRsStuUwxvV1@/[c | v]%[atime | crtime | ctime | mtime | all] [files] It's succinct but that second line is almost completely useless.

One of my favorites is tar:

    $ tar -m foo
    tar: You must specify one of the `-Acdtrux' options
    Try `tar --help' or `tar --usage' for more information.
Oh, right! `-Acdtrux'! How could I have forgotten. I deal with ACD Trucks all the time. (?!?!)

Re: Designing command-line interfaces

#25

Post by gnufied »

> Silence trumps noise

How about, ec2-server-start -n 4 -t medium -i img-xxxg Which expands to start 4 medium instances using image img-xxxg. Will you prefer a long wait and then silently back on prompt or an indication of something happening?

I agree with what he is saying, but I think there is a hint of unfair generalization here.

> Naming your utility

Again small unix commands are like precious three letter domain names. Not always viable. Also, although most of single letter commands are free, one should avoid to name a CLI binary in single letter, because 1. users often type single letter stuff by mistake. 2. users use single letter aliases.

Re: Designing command-line interfaces

#26

Post by dmpatierno »

alexis-d wrote: post #19

I agree with most of the article, except the yes/no part. In fact I think it's better to do : "Do you want to do this (Y/n)?" Where the most common option is uppercase so I can just hit enter.

The important point here is to at least require that key, rather than just using getchar() or whatever else and continuing on unexpectedly.

Re: Designing command-line interfaces

#28

Post by brunoc »

mcantor wrote: post #7

Oh, and another: Use your language's command-line option processing libraries. OptionParser in ruby and argparse in python. There is no reason to eschew these libraries: they're part of the standard library, they require zero coupling to your app logic, and they handle all of the edge cases for free. "But I can just shift the arguments", you say! Yeah? Great! What if the user pipes input through STDOUT? What if the u…

I'm working on a CLI right now that's rather "complex" in Ruby and i'm seeing the other extreme: CLI frameworks and DSLs. I don't know about other languages but in Ruby your library options range from the minimal (DIY with OptsParser, Trollop) to the gigantic (Thor, Rubicon) and everything in between...

Re: Designing command-line interfaces

#29

Post by janus »

mcantor wrote: post #12

One more: Keep your "usage" blurb succinct and clear. Don't clobber your users' terminals with two pages of output when they're not expecting it. If "yourapp", "yourapp -h" or "yourapp --invalid-flag" results in two screenfuls of information containing your app's license, installation instructions, contribution notes, an exhaustive listing of every single one of the 100 available subcommands, and a verbose representa…

Also I'm looking at you, rails.

Re: Designing command-line interfaces

#30

Post by a3_nm »

mcantor wrote: post #3

Here's another one: Provide explicit flags for default behavior . For example, if your lines-of-code counting utility excludes preprocessor directives by default, and includes them when you pass "-i", provide an "-x" switch that signals to use the default behavior. This way, when someone wants to write a bash script that uses your utility, they can do this: case $include_directives in y) LOC_FLAGS='-i';; n) LOC_FLAGS…

Other benefit: if you aliased myownloc="myloc -i --complicated_option", you can run myownloc -x to selectively disable the -i switch.
Post reply on HN