On Tue, Feb 5, 2013 at 2:01 AM, Dave Reisner <d@falconindy.com> wrote:
On Tue, Feb 05, 2013 at 01:44:28AM +0100, Sébastien Luttringer wrote:
Colors initialization was called after arg parsing. This disallow error messages and options called directly from arg parser to use colors. By example, call `mkinitcpio -k toto' or `mkinitcpio -L'.
-k isn't immediately processed, btw. This isn't a valid example. It's potentially true only of -g, -H, -L, and -P.
This patch initialize colors when terminal is able to support it but disable it if users don't wants it (with -n).
Signed-off-by: Sébastien Luttringer <seblu@seblu.net> ---
I'm starting to have second thoughts about this patch. It means that you could potentially have color or not based on the order of the flags passed. That is...
$ mkinitcpio -L -n # this will be in color $ mkinitcpio -n -L # this will not be in color
I tend to think missing out on color for a small number of options versus this inconsistent behavior isn't worthwhile. I could look into some refactoring so that the 4 options I mention above are colorized properly, after arg parsing is done. It's probably equally wrong to be doing work straight out of arg parsing. I agree. Re-factoring is a better solution!
-- Sébastien "Seblu" Luttringer https://www.seblu.net GPG: 0x2072D77A