On 12/1/06, Phil Ehrens <[EMAIL PROTECTED]> wrote:
Messages on stderr should avoid the use of control sequences that may obscure meaning on some terminals or redirection targets.
I partly agree. To explain, I agree considering this behaviour sane in the general case, but I don't see any other straightforward way to improve things *for transcode*, and that's especially true for the short term (1.1.0). As Andrew pointed out, very few pieces of transcode emits program-friendly output/log messages, and this situation will not improve in short term ( 1.1.0). So, for users, colored logging is helpful. Some frontends can be drive crazy by that, so the need for --no_log_color emerge[1] We use stderr since stdin/stdout is already used by tc* tools for IPC, so there isn't much choice left :\ 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.
Same as above; while I surely agree that this the way to go in theory, I 101% agree with Andrew here too. Doing checks on the fly is mabye less clean, but allow us to save a lot of code and buffering space, since transcode can eat A LOT of options (and combinations of them). +++ [1] In facts, I've received request to disable colorized logs from a guy which's writing a frontend for transcode. I think that can be useful for dvd::rip too :) Bests, -- Francesco Romani
