>in CVS HEAD we already have --no_log_color, but that isn't enough
>since this doesn't address at all 1) and considering 2)
>we can have this situation:
>
>transcode --no_log_color -V yuv420p [...]
> gives sane behaviour
>transcode -V yuv420p --no_log_color [...]
> doesn't work as expected.
>
>I see two solutions for this:
>a) drop tc_log_* in options processing, fallback to fprintf(stderr, ...)
>(I don't like this soo much)
>b) process --no_log_color outside main option loop, before any other option,
>then remove processed options from argc/argv[] (if found), last go on
>with standard option processing loop.
Yes, I'd agree with this too. 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.
>Finally, we must address sub-issue 1).
>I see two ways here too:
>a) adding a command line option to every tc-tool like transcode (boring,
>error prone, much code needs to be modified)
>b) using an environment variabile to control log colorized output.
>Maybe a little less clean but effective.
>
>I like b) most even here.
That seems reasonable to me as well.
--Andrew Church
[EMAIL PROTECTED]
http://achurch.org/
