I think that this is a false opposition thing: they're all good, and you should have all of them. Command-line parameters, especially single character ones, ar

I think that this is a false opposition thing: they're all good, and you should have all of them. Command-line parameters, especially single character ones, are a quick and easy way to request ad hoc changes of program behavior. They're also common across many utilities, so you can expect that -d to display debugging output, and -h to be a hostname, -p to be a port number, -n to do a dry-run, etc. Configuration files are good for persistent, per-program settings. If you always want altered behavior, a configuration file is easier than constantly adding command-line options. Note that this implies that command-line options should override configuration file options, and that a --no-foo variant can be useful. Environment variables are good for long-term, multi-program configurations: EDITOR, DISPLAY, LANG, PAGER, TERM, etc. It can be good to have these available as command-line options (eg. -display, for Xt-based apps), but generally it's ok to override them with env FOO=bar program. Also of note: container orchestration systems are generally able to set environment variables, but might not be able to create (and later remove) a configuration file. So ... it's often not the case that every program option should have all three means of control, but most programs should use all three mechanisms, depending on what type of optional behavior is being controlled.