On 06/17/2010 01:06 PM, Ralf Wildenhues wrote:
> * Pádraig Brady wrote on Tue, Jun 15, 2010 at 11:50:01AM CEST:
>> On 14/06/10 21:23, Eric Blake wrote:
>>> ls --color => color
>>> ls --color=yes => color
>>> ls --color=auto => plain
>>> ls --color=always => color
>>> grep --color => plain
>>> grep --color=yes => color
>>> grep --color=auto => plain
>>> grep --color=always => color
>>>
>>> That is, ls --color implies ls --color=always, while grep --color
>>> implies grep --color=always.
>>
>> grep --color=auto you mean.

Yep, sorry for my typo.

> I don't know either.  However, I also think Autotest need not wait for
> standardization in order to gain color support.  We can still fix the
> details later.

True enough.

> 
>> ls has these synonyms:
>>
>>   "always", "yes", "force",
>>   "never", "no", "none",
>>   "auto", "tty", "if-tty", NULL
>>
>> We only document the first column which is a good thing.
> 
> I agree, and implemented that in the updated patch.
> 
> The patch below has --color equal --color=always.  Since I'm less
> concerned about this detail than about the fact that the patch may not
> go in at all, I'm adding a second patch, to be squashed in with the
> first, if you prefer --color to be equal to --color=auto.
> 
> OK to commit 1 or 1+2?

For now, let's match ls (--color equals --color=always, patch 1 only),
and you are free to push after fixing one nit:

> +    --color )
> +	at_color=always
> +	;;
> +    --color=* )
> +	case $at_optarg in
> +	no | never | none) at_color=never ;;
> +	auto | tty | if-tty) at_color=auto ;;
> +	always | yes | force) at_color=always ;;
> +	esac

Let's add a *) option and cause a fatal error if we don't recognize the
argument given to the --color option.

-- 
Eric Blake   eblake@redhat.com    +1-801-349-2682
Libvirt virtualization library http://libvirt.org