join is inconsistent with other utils (like cut, for example) in how it handles a specification of a switch value that has already been set.
1) if a switch is set more than once with the same value, it doesn't complain, but if the options differ, unlike utilities like 'cut', the tool dies rather than taking the final specification as what is meant. ex: cut -d'<TAB>' -d: -f1 </etc/passwd doesn't issue any errors. But the same thing with join: join -t'<TAB>' -t: -f1 /etc/passwd /etc/group join: incompatible tabs ??? tabs? they are field separators. Historically, options specified on the command line take precedence over options in an init/rc-file or in the ENV. Many utils in a build process build up command lines in pieces -- with the expectation that later values take precedence, allowing for higher level make files to set defaults, while allowing make's in sub directories to override options set in a parent. Defaulting to "fail", rather than proceed with latest input data, is rarely useful for humans. It's arguable whether or not it is useful for machines in most cases. In the past, unix utils have tried to do what the user meant rather than deliberately playing "stupid" and pretending to have no clue about what was likely expected.
