Andrew Church wrote: > > ... In a more general sense, it might be > good to do two passes over the entire command line, where the first one > just picks up critical options (like --no_log_color) and has tc_log_*() > disabled entirely, and the second one does normal option processing. That > way, when you have an option that needs early processing but can also > generate syntax errors (like --export_profile), you can have it respond on > both passes: in the first pass it saves the value or error, and if there > was an error it logs it during the second pass. > > Another possibility would be to give every option a priority, and > ensure that --no_log_color has the highest priority, but I'm not too fond > of that idea because it leaves open the possibility that someone could > later add an option with an even higher priority without realizing the > consequences of doing so.
I think the mistake here is in applying coloring to stderr. Messages on stderr should avoid the use of control sequences that may obscure meaning on some terminals or redirection targets. There should not be any options that require "early processing"... All options should be parsed and syntactically validated, and errors should be reported against invalid syntax before any other action is taken.
