Interesting question. I think I may have the answer (at least for Unix). (IIRC had read about this somewhere a while ago, also had thought about this issue mys

Interesting question. I think I may have the answer (at least for Unix). (IIRC had read about this somewhere a while ago, also had thought about this issue myself earlier, so it's a combo of reading the reason somewhere and (maybe) figuring it out. Anyway, here it is: It is because it allows 3 different ways of setting options for commands: rc files, environment variables (env. vars from now) and command line arguments, with each subsequent one able to override the previous one. The logic being that they go, in order, from more permanent to less permanent (as settings). rc files (rc stands for run command, a term I think I read Unix inherited from some previous OS) are config files for commands, like .exrc and .vimrc for vi/vim, .bashrc for bash, .netrc and many more. Any command can create or require users to create its own rc file, and can use it if present to read settings. The setting in a file is less easy to change on the fly than an env. var (not really difficult, of course, just that you have to go edit that file in an editor - or use sed etc.), and an env. var in turn is (a bit) less easy to change than a command line option, when we are talking about multiple different invocations of a command, in which you want the values for that option to be different in some of the invocations. Let's take the example of a setting for a port (for a network server or client): First, put the most common and permanent setting for the option, say, PORT=8080, in the rc file, say .foorc (for command foo - whether foo is built-in or written by you). Second, for times when you want to change it for say today's work, set (i.e. change) it via an env. var, like: export PORT=8181 foo args ... # this setting will remain in effect until you change the var or you logout/reboot, and as long as it is present, will override any PORT value in .foorc each time you run foo. It can also be shortened to: PORT=8181 foo args ... # but this is now a one-time setting of the env. var, so will override any PORT value in .foorc for this run only. # In both the above variants, the args will not include PORT, since the foo command will be written to check for an env. var called PORT internally (and similarly checks for a PORT setting in .foorc before checking for an env. var called PORT, with the latter overriding the former if both are present). And third, for the time(s) when you want to change the PORT setting on the fly, maybe just once for today, do: foo --port 8282 args which will override the settings for port (if any) in both the rc file and the env. var. So the order is: command line option overrides env. var. and env. var overrides rc file setting. This is what I read/figured out. It gives a lot of flexibility. Many Unix commands work that way. If you want your own to work that way, you have to write the code for it, like checking for presence of the rc file and for the setting in it, checking for the env. var with getenv() and finally checking for the command line option. Edit: for typos.