13

Is there a style guide to writing command line applications' arguments on unix platforms? Coming from the iOS world I'm thinking of something akin to the Human Interface Guidelines (HIG). I'm writing a script in Python that can take parameters.

Example: How to name arguments, when to use -dash or --doubleDash.

1
  • 3
    Use argparse module for your argument parsing stuff, it's easy to use and it more or less forces you to have a good style for your CLI. docs.python.org/dev/library/argparse.html Commented Aug 31, 2011 at 1:45

3 Answers 3

9

Look at this standard library module: http://docs.python.org/library/argparse.html

It will make your life much easier implementing a command line interface, and you end up using its style guide.

Note that argparse only became available in Python 2.7 (or 3.2, in the 3.x series). Before that there was http://docs.python.org/library/optparse.html, which results in a similar command line interface, but is not as much fun to use.

Sign up to request clarification or add additional context in comments.

6 Comments

Yes, but what about the syntax of the arguments and naming them?
@JoePasq: I doubt there's anyone's formally written up naming conventions, but it would help to look at the options used by GNU coreutils.
You're locked into the syntax of the arguments by argparse. It gives you positional parameters, single letter arguments like -a -b -c (that can be grouped like -abc), and long arguments like --long. I'm not sure there are naming conventions for command line arguments, or that there even could be at more than a vague level.
Welp. the different argument parsing modules out there basically define the standards. Some of them have legacy support -- if you need to, they will allow you to use a single dash before a long option name, or a plus instead of the dash -- but you should let the default behavior of a reasonably modern option parsing library should be your guidance.
There are a few naming conventions, most of which can be found in the manual pages of popular commands. Some examples are -h or --help (display a synopsis of command syntax and then exit), -V or --version (display the version number and then exit), -v or --verbose (provide extra information on standard error about what the command is doing), -q or --quiet (produce less output), -d or --debug (provide debugging information on standard error), -n or --dry-run (provide information on what the command would do instead of actually doing it), etc.
|
7

The GNU Coding Standards have a section on command line programs.

For a posixy feel, you shouldn't only provide the standard command line options, both short and long, but also, if possible, adhere to reading from the standard input (or the command line) and writing to the standard output, and only overriding the output with an option (like -o/--output). That's what one expects of most GNU command line tools.

Comments

6

Read The Art of Unix Usability http://www.catb.org/~esr/writings/taouu/taouu.html

Comments

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.