GNU logs - #6427, boring messages


Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#6427: Autotest: enable colored test results.
Resent-From: Eric Blake <eblake@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Mon, 14 Jun 2010 20:26:02 +0000
Resent-Message-ID: <handler.6427.B.12765471098432 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 6427
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: autoconf-patches@HIDDEN, 6427 <at> debbugs.gnu.org
X-Debbugs-Original-To: autoconf-patches@HIDDEN, bug-coreutils <bug-coreutils@HIDDEN>
Received: via spool by submit <at> debbugs.gnu.org id=B.12765471098432
          (code B ref -1); Mon, 14 Jun 2010 20:26:02 +0000
Received: (at submit) by debbugs.gnu.org; 14 Jun 2010 20:25:09 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1OOGDV-0002Bx-AN
	for submit <at> debbugs.gnu.org; Mon, 14 Jun 2010 16:25:09 -0400
Received: from mx10.gnu.org ([199.232.76.166])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <eblake@HIDDEN>) id 1OOGDS-0002BY-Mc
	for submit <at> debbugs.gnu.org; Mon, 14 Jun 2010 16:25:08 -0400
Received: from lists.gnu.org ([199.232.76.165]:53650)
	by monty-python.gnu.org with esmtps
	(TLS-1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.60)
	(envelope-from <eblake@HIDDEN>) id 1OOGDO-0007Bj-Jc
	for submit <at> debbugs.gnu.org; Mon, 14 Jun 2010 16:25:02 -0400
Received: from [140.186.70.92] (port=50224 helo=eggs.gnu.org)
	by lists.gnu.org with esmtp (Exim 4.43) id 1OOGDL-00051U-V2
	for bug-coreutils@HIDDEN; Mon, 14 Jun 2010 16:25:01 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI,
	T_RP_MATCHES_RCVD autolearn=unavailable version=3.3.1
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69)
	(envelope-from <eblake@HIDDEN>) id 1OOGDK-0002zG-FF
	for bug-coreutils@HIDDEN; Mon, 14 Jun 2010 16:24:59 -0400
Received: from mx1.redhat.com ([209.132.183.28]:62890)
	by eggs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <eblake@HIDDEN>)
	id 1OOGDG-0002yN-TX; Mon, 14 Jun 2010 16:24:55 -0400
Received: from int-mx05.intmail.prod.int.phx2.redhat.com
	(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5EKOqjU031792
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Mon, 14 Jun 2010 16:24:52 -0400
Received: from [10.3.224.215] (vpn-224-215.phx2.redhat.com [10.3.224.215])
	by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id o5EKOpJs029983; Mon, 14 Jun 2010 16:24:52 -0400
Message-ID: <4C168FD7.7000001@HIDDEN>
Date: Mon, 14 Jun 2010 14:23:51 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre
	Mnenhy/0.8.2 Thunderbird/3.0.4
MIME-Version: 1.0
References: <20100614194523.GD22568@HIDDEN>
In-Reply-To: <20100614194523.GD22568@HIDDEN>
X-Enigmail-Version: 1.0.1
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="------------enig6FD271176F9DE0CA7A8A846F"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18
X-detected-operating-system: by eggs.gnu.org: Genre and OS details not
	recognized.
X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6,
	seldom 2.4 (older, 4)
X-Spam-Score: -6.4 (------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -7.7 (-------)

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enig6FD271176F9DE0CA7A8A846F
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

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

On 06/14/2010 01:45 PM, Ralf Wildenhues wrote:
> Hi Eric,
>=20
> quoting your reply out of order:
>=20
> * 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 fo=
r
>>> 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
>=20
> This currently does not work:
>=20
>> 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 awa=
re of?
>=20
> Right now it has to be specified before AT_INIT.  If there's a diversio=
n
> 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=3Dno in an early diversion, and having AT_COLOR_TESTS emit
at_color=3Dauto 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=3Dno or --color=3D=
never
>> to disable, --color=3Dyes or --color=3Dalways to enable, and --color=3D=
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?
>=20
> I meant yes=3Dauto.  I realize this is different from how ls does it, a=
nd
> 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=3Dauto', '--color=3Dyes', and
'--color=3Dalways' as a command to turn on color.  More interesting is
collecting the output:

ls --color =3D> color
ls --color=3Dyes =3D> color
ls --color=3Dauto =3D> plain
ls --color=3Dalways =3D> color
grep --color =3D> plain
grep --color=3Dyes =3D> color
grep --color=3Dauto =3D> plain
grep --color=3Dalways =3D> color

That is, ls --color implies ls --color=3Dalways, while grep --color
implies grep --color=3Dalways.

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[=3DARG] accepts no and yes and other arguments, then yes
> --foo should be a synonym for --foo=3Dyes, not anything else.

So you are arguing yet a third behavior from either coreutils or grep,
which is that --color implies --color=3Dyes, 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.
>=20
> 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).

--=20
Eric Blake   eblake@HIDDEN    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


--------------enig6FD271176F9DE0CA7A8A846F
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJMFo/bAAoJEKeha0olJ0NqR6kH/2XcY/VQK9qvcWRzEfUa2W46
qv6ypNHTOC4X42K5TeARjYX1xFhhHAMfcHV9dw0GyaQdMVpVoyP7G8E3s4YOE1fo
K/C4QiMFPhwRiLKpjv+RpWmzjV3vbjoehmLyIXg92QhWk1RQN8lw2+R+UXFmZHYe
HhLQKmZhUE6zYBvk/SLxgePt/OmIIvM7UxTxPZZNeiLtUi2eGzjpn5W6/U54ZWq8
+Orm6+DnEJDlOHhhuCkfcrRk1+l34wQq/8HYrwllyBx1cOY3xyGRNQRcdR88U+8c
/0zmocJgL+/s0IU4/mySpwH+eNBYLTDK1BcbrbdBaO7HLQNUNcnQAGaTRjLJFAA=
=mCGX
-----END PGP SIGNATURE-----

--------------enig6FD271176F9DE0CA7A8A846F--




Message sent:


Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Eric Blake <eblake@HIDDEN>
Subject: bug#6427: Acknowledgement (Autotest: enable colored test results.)
Message-ID: <handler.6427.B.12765471098432.ack <at> debbugs.gnu.org>
References: <4C168FD7.7000001@HIDDEN>
X-Gnu-PR-Message: ack 6427
X-Gnu-PR-Package: coreutils
Reply-To: 6427 <at> debbugs.gnu.org
Date: Mon, 14 Jun 2010 20:26:02 +0000

Thank you for filing a new bug report with GNU.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-coreutils@HIDDEN

If you wish to submit further information on this problem, please
send it to 6427 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
6427: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D6427
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems


Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#6427: Autotest: enable colored test results.
Resent-From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Tue, 15 Jun 2010 09:52:02 +0000
Resent-Message-ID: <handler.6427.B6427.127659548032304 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 6427
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: Eric Blake <eblake@HIDDEN>
Cc: 6427 <at> debbugs.gnu.org, autoconf-patches@HIDDEN
Received: via spool by 6427-submit <at> debbugs.gnu.org id=B6427.127659548032304
          (code B ref 6427); Tue, 15 Jun 2010 09:52:02 +0000
Received: (at 6427) by debbugs.gnu.org; 15 Jun 2010 09:51:20 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1OOSnf-0008Oz-Ky
	for submit <at> debbugs.gnu.org; Tue, 15 Jun 2010 05:51:19 -0400
Received: from mail1.slb.deg.dub.stisp.net ([84.203.253.98])
	by debbugs.gnu.org with smtp (Exim 4.69)
	(envelope-from <P@HIDDEN>) id 1OOSnd-0008Os-6v
	for 6427 <at> debbugs.gnu.org; Tue, 15 Jun 2010 05:51:18 -0400
Received: (qmail 80109 invoked from network); 15 Jun 2010 09:51:14 -0000
Received: from unknown (HELO ?192.168.2.25?) (84.203.137.218)
	by mail1.slb.deg.dub.stisp.net with SMTP; 15 Jun 2010 09:51:14 -0000
Message-ID: <4C174CC9.1040201@HIDDEN>
Date: Tue, 15 Jun 2010 10:50:01 +0100
From: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US;
	rv:1.9.1.8) Gecko/20100227 Thunderbird/3.0.3
MIME-Version: 1.0
References: <20100614194523.GD22568@HIDDEN> <4C168FD7.7000001@HIDDEN>
In-Reply-To: <4C168FD7.7000001@HIDDEN>
X-Enigmail-Version: 1.0.1
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 8bit
X-Spam-Score: -1.4 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -2.7 (--)

On 14/06/10 21:23, Eric Blake wrote:
>>> 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.

grep --color=auto you mean.

> 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?

Yes I prefer the grep behavior, but I'm not sure we can
change ls at this stage?

>>  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.

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.

> 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).

I've wondered about how general the color codes we use are.
Using termcap/terminfo would be most general but since
we've had no reports about it yet I think we should stick
with the simple hardcoded scheme.

I.E. the following currently outputs colors:

  TERM=dumb ls --color=auto

The l¹ script I use to wrap `ls` works around
this "limitation" by essentially doing:

  if ! tput setaf 1 >/dev/null 2>&1 && ! tput AF 1 >/dev/null 2>&1; then
    color_when=never
  else
    color_when=auto
  fi
  ls --color=$color_when

cheers,
Pádraig.

¹ http://www.pixelbeat.org/scripts/l




Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#6427: Autotest: enable colored test results.
Resent-From: Eric Blake <eblake@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 17 Jun 2010 19:56:01 +0000
Resent-Message-ID: <handler.6427.B6427.127680453515031 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 6427
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>, 6427 <at> debbugs.gnu.org,  autoconf-patches@HIDDEN
Received: via spool by 6427-submit <at> debbugs.gnu.org id=B6427.127680453515031
          (code B ref 6427); Thu, 17 Jun 2010 19:56:01 +0000
Received: (at 6427) by debbugs.gnu.org; 17 Jun 2010 19:55:35 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1OPLBU-0003uN-D5
	for submit <at> debbugs.gnu.org; Thu, 17 Jun 2010 15:55:34 -0400
Received: from mx1.redhat.com ([209.132.183.28])
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <eblake@HIDDEN>) id 1OPLBR-0003uG-CI
	for 6427 <at> debbugs.gnu.org; Thu, 17 Jun 2010 15:55:30 -0400
Received: from int-mx05.intmail.prod.int.phx2.redhat.com
	(int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.18])
	by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o5HJtNL9028330
	(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
	Thu, 17 Jun 2010 15:55:24 -0400
Received: from [10.3.225.162] (vpn-225-162.phx2.redhat.com [10.3.225.162])
	by int-mx05.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP
	id o5HJtNx1019342; Thu, 17 Jun 2010 15:55:23 -0400
Message-ID: <4C1A7D70.8060209@HIDDEN>
Date: Thu, 17 Jun 2010 13:54:24 -0600
From: Eric Blake <eblake@HIDDEN>
Organization: Red Hat
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US;
	rv:1.9.1.9) Gecko/20100430 Fedora/3.0.4-3.fc13 Lightning/1.0b2pre
	Mnenhy/0.8.2 Thunderbird/3.0.4
MIME-Version: 1.0
References: <20100614194523.GD22568@HIDDEN> <4C168FD7.7000001@HIDDEN>
	<4C174CC9.1040201@HIDDEN> <20100617190644.GA12517@HIDDEN>
In-Reply-To: <20100617190644.GA12517@HIDDEN>
X-Enigmail-Version: 1.0.1
Content-Type: multipart/signed; micalg=pgp-sha256;
	protocol="application/pgp-signature";
	boundary="------------enigDFAC148546A300F5D26E09B9"
X-Scanned-By: MIMEDefang 2.67 on 10.5.11.18
X-Spam-Score: -10.1 (----------)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -10.1 (----------)

This is an OpenPGP/MIME signed message (RFC 2440 and 3156)
--------------enigDFAC148546A300F5D26E09B9
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

On 06/17/2010 01:06 PM, Ralf Wildenhues wrote:
> * P=E1draig Brady wrote on Tue, Jun 15, 2010 at 11:50:01AM CEST:
>> On 14/06/10 21:23, Eric Blake wrote:
>>> ls --color =3D> color
>>> ls --color=3Dyes =3D> color
>>> ls --color=3Dauto =3D> plain
>>> ls --color=3Dalways =3D> color
>>> grep --color =3D> plain
>>> grep --color=3Dyes =3D> color
>>> grep --color=3Dauto =3D> plain
>>> grep --color=3Dalways =3D> color
>>>
>>> That is, ls --color implies ls --color=3Dalways, while grep --color
>>> implies grep --color=3Dalways.
>>
>> grep --color=3Dauto 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.

>=20
>> 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.
>=20
> I agree, and implemented that in the updated patch.
>=20
> The patch below has --color equal --color=3Dalways.  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=3Dauto.
>=20
> OK to commit 1 or 1+2?

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

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

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

--=20
Eric Blake   eblake@HIDDEN    +1-801-349-2682
Libvirt virtualization library http://libvirt.org


--------------enigDFAC148546A300F5D26E09B9
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: OpenPGP digital signature
Content-Disposition: attachment; filename="signature.asc"

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (GNU/Linux)
Comment: Public key at http://people.redhat.com/eblake/eblake.gpg
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org/

iQEcBAEBCAAGBQJMGn1wAAoJEKeha0olJ0NqvCAH/1fdcSHlT4r2nS6XYVY3LQ8K
0rk2BDI00AuYeEEQNT5YCltScOCs0zbnDfFQ0BsLYxhgaU1dCEr3YEQeOFbSaeXe
BOT2SbOK6qdpFEbflwuVGf6i0fmbB9e4c3CHIR6Hl2/4MdPkAFaebSIllLZoU4mM
SKxSJ1DXwi1pKVyag6U4UzZb1htkf6QqkU3hCEXeO/rNbWwuL+UVh18HnN0eY7oa
iaqGfxzCgEKbxixGJPA4hEbQK5iGbu14hJjsOmH4TMGYVDILp3Ke0nI2U2c7pCsD
fT1vrhJ+7PkYfWZuUi6eplcrFAkd4vvo4mVC5plbr84eD1g3SurJ4PFSIFlJgu0=
=pyPA
-----END PGP SIGNATURE-----

--------------enigDFAC148546A300F5D26E09B9--




Message sent to owner <at> debbugs.gnu.org, bug-coreutils@HIDDEN:


X-Loop: help-debbugs@HIDDEN
Subject: bug#6427: Autotest: enable colored test results.
Resent-From: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>
Original-Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Resent-To: owner <at> debbugs.gnu.org
Resent-CC: bug-coreutils@HIDDEN
Resent-Date: Thu, 17 Jun 2010 21:54:02 +0000
Resent-Message-ID: <handler.6427.B6427.127681160618230 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 6427
X-GNU-PR-Package: coreutils
X-GNU-PR-Keywords: 
To: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>
Cc: 6427 <at> debbugs.gnu.org, autoconf-patches@HIDDEN, Eric Blake <eblake@HIDDEN>
Received: via spool by 6427-submit <at> debbugs.gnu.org id=B6427.127681160618230
          (code B ref 6427); Thu, 17 Jun 2010 21:54:02 +0000
Received: (at 6427) by debbugs.gnu.org; 17 Jun 2010 21:53:26 +0000
Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.69)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1OPN1Y-0004jy-6t
	for submit <at> debbugs.gnu.org; Thu, 17 Jun 2010 17:53:26 -0400
Received: from mail.gmx.net ([213.165.64.20])
	by debbugs.gnu.org with smtp (Exim 4.69)
	(envelope-from <Ralf.Wildenhues@HIDDEN>) id 1OPKQi-0003ZP-Ah
	for 6427 <at> debbugs.gnu.org; Thu, 17 Jun 2010 15:07:15 -0400
Received: (qmail invoked by alias); 17 Jun 2010 19:07:01 -0000
Received: from xdsl-89-0-148-93.netcologne.de (EHLO localhost.localdomain)
	[89.0.148.93]
	by mail.gmx.net (mp009) with SMTP; 17 Jun 2010 21:07:01 +0200
X-Authenticated: #13673931
X-Provags-ID: V01U2FsdGVkX18uGW0N+GkuNc7DZcLDzI4rTPB3u8W5/ayE+j8J19
	nRfBXojMI/2UfM
Received: from ralf by localhost.localdomain with local (Exim 4.69)
	(envelope-from <Ralf.Wildenhues@HIDDEN>)
	id 1OPKQR-0003GG-E3; Thu, 17 Jun 2010 21:06:55 +0200
Date: Thu, 17 Jun 2010 21:06:55 +0200
From: Ralf Wildenhues <Ralf.Wildenhues@HIDDEN>
Message-ID: <20100617190644.GA12517@HIDDEN>
Mail-Followup-To: =?UTF-8?Q?P=C3=A1draig?= Brady <P@HIDDEN>,
	Eric Blake <eblake@HIDDEN>, 6427 <at> debbugs.gnu.org,
	autoconf-patches@HIDDEN
References: <20100614194523.GD22568@HIDDEN> <4C168FD7.7000001@HIDDEN>
	<4C174CC9.1040201@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <4C174CC9.1040201@HIDDEN>
Organization: Institute for Numerical Simulation, University of Bonn
X-GMX-UID: H0ksffNrYmYTO/2StXc36iVPWkZTQRRu
X-Flags: 1000
User-Agent: Mutt/1.5.20 (2010-04-22)
X-Y-GMX-Trusted: 0
X-Spam-Score: 0.0 (/)
X-Mailman-Approved-At: Thu, 17 Jun 2010 17:53:23 -0400
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.11
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <http://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <http://debbugs.gnu.org/pipermail/debbugs-submit>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <http://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
	<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Sender: debbugs-submit-bounces <at> debbugs.gnu.org
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
X-Spam-Score: -1.3 (-)

* 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.
> 
> > 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?
> 
> Yes I prefer the grep behavior, but I'm not sure we can
> change ls at this stage?

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.

> 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.

> I've wondered about how general the color codes we use are.
> Using termcap/terminfo would be most general but since
> we've had no reports about it yet I think we should stick
> with the simple hardcoded scheme.
> 
> I.E. the following currently outputs colors:
> 
>   TERM=dumb ls --color=auto

I regard it as fairly unproblematic if --color does the wrong thing on a
dumb terminal for now (Automake hasn't seen a bug report to this end
yet either).  Thanks for the suggestions.

In the attched patch, I also moved the AT_COLOR_TESTS entry up a bit,
because the paragraph after AT_TESTED really belongs to the macro
definition.  And added another diversion HELP_TUNING_BEGIN, to cope with
the ordering issues.

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?

Thanks,
Ralf

    Autotest: enable colored test results.
    
    * lib/autotest/general.m4 (HELP_TUNING_BEGIN): New diversion.
    (HELP_TUNING, HELP_OTHER, HELP_END): Bump diversion numbers.
    (AT_INIT): Accept
    --color and --color=never|auto|always.  If desired, colorize
    test results and testsuite summary on standard output.
    [HELP_TUNING]: Divert content instead to ...
    [HELP_TUNING_BEGIN]: ... this diversion, m4_wrapped until the
    end, when we know whether AT_COLOR_TESTS has been specified.
    (AT_COLOR_TESTS): New macro, set the default for color to auto.
    * doc/autoconf.texi (Writing Testsuites): Document it.
    (testsuite Invocation): Document --color* options.
    * tests/local.at: Call AT_COLOR_TESTS for Autoconf's testsuite.
    * tests/autotest.at (color test results): New test, mirroring
    color.test from Automake.
    * NEWS: Update.

diff --git a/NEWS b/NEWS
index f2290a1..0ff482f 100644
--- a/NEWS
+++ b/NEWS
@@ -36,6 +36,8 @@ GNU Autoconf NEWS - User visible changes.
    AT_ARG_OPTION has been changed in that the negative of a long option
    --OPTION is now --no-OPTION rather than --noOPTION.
 
+** Autotest testsuites may optionally provide colored test results.
+
 * Major changes in Autoconf 2.65 (2009-11-21) [stable]
   Released by Eric Blake, based on git versions 2.64.*.
 
diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 48f8589..3bb6b6d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -23478,6 +23478,12 @@ It it recommended that you use a package-specific prefix to @var{options}
 names in order to avoid clashes with future Autotest built-in options.
 @end defmac
 
+@defmac AT_COLOR_TESTS
+@atindex{COLOR_TESTS}
+Enable colored test results by default when the output is connected to
+a terminal.
+@end defmac
+
 @defmac AT_TESTED (@var{executables})
 @atindex{TESTED}
 Log the file name and answer to @option{--version} of each program in
@@ -23868,6 +23874,14 @@ then concurrently running tests will finish before exiting.
 Force more verbosity in the detailed output of what is being done.  This
 is the default for debugging scripts.
 
+@item --color
+@itemx --color@r{[}=never@r{|}auto@r{|}always@r{]}
+Enable colored test results.  Without an argument, or with @samp{always},
+test results will be colored.  With @samp{never}, color mode is turned
+off.  Otherwise, if either the macro @code{AT_COLOR_TESTS} is used by
+the testsuite author, or the argument @samp{auto} is given, then test
+results are colored if standard output is connected to a terminal.
+
 @item --debug
 @itemx -d
 Do not remove the files after a test group was performed ---but they are
diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index 0bc529f..68b80b4 100644
--- a/lib/autotest/general.m4
+++ b/lib/autotest/general.m4
@@ -62,8 +62,10 @@ Copyright (C) 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
 #  - HELP_MODES
 #    Modes help text.  Additional modes can be appended as self-contained
 #    cat'd here-docs as generated by AS_HELP_STRING.
+#  - HELP_TUNING_BEGIN
+#    Tuning help text.  This is for Autotest-provided text.
 #  - HELP_TUNING
-#    Tuning help text.  Additional tuning options can be appended as
+#    Additional tuning options' help text can be appended here as
 #    self-contained cat'd here-docs as generated by AS_HELP_STRING.
 #  - HELP_OTHER
 #    User help can be appended to this as self-contained cat'd here-docs.
@@ -104,9 +106,10 @@ m4_define([_m4_divert(PARSE_ARGS)],         201)
 m4_define([_m4_divert(PARSE_ARGS_END)],     202)
 m4_define([_m4_divert(HELP)],               300)
 m4_define([_m4_divert(HELP_MODES)],         301)
-m4_define([_m4_divert(HELP_TUNING)],        302)
-m4_define([_m4_divert(HELP_OTHER)],         303)
-m4_define([_m4_divert(HELP_END)],           304)
+m4_define([_m4_divert(HELP_TUNING_BEGIN)],  302)
+m4_define([_m4_divert(HELP_TUNING)],        303)
+m4_define([_m4_divert(HELP_OTHER)],         304)
+m4_define([_m4_divert(HELP_END)],           305)
 m4_define([_m4_divert(VERSION)],            350)
 m4_define([_m4_divert(VERSION_NOTICES)],    351)
 m4_define([_m4_divert(VERSION_END)],        352)
@@ -423,6 +426,8 @@ m4_define([_AT_FINISH],
 [m4_ifdef([AT_ingroup], [m4_fatal([missing AT_CLEANUP detected])])dnl
 m4_divert_text([DEFAULTS],
 [
+# Whether to enable colored test results.
+at_color=m4_ifdef([AT_color], [AT_color], [no])
 # List of the tested programs.
 at_tested='m4_ifdef([AT_tested],
   [m4_translit(m4_dquote(m4_defn([AT_tested])), [ ], m4_newline)])'
@@ -492,6 +497,17 @@ do
 	at_clean=:
 	;;
 
+    --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
+	;;
+
     --debug | -d )
 	at_debug_p=:
 	;;
@@ -663,6 +679,17 @@ else
   # Sort the tests, removing duplicates.
   at_groups=`AS_ECHO(["$at_groups"]) | tr ' ' "$as_nl" | sort -nu`
 fi
+
+if test x"$at_color" = xalways \
+   || { test x"$at_color" = xauto && test -t 1; }; then
+  at_red=`printf '\033@<:@0;31m'`
+  at_grn=`printf '\033@<:@0;32m'`
+  at_lgn=`printf '\033@<:@1;32m'`
+  at_blu=`printf '\033@<:@1;34m'`
+  at_std=`printf '\033@<:@m'`
+else
+  at_red= at_grn= at_lgn= at_blu= at_std=
+fi
 m4_divert_pop([PARSE_ARGS_END])dnl
 m4_divert_push([HELP])dnl
 
@@ -697,13 +724,17 @@ Operation modes:
   -l, --list     describes all the tests, or the selected TESTS
 _ATEOF
 m4_divert_pop([HELP_MODES])dnl
-m4_divert_push([HELP_TUNING])dnl
+m4_wrap([m4_divert_push([HELP_TUNING_BEGIN])dnl
 cat <<_ATEOF || at_write_fail=1
 
 dnl extra quoting prevents emacs whitespace mode from putting tabs in output
 Execution tuning:
   -C, --directory=DIR
 [                 change to directory DIR before starting]
+      --color[[=never|auto|always]]
+[                 ]m4_ifdef([AT_color],
+		      [disable colored test results, or enable even without terminal],
+		      [enable colored test results on terminal, or always])
   -j, --jobs[[=N]]
 [                 Allow N jobs at once; infinite jobs with no arg (default 1)]
   -k, --keywords=KEYWORDS
@@ -717,7 +748,7 @@ Execution tuning:
 [                 default for debugging scripts]
   -x, --trace    enable tests shell tracing
 _ATEOF
-m4_divert_pop([HELP_TUNING])dnl
+m4_divert_pop([HELP_TUNING_BEGIN])])dnl
 m4_divert_push([HELP_END])dnl
 cat <<_ATEOF || at_write_fail=1
 
@@ -1156,35 +1187,40 @@ _ATEOF
 	at_msg="UNEXPECTED PASS"
 	at_res=xpass
 	at_errexit=$at_errexit_p
+	at_color=$at_red
 	;;
     no:0)
 	at_msg="ok"
 	at_res=pass
 	at_errexit=false
+	at_color=$at_grn
 	;;
     *:77)
 	at_msg='skipped ('`cat "$at_check_line_file"`')'
 	at_res=skip
 	at_errexit=false
+	at_color=$at_blu
 	;;
     no:* | *:99)
 	at_msg='FAILED ('`cat "$at_check_line_file"`')'
 	at_res=fail
 	at_errexit=$at_errexit_p
+	at_color=$at_red
 	;;
     yes:*)
 	at_msg='expected failure ('`cat "$at_check_line_file"`')'
 	at_res=xfail
 	at_errexit=false
+	at_color=$at_lgn
 	;;
   esac
   echo "$at_res" > "$at_job_dir/$at_res"
   # In parallel mode, output the summary line only afterwards.
   if test $at_jobs -ne 1 && test -n "$at_verbose"; then
-    AS_ECHO(["$at_desc_line $at_msg"])
+    AS_ECHO(["$at_desc_line $at_color$at_msg$at_std"])
   else
     # Make sure there is a separator even with long titles.
-    AS_ECHO([" $at_msg"])
+    AS_ECHO([" $at_color$at_msg$at_std"])
   fi
   at_log_msg="$at_group. $at_desc ($at_setup_line): $at_msg"
   case $at_status in
@@ -1485,12 +1521,14 @@ if $at_errexit_p && test $at_unexpected_count != 0; then
     at_result="$at_result $at_were run, one failed"
   fi
   at_result="$at_result unexpectedly and inhibited subsequent tests."
+  at_color=$at_red
 else
   # Don't you just love exponential explosion of the number of cases?
+  at_color=$at_red
   case $at_xpass_count:$at_fail_count:$at_xfail_count in
     # So far, so good.
-    0:0:0) at_result="$at_result $at_were successful." ;;
-    0:0:*) at_result="$at_result behaved as expected." ;;
+    0:0:0) at_result="$at_result $at_were successful." at_color=$at_grn ;;
+    0:0:*) at_result="$at_result behaved as expected." at_color=$at_lgn ;;
 
     # Some unexpected failures
     0:*:0) at_result="$at_result $at_were run,
@@ -1538,10 +1576,10 @@ $at_skip_count tests were skipped." ;;
 esac
 
 if test $at_unexpected_count = 0; then
-  echo "$at_result"
+  echo "$at_color$at_result$at_std"
   echo "$at_result" >&AS_MESSAGE_LOG_FD
 else
-  echo "ERROR: $at_result" >&2
+  echo "${at_color}ERROR: $at_result$at_std" >&2
   echo "ERROR: $at_result" >&AS_MESSAGE_LOG_FD
   {
     echo
@@ -1757,6 +1795,12 @@ m4_define([AT_COPYRIGHT],
 [m4_default([$2], [m4_newline])([$1])])])# AT_COPYRIGHT
 
 
+# AT_COLOR_TESTS
+# --------------
+# Enable colored test results if standard error is connected to a terminal.
+m4_define([AT_COLOR_TESTS],
+[m4_define([AT_color], [auto])])
+
 # AT_SETUP(DESCRIPTION)
 # ---------------------
 # Start a group of related tests, all to be executed in the same subshell.
diff --git a/tests/autotest.at b/tests/autotest.at
index e09e189..fd3787a 100644
--- a/tests/autotest.at
+++ b/tests/autotest.at
@@ -1505,6 +1505,93 @@ AT_CHECK([test -s sigpipe-stamp || test ! -f micro-suite.dir/7/micro-suite.log],
 
 AT_CLEANUP
 
+
+# --color
+AT_CHECK_AT_TEST([colored test results],
+  [AT_CHECK([:])
+   AT_CLEANUP
+   AT_SETUP([fail])
+   AT_CHECK([exit 1])
+   AT_CLEANUP
+   AT_SETUP([xpass])
+   AT_XFAIL_IF([:])
+   AT_CHECK([:])
+   AT_CLEANUP
+   AT_SETUP([xfail])
+   AT_XFAIL_IF([:])
+   AT_CHECK([exit 1])
+   AT_CLEANUP
+   AT_SETUP([skip])
+   AT_CHECK([exit 77])
+   AT_CLEANUP
+   AT_SETUP([hardfail])
+   AT_XFAIL_IF([:])
+   AT_CHECK([exit 99])
+], [], [], [], [], [], [
+
+TERM=ansi
+export TERM
+
+red=`printf '\033@<:@0;31m'`
+grn=`printf '\033@<:@0;32m'`
+lgn=`printf '\033@<:@1;32m'`
+blu=`printf '\033@<:@1;34m'`
+std=`printf '\033@<:@m'`
+
+# Check that grep can parse nonprinting characters.
+# BSD 'grep' works from a pipe, but not a seekable file.
+# GNU or BSD 'grep -a' works on files, but is not portable.
+AT_CHECK([case `echo "$std" | grep .` in #'' restore font-lock
+	    $std) :;;
+	    *) Exit 77;;
+	  esac], [], [ignore], [],
+	 [echo "grep can't parse nonprinting characters" >&2])
+
+if echo 'ab*c' | grep -F 'ab*c' >/dev/null 2>&1; then
+  FGREP="grep -F"
+else
+  FGREP=fgrep
+fi
+
+# No color.
+AT_CHECK([$CONFIG_SHELL ./micro-suite], [1], [stdout], [stderr])
+for color in "$red" "$grn" "$lgn" "$blu"; do
+  AT_CHECK([cat stdout stderr | $FGREP "$color"], [1])
+done
+
+# Color of test group results.
+AT_CHECK([$CONFIG_SHELL ./micro-suite --color=always], [1], [stdout], [stderr])
+AT_CHECK([cat stdout | grep " only " | $FGREP "$grn"], [], [ignore])
+AT_CHECK([cat stdout | grep " fail " | $FGREP "$red"], [], [ignore])
+AT_CHECK([cat stdout | grep " xfail " | $FGREP "$lgn"], [], [ignore])
+AT_CHECK([cat stdout | grep " xpass " | $FGREP "$red"], [], [ignore])
+AT_CHECK([cat stdout | grep " skip " | $FGREP "$blu"], [], [ignore])
+AT_CHECK([cat stdout | grep " hardfail " | $FGREP "$red"], [], [ignore])
+AT_CHECK([cat stderr | grep ERROR | $FGREP "$red"], [], [ignore])
+
+# The summary is green if all tests were successful, light green if all
+# behaved as expected, and red otherwise.
+AT_CHECK([$CONFIG_SHELL ./micro-suite --color=always 1 -k skip],
+	 [0], [stdout])
+AT_CHECK([cat stdout | grep 'test.*successful' | $FGREP "$grn"],
+	 [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite --color=always 1 -k xfail -k skip],
+	 [0], [stdout])
+AT_CHECK([cat stdout | grep 'as expected' | $FGREP "$lgn"], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite --color=always -k fail],
+	 [1], [ignore], [stderr])
+AT_CHECK([cat stderr | grep ERROR | $FGREP "$red"], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite --color=always -k xpass],
+	 [1], [ignore], [stderr])
+AT_CHECK([cat stderr | grep ERROR | $FGREP "$red"], [], [ignore])
+AT_CHECK([$CONFIG_SHELL ./micro-suite --color=always -k hardfail],
+	 [1], [ignore], [stderr])
+AT_CHECK([cat stderr | grep ERROR | $FGREP "$red"], [], [ignore])
+# Reset color on verbose output.
+printf %s\\n "$std"
+], [1])
+
+
 ## ------------------- ##
 ## srcdir propagation. ##
 ## ------------------- ##
diff --git a/tests/local.at b/tests/local.at
index a812c43..39360ef 100644
--- a/tests/local.at
+++ b/tests/local.at
@@ -25,6 +25,8 @@ m4_pattern_allow([^m4_(define|shift)$])
 # Programs this package provides
 AT_TESTED([autom4te autoconf autoheader autoupdate autoreconf ifnames])
 
+# Enable colored test output.
+AT_COLOR_TESTS
 
 ## ---------------- ##
 ## Utility macros.  ##




    --color implies --color=auto, not --color=always

diff --git a/doc/autoconf.texi b/doc/autoconf.texi
index 3bb6b6d..3c67a0d 100644
--- a/doc/autoconf.texi
+++ b/doc/autoconf.texi
@@ -23876,11 +23876,12 @@ is the default for debugging scripts.
 
 @item --color
 @itemx --color@r{[}=never@r{|}auto@r{|}always@r{]}
-Enable colored test results.  Without an argument, or with @samp{always},
-test results will be colored.  With @samp{never}, color mode is turned
-off.  Otherwise, if either the macro @code{AT_COLOR_TESTS} is used by
-the testsuite author, or the argument @samp{auto} is given, then test
-results are colored if standard output is connected to a terminal.
+Enable colored test results.  Without an argument of @samp{always},
+test results will always be colored, with @samp{never}, color mode is
+turned off.  Otherwise, if either the macro @code{AT_COLOR_TESTS} is
+used by the testsuite author, or no argument or @samp{auto} is given,
+then test results are colored if standard output is connected to a
+terminal.
 
 @item --debug
 @itemx -d
diff --git a/lib/autotest/general.m4 b/lib/autotest/general.m4
index 68b80b4..9389d16 100644
--- a/lib/autotest/general.m4
+++ b/lib/autotest/general.m4
@@ -498,7 +498,7 @@ do
 	;;
 
     --color )
-	at_color=always
+	at_color=auto
 	;;
     --color=* )
 	case $at_optarg in





Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.