Skip to content

Instantly share code, notes, and snippets.

@scop
Last active January 25, 2026 20:44
Show Gist options
  • Select an option

  • Save scop/16da5b0cf27acf2a751a1d5b740bb854 to your computer and use it in GitHub Desktop.

Select an option

Save scop/16da5b0cf27acf2a751a1d5b740bb854 to your computer and use it in GitHub Desktop.
Executing commands in programs

Use --long-options if available. These are typically clearer to readers than short ones. They do make the command line longer than corresponding short ones, but in practice this is very rarely, if ever, a problem.

Use equals sign rather than space between a long option and its argument, if available, like --long-option=argument rather than --long-option argument. This is also for clarity as it's immediately clear that the argument is for the option rather than a positional argument for the command, and doing so tends to support pathological option argument cases starting with dashes better. It also renders better (subjective?) in many cases involving linefeeds, such as in various config file format and programming language arrays.

Always separate positional arguments from option/flag ones if the program provides a way to do it. Typically this is available with --. Doing so also supports pathological cases like in above, but can in some cases prevent security issues, e.g. arbitrary command execution by providing "filename" arguments that without the -- separator get treated as options that invoke user specified commands.

Following these practices in interactive command line usage would be a good habit too, but can be a bit of a chore e.g. if let's say a shell completion skips adding the equals sign and instead appends a space after an option. And the above mentioned separator is actually rarely needed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment