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='-x';;
esac
myloc $LOC_FLAGS
1.) It's explicit, and thus more obvious and clearer.
2.) It's more consistent, so there's no risk of empty/unset variables, whitespace, or other edge conditions screwing up a delicate munging operation.
3.) It's change-tolerant, so if future versions of your utility change the default behavior, scripts will continue functioning as expected.
- 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.
Last flag wins is a common choice because it allows some script to contain yourcommand --include $@ and then you can override with --no-include.
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.
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.
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 user passes a flag, a required argument, and then another flag? Will your script read the last flag correctly, or has the naive logic already entered "required argument processing mode"? Just use the library. It's a solved problem!
Indeed! In fact it is so solved that the Python standard library has solved it differently 3-4 (I've lost count) times already, let alone the dozen or two extra packages at PyPI ;)
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/master/src/main.cpp#L...
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
:)
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 there are, if there are macros, how many rows, etc.
One of my pet peeves is pdftotext, a very nifty utility that I use to convert PDF reports to ASCII for subsequent awking. pdftotext has an option to specify start and end pages to extract, but it doesn't have an -i or --info option that tells me how many pages a PDF file has. So, my scripts have a very high upper-limit, like 1000, and it converts the file page by page, until the output text page has a size of zero.
Which reminds me, I should probably fork the fucker this weekend, now that I have some free time.
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 2If 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'll dive into the mess that is the dozens of flags and inputs to decipher exactly what I want.
I agree with you, but there are some who believe that examples do not belong in manages (not sure what their rationale is).
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.
Do you really want to do this (y/n)?
Do you really want to do this (y/N)?
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 representation of a configuration setting that 75% of your users won't care about, you're doing it wrong. (I'm looking at you, rvm).
This is similar to the idea of "You don't really understand something unless you can explain it so your grandmother gets it." Your app doesn't really have a sensible interface unless the top layer of its abstraction, or the most common commands, can be summarized in less than scrillions of lines of text. If you simply can't trim it down far enough, it's because you're breaking from the Unix philosophy and your utility is doing too much.
$ ls -Q
ls: illegal option -- Q
usage: ls -aAbBcCdeEfFghHiklLmnopqrRsStuUwxvV1@/[c | v]%[atime | crtime | ctime | mtime | all] [files]
$ tar -m foo
tar: You must specify one of the `-Acdtrux' options
Try `tar --help' or `tar --usage' for more information.
$ my-aw<TAB> # yay!
$ may-aw<TAB>
my-awe-inspiring-tool my-awwwww-how-cute-program my-awesome-version-control-prog
my-aww-yeah-tool my-awchoo-i-sneezed-program my-aw-long-your-names-are-grandma
bind 'tab:menu-complete'
This is an interesting discussion - what is the CLI, exactly? My personal PDF viewer is Zathura[1], which is controlled like VIM. On the other hand, programs like Kismet run on a terminal, but have mouse controlled menus.
Personally, I feel that Zathura is a CLI application, even though it depends on X, because the interaction is done in a keyboard driven way with no graphical widgets.
For the benefit of the original author, mplayer and xine both have ASCII art output modes (mplayer -quiet -vo aa, aaxine).
---
Speaking from an experience writing CLIs for configuration-heavy embedded devices, the key design element of a functional CLI is a context-aware TAB expansion. This is what makes a CLI truly convenient for routine use.
For example, if a mysql shell was smarter, it would've been allowing this:
> use p<tab><enter> expands to "use production"
> show c<tab> s<tab><tab><enter> expands to "show columns from secondary"
> select * f<tab> s<tab><tab> ... expands to "select * from secondary ..."
# ip addr <tab> shows "ip addr add"
# <tab> shows "ip addr del"
# <tab> shows "ip addr"
Context-aware tab completion is very doable in the unix world, actually; it's just a hassle on the part of the utility-writer. Have you ever noticed that if you add a new file "foo/bar/baz.py" to a mercurial repository and type "hg add fo<TAB>", it will autocomplete all the way to "foo/bar/baz.py", without stopping at each directory? This is because hg has overridden the default tab completion provided by bash and defined its own set of possibilities.
I wish it were easier to set up; I think if that were the case, we'd see a lot more utilities with spot-on tab completion.
> 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.
"Do you want to do this (Y/n)?"
Where the most common option is uppercase so I can just hit enter.
It's rather like the Plan 9 convention of programs returning strings instead of ints when then terminate; an empty string means success, a non-empty string contains the error message. I wish other OSes had adopted that.
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)
joey@gnu:~>true
joey@gnu:~>false
zsh: exit 1
I'm also working on a project where by entering "?" at any interactive section you're taken to an interactive help menu. From here you can query (amongst other things) the state of the program, something that isn't always clear when you're using command line software, as you can't have extra info somewhere in the corner or whatever.
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).
-- http://wiki.g2.bx.psu.edu/Admin/Tools/Tool%20Config%20Syntax
That's disappointing, I was hoping I'd learn how vi, etc. worked from this, since I know nothing about writing command line interfaces other than input and output to the last column of the last line of the terminal. Does anyone know of a good article/introduction to this?
- Don't make the user reach for distant keys like escape or pagedown/pageup (also support ^N/^P or ^B/^F) or the arrow keys (also support hjkl), unless you really need to.
- For one-line text entry, support readline bindings (^W, ^U, ^Y, ^B, ^F, etc.)
- If you show a list, provide a way to search for an item rather than moving through the list item by item or page by page.
- Unless there is a good reason not to, spawn $PAGER to show text and $EDITOR to edit text.
- If there is a finite set of actions to choose from, provide one-key hotkeys for each one. Don't require unnecessary use of the control key. Optionally show the list of possible or common actions, but have an option to hide it and save screen space for users who don't need it anymore (like mutt does). Likewise, if there are several items that can get focus, provide hotkeys, don't require the user to Tab their way through all of them.
Obviously, there are more.
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.
How did I never know that before?
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.
This is what the -v, --verbose option is for. Without this flag, you should assume everything is operating as expected until you receive an error message or an exit status >0.
That's something that's always annoyed me about screen; commands such as "wipe" are "screen -wipe"
* 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