[arch-projects] [MKINITCPIO][PATCH 1/2] Fix colors display in some options

Sébastien Luttringer seblu at seblu.net
Mon Feb 4 20:14:02 EST 2013

On Tue, Feb 5, 2013 at 2:01 AM, Dave Reisner <d at 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 at 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
GPG: 0x2072D77A

More information about the arch-projects mailing list