A few more things on the subject:

When secrets are passed as argument they are discoverable by any process on the machine. Instead, it should be good form to only accept paths to secrets as arguments and rely on the POSIX filesystem to enforce ACL.

The flag parser should convert empty values to defaults if there is one. For example if the default user is root and $USER is empty, -user "$USER" would default as root. This is necessary to avoid having all the users of the CLI find out about the default and re-expand it in their script with "${USER:-root}".

For more complex cases where a configuration file starts being needed, I have seen a few using the command-line args as the configuration format. This has the advantage to enforce that all configuration options will also be overridable with the command-line.

I’m a big fan of this style but with a couple of additions. In particular, I like to have variables that, when set, pass their values to the flags, and when not set, just don’t exist in the command line arguments. An example:

#!/bin/bash
# File: foo.sh

type=${type:-f}
dir=${1?:need a directory}

find "$dir" ${type:+-type "$type"} "$@"

# Usage:
#   ./foo.sh mydir  # find files in mydir
#   type=d ./foo.sh mydir # find directories in mydir
#   ./foo.sh mydir -exec wc -l +  # count lines in files in mydir
#   ./foo.sh  # error: need a directory

The trick is using ${variable:+--flag "$variable"} which, if $variable is unset, expands to nothing, but if set, it expands --flag "$variable". Another example for docker is:

#!/bin/bash
# File: docker.sh

data=/mnt/data

docker run -it --rm ${data:+-v "$data:$data"} "$@"

# Usage: ./docker.sh hello-world

This will run whatever container interactively and with the /mnt/data directory (but if you edit the file to remove the data= then it will not mount it).

(I talked about the Docker approach more at https://mediocreatbest.xyz/1/ if you’re interested)

I totally agree, but mostly for a reason not listed in the article: if flags are the primary way to configure your program, then program -h is an authoritative and easy-to-use way to review the complete configuration “surface area” available to users. Config files and env vars both lack this automatic discoverability.

After many years of futzing about and trying to find the best approach, I’ve written a configuration parsing package for Go which IMO captures the best of all worlds. peterbourgon/ff (ff for flags-first) hooks onto a stdlib flags.FlagSet, but allows you to optionally parse each flag from a config file or an env var, too, in that priority order. (Explicit flags always take precedence.) So you keep the discoverability, without giving up the usability of other options in situations where they make sense.

That’s a fun subject to think about, and I enjoyed reading your thoughts. When thinking about configuration, I find it useful to consider how often it varies: (a) per invocation, (b) per use case, or (c) per user? (There are other levels such as ‘per site’ or ‘at runtime’, but these will do for now.)

To set config per invocation (a), parsing flags and arguments is fine, and I agree with the author that they’re somewhat nicer than environment variables.

To set config per user (c), I really like config files. I can slowly grow my pool of personal tweaks in one place, add comments, keep them in my dotfiles, and share them with others. Some config files are set-and-forget, like for elinks or Readline. The config files I interact with most are Vim, Mercurial, and my shell, all programs that allow extending their vocabulary and defining new commands.

To set config per use case (b), retyping the same flags over and over can get tedious even if they’re short, such as the -Tpng to make graphviz emit a PNG file. Config files are obviously out because then you have to repeatedly specify which config file. Here, the ideal is a program that supports flags, and a wrapper script for each use case. For example, I have a graphviz wrapper script dot2png that ultimately comes down to dot my_input -Tpng -o my_output.png. I’d hate for that script to need to edit a config file on the fly.

I agree with you in spirit but in practice I find this logic to be questionable.

Why? Because humans make mistakes with command line invocations, and every decision point that can be removed from the tired human running ./save_or_destroy_the_world.py at 3 AM when their pager goes off is priceless.

Flags a weird that in some sense they take the place of metadata, while they are just as much text as anything else. I guess getopt helps to hide this mysticism. This causes quite a lot of inconsistencies, -v, -v [necessary arg], –verbose, –verbose [necessary arg], –verbose=[not-necessary arg], etc. could all be used, but aren’t interchangable, even though one could imagine a shell that understands all these notations and generally configures/passes the values to a program. Maybe even do type-checking automatically?

For my own blog, I use a system like flags to pass arguments to the blog system, and I’ve taken the convention to declare boolean properties with a prepended : (eg. :syntax) while properties with values start with = (eg. :next part32.html). Seems more clean.