[the coreutils portion of this email starts half-way down]

On 06/14/2010 01:45 PM, Ralf Wildenhues wrote:
> Hi Eric,
> 
> quoting your reply out of order:
> 
> * Eric Blake wrote on Mon, Jun 14, 2010 at 07:22:31PM CEST:
>> On 06/13/2010 12:50 AM, Ralf Wildenhues wrote:
>>> The logical next step for Autotest to be on par with Automake's
>>> parallel-test.
>>>
>>> Unlike Automake, the testsuite author does not have to do anything for
>>> the user to be able to use color; AT_COLOR_TESTS only changes the
>>> default to yes.  We could easily let it accept an optional argument, if
>>> you think it is useful.
>>
>> I'm debating whether:
>>
>> AT_INIT([testsuite])
>> AT_COLOR_TESTS
> 
> This currently does not work:
> 
>> Did you make sure that AT_COLOR_TESTS can be specified either side of
>> AT_INIT, or is there a fixed invocation order that authors must be aware of?
> 
> Right now it has to be specified before AT_INIT.  If there's a diversion
> thinhy we can easily fix that with, great, otherwise I guess it would
> need documentation and order warning in the code.  Help?

It seems like it would merely be a matter of unconditionally emitting
at_color=no in an early diversion, and having AT_COLOR_TESTS emit
at_color=auto in an intermediate diversion, all before the option
parsing that appears in a later diversion.  That way, if the user didn't
specify --color, they pick up the appropriate default.

That also implies that anything else that checks at m4-time whether
AT_color is defined (such as your m4_ifdef for changing the --help
output text) must be m4_wrap'd to delay any output based on that
decision of AT_color until after the user's source file has been
completely read in.  Then again, we already m4_wrap some of our --help
text in order to accurately tell the user how many AT_SETUPs we
encountered, so this may already be taken care of given the current
architecture of autotest.

I'll see if I can get some time to help you figure that out, if that
wasn't enough of a hint.

>> Personally, I like tri-state color options: --color=no or --color=never
>> to disable, --color=yes or --color=always to enable, and --color=auto or
>> the simpler --color to depend on tty status.  Are you making 'yes' a
>> synonym for 'always' or for 'auto'?  Should we support other common
>> synonyms?
> 
> I meant yes=auto.  I realize this is different from how ls does it, and
> I'm fine with doing it another way.

My quick testing shows that when directed to a tty, both ls and grep
treat all four of '--color', '--color=auto', '--color=yes', and
'--color=always' as a command to turn on color.  More interesting is
collecting the output:

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.

It's probably worth a bug report to coreutils (cc'd), since I prefer the
grep behavior.  Should we also raise a bug against the GNU Coding
Standards to codify a preferred variant?

>  I'm also fine with 'never' and
> 'auto' as additional synonyms.  However, I very much think that if some
> option --foo[=ARG] accepts no and yes and other arguments, then yes
> --foo should be a synonym for --foo=yes, not anything else.

So you are arguing yet a third behavior from either coreutils or grep,
which is that --color implies --color=yes, but that yes is an alias for
'auto' rather than 'always'.  I could see your behavior making sense as
well.  But again, it argues for standardization among GNU projects.

Any other examples we can look at, to see if there is already a majority
in behavior?

>> I don't know how to easily detect ascii vs. ebcdic ESC (which is a
>> different encoding); \e and \E escapes are common, but non-portable.
> 
> Is there any chance that an EBCDIC system accepts ANSI terminal color
> escape sequences?  If not, then what would be the equivalent there?
> Am I confusing different entities here?

I have no idea of anyone that uses an EBCDIC system that also uses
terminal escape sequences.  Let's just go with hard-coding ASCII and
wait for the bug reports (after all, we DID get some bug reports, along
with a patch, about one use of m4_translit in 2.65, which have already
been applied to make autoconf.git more EBCDIC-friendly).

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