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

51–60 of 81 posts

Re: Designing command-line interfaces

#51

Post by njharman »

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…

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)

Re: Designing command-line interfaces

#52

Post by jsrn »

mahmud wrote: post #49

This might not be shared by others, but here it goes. If your CLI program is a file-format conversion utility, please include a way to dump meta-data, header formats, etc. Don't just silently convert from A to B, allow me to get at the info you have gathered from the input. For example, a binary disassembler SHOULD dump the executable header format. An spreadsheet converter utility SHOULD display how many sheets ther…

"[...] but it doesn't have an -i or --info option that tells me how many pages a PDF file has"

You could use pdfinfo - in Debian / Ubuntu, it is in the same package as pdftotext (poppler-utils).

To extract (only) the number of pages of a PDF:

    $ pdfinfo FILE.pdf | grep '^Pages' | tr -s ' ' | cut -d ' ' -f 2

Re: Designing command-line interfaces

#54

Post by joeyh »

njharman wrote: post #51
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…

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.

Re: Designing command-line interfaces

#55

Post by billmcneale »

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…

For Java: JCommander http://jcommander.org/

Re: Designing command-line interfaces

#56

Post by sjs »

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 doesn't necessarily double the number of flags, it doubles the number of boolean flags. And if you use a convention like joeyh mentioned then the length of your help text won't double, nor will the cognitive burden on users who have to remember the options.

A disadvantage of this system is that --no-x might not always make sense or read well so if you make it consistent it may be weird. On the other hand if you use --no-this and --without-that then you are increasing the documentation and cognitive burden on yourself and your users. For most geeks this is admittedly a pretty minor disadvantage but it's the only one I have off the top of my head.

Re: Designing command-line interfaces

#57

Post by shaggyfrog »

huhtenberg wrote: post #17
scott_s wrote: post #11

Earlier quoted context omitted.

And if you use C++ and are willing to use Boost, program_options: http://www.boost.org/doc/libs/1_47_0/doc/html/program_option... I recognize that many people are not willing to use C++, and among those that are, many are still unwilling to use Boost, but I find the program_options library to be great. An example use that I think is reasonable and a big win over doing it myself: https://github.com/scotts/cellgen/blob…

> 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 :)

What's the deal with not liking Boost? I've used several of its components off and on over the years.

Re: Designing command-line interfaces

#58

Post by mahmud »

jsrn wrote: post #52
mahmud wrote: post #49

This might not be shared by others, but here it goes. If your CLI program is a file-format conversion utility, please include a way to dump meta-data, header formats, etc. Don't just silently convert from A to B, allow me to get at the info you have gathered from the input. For example, a binary disassembler SHOULD dump the executable header format. An spreadsheet converter utility SHOULD display how many sheets ther…

"[...] but it doesn't have an -i or --info option that tells me how many pages a PDF file has" You could use pdfinfo - in Debian / Ubuntu, it is in the same package as pdftotext (poppler-utils). To extract (only) the number of pages of a PDF: $ pdfinfo FILE.pdf | grep '^Pages' | tr -s ' ' | cut -d ' ' -f 2

Thank you. Now I don't have to hate people who leave blank pages without the customary "This page intentionally left blank".

Re: Designing command-line interfaces

#59

Post by shabble »

salem wrote: post #27

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

There was a project mentioned on HN fairly recently (~weeks ago) about an extended pipe system, using JSON and a bunch of common schemas, as I recall.

Both http://acko.net/blog/on-termkit and http://blogs.perl.org/users/rocco_caputo/2011/05/apppipefilt... seem to fit what I was thinking of, but I'm sure there was something else.

Nice ideas, but the inertia of existing unix tools is going to be hard to overcome, and a system isn't much use until all your common tools support it (or at least don't break it).

Re: Designing command-line interfaces

#60

Post by jcr »

You might want to fix this typo.

> Maybe it¿s just me, but I prefer to remotely control computers via SSH over VNC

If you're really running "SSH over VNC" then you're doing it wrong. ;)

> I have always wanted a program that shows a movie in my terminal by converting it to ASCII art in real-time, that would be sweet

man mplayer and look for the -vo flag which controls the video output mode/driver. Two common options for video output (-vo) are the 'aa' (ASCII Art) and 'caca' (Color Coded ASCII Art). There is a third, 'bl' ("blinkenlights") but it's hardware dependent.

Post reply on HN