Are There Standards for Linux Command Line Switches and Arguments

Are there standards for Linux command line switches and arguments?

Generally, yes.

• IEEE
• GNU getopt

Is there a standard format for command line/shell help text?

Typically, your help output should include:

• Description of what the app does
• Usage syntax, which:
  
  
  • Uses [options] to indicate where the options go
  • arg_name for a required, singular arg
  • [arg_name] for an optional, singular arg
  • arg_name... for a required arg of which there can be many (this is rare)
  • [arg_name...] for an arg for which any number can be supplied
  • note that arg_name should be a descriptive, short name, in lower, snake case
• A nicely-formatted list of options, each:
  
  
  • having a short description
  • showing the default value, if there is one
  • showing the possible values, if that applies
  • Note that if an option can accept a short form (e.g. -l) or a long form (e.g. --list), include them together on the same line, as their descriptions will be the same
• Brief indicator of the location of config files or environment variables that might be the source of command line arguments, e.g. GREP_OPTS
• If there is a man page, indicate as such, otherwise, a brief indicator of where more detailed help can be found

Note further that it's good form to accept both -h and --help to trigger this message and that you should show this message if the user messes up the command-line syntax, e.g. omits a required argument.

Are there any standard Command line conventions for dashes and arguments?

Read up on the background section of Python's optparse module, it answers some of your questions and exemplifies with some common argument formatting standards seen in the wild. The optparse module author recommends a style that roughly corresponds to the POSIX conventions for command line arguments, with the addition of --double-dashed-long-arguments which comes from the GNU coding standard.

How to denote that a command line argument is optional when printing usage

I personally have not seen a 'standard' that denotes that a switch is optional (like how there's a standard that defines how certain languages are written for example), as it really is personal choice, but according to IBM's docs and the Wiki, along with numerous shell scripts I've personally seen (and command line options from various programs), and the IEEE, the 'defacto' is to treat square bracketed ([]) parameters as optional parameters. Example from Linux:

ping (output trimmed...)

usage: ping [-c count] [-t ttl] host

where [-c count] and [-t ttl] are optional parameters but host is not (as defined in the help).

I personally follow the defacto as well by using [] to mean they are optional parameters and make sure to note that in the usage of that script/program.

I should note that a computer standard should define how something happens and its failure paths (either true fail or undefined behavior). Something along the lines of the command line interpreter _shall_ treat arguments as optional when enclosed in square brackets, and _shall_ treat X as Y when Z, etc.. Much like the ISO C standard says how a function shall be formed for it to be valid (otherwise it fails). Given that there are no command line interpreters, from ASH to ZSH and everything in between, that fail a script for treating [] as anything but optional, one could say there is not a true standard.

How to send both command line arguments and standard inputs to a program from a shell script

If I understand your situation correctly, it seems to be saying that you would like to use both command line parameters while also being able to pipe input into the same program as if typed from the standard input.

If so, then the solution is simple. You can do both at the same time:

echo "some input" | ./myprogram arg1 arg2

Parameters for a program are handled separately from STDIN. Therefore, there's no conflict. The C++ program would handle the parameters as an array passed into main(), and it would handle the input piped to it through a stream coming from STDIN.

It is up to the program itself to determine when and how it process that information. It is entirely possible that it could check first for STDIN. If it is the case that you need to delay your piped input, you might consider using the expect command. Fortunately, it is common convention to handle the command line parameters first before moving on to do other things, such as checking for input, so the above should work in most cases.

Command line parameters, standard aproach to parse?

On systems like Linux, there is the convention that options that are full words use two dashes (e.g. --file), while single-letter options use a single dash (e.g. -f.)

Using slash to introduce options is from old DOS, and is being kept in Windows.

Also, if an option is using a whole word, it can not be split into several options. This is in regards to your example with -file: -file can either be one option, or four different options (-f, -i, -l and -e).

All in all, how options looks, or is handled, differ very much between programs, and there really isn't any specific standard.

I would suggest you find some way you like, and then use that.

Is there a standard pattern for writing a linux command-line utility in C++?

The POSIX guidelines for utilities are here and conventions succinctly described here. GNU extensions are common and I think pretty much expected on Linux.

Jonathan Leffler wrote a nice answer here which delves into some of this as well.

---

Related Topics