Kinda true, but in a typical shell script (or even any other kind of program) there aren't many user controlled variables that would typically be incorporated d

Kinda true, but in a typical shell script (or even any other kind of program) there aren't many user controlled variables that would typically be incorporated directly into a command invocation. Pathname expansions are the most common and likely vector because it's common to both introspect directory trees and then pass those file paths as arguments to other utilities. That's why I always put a line like set -f # disable pathname expansion at the top of my shell scripts, in addition to several other settings (e.g. -e, -u, and -C). Because file globbing is a common operation in shell scripts I invariably have to re-enable it locally (e.g. set +f; set -- *; set -f; for F; do ...; done) somewhere. That extra work reinforces that pathnames are tainted, making it easier to remember to use the "--" option argument terminator where ever else I pass file names--particularly names not statically defined in the script--whether they come from globbing or some other route. As an aside, I really dislike GNU-style argument vector permuting, where getopt/getopt_long rearranges "cmd foo bar -x" to be "cmd -x foo bar". On BSD doing something like 'ls /tmp "$X"', where X is user controlled, is relatively safe because "/tmp" terminates option parsing. Not so with GNU getopt. I get the convenience of permuting the vector, but I just don't think it's worth the cost in terms of security (it's a dangerously nuanced semantic) or in terms of the size of the GNU getopt/getopt_long implementation (it could be many times simpler and shorter, not to mention requiring only a constant amount of work and memory, but-for the permuting).