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

61–70 of 81 posts

Re: Designing command-line interfaces

#61

Post by llimllib »

scott_s wrote: post #36
huhtenberg wrote: post #17

Earlier quoted context omitted.

> many are still* unwilling to use Boost* I can appreciate the subtlety of wording, but in reality it is more of > many will never be touching Boost even with a long pole and for a large sum of money :)

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.

Re: Designing command-line interfaces

#63

Post by lell »

rmccue wrote: post #62

> Multi-letter options start with two hyphens, and each such argument must be separated with spaces. That's something that's always annoyed me about screen; commands such as "wipe" are "screen -wipe"

there's "find ./ -type d", also (find directories only.)

Re: Designing command-line interfaces

#64

Post by ilikepi »

lell wrote: post #63
rmccue wrote: post #62

> Multi-letter options start with two hyphens, and each such argument must be separated with spaces. That's something that's always annoyed me about screen; commands such as "wipe" are "screen -wipe"

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

Re: Designing command-line interfaces

#65

Post by ilikepi »

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…

Speaking of "usage" blurbs, for $DIETY's sake, please assume 80-character wide terminals.

Re: Designing command-line interfaces

#67

Post by keeperofdakeys »

reinhardt wrote: post #37
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…

What about the disadvantages? - It doubles the number of flags of the program. - It allows invalid or ambiguous combinations: is `myloc -i -x` valid? If yes which flag takes precedence? It seems these must outweigh the benefits or it wouldn't be so uncommon.

"- It doubles the number of flags of the program."

I don't agree with this. One of the advantages of command line programs is that you can have a large amount of possible arguments, but it doesn't really matter for the user, as long as there is some way to give the most common (like --help and --long-help, or listing the important options in the man page, then have a full list) . This is where GUI's fall down, you must process all options to get to ones you want; where as command line programs can have just the options you want set mentioned. (have you seen mplayer's man page lately?)

As well as having negating arguments, you also want long versions. This is so, when used in scripts, the arguments passed to a program make some kind of sense.

With your precedence argument, just look at some of the standard tools. For rm, -f will override -i. I want this behaviour, personally. It seems 'obvious' that it should be that way.

Re: Designing command-line interfaces

#68

Post by BrandonM »

supersillyus wrote: post #45

I'm glad he mentioned the "Silence trumps noise" point. I like to call the idiom "no news is good news". Tell me only when I need to know something (like a failure); "-v" is always there if I need it. It feels uncomfortable to get no output at first, but once you get used to it there's much less to read. It's rather like the Plan 9 convention of programs returning strings instead of ints when then terminate; an empty…

There is no silence vs noise problem. Send output to STDOUT and "noise" to STDERR. Use -q and -v when appropriate. I thought it was weird that the author created a false dichotomy between being informational and giving only output that can be easily processed.

Re: Designing command-line interfaces

#69

Post by code_duck »

Pewpewarrows wrote: post #15

One 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'…

I've seen a few discussions of this around.

I agree with you, but there are some who believe that examples do not belong in manages (not sure what their rationale is).

Re: Designing command-line interfaces

#70

Post by epochwolf »

llimllib wrote: post #61
scott_s wrote: post #36

Earlier 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.

I haven't used C++ since college so I don't understand why this would be an issue.
Post reply on HN