Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2024-01-02 Thread Paul Eggert

On 2024-01-02 10:40, Alan Coopersmith wrote:

On 12/21/23 13:46, Alan Coopersmith wrote:

On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.

In that shell, when I run:
   printf "test" /dev/full
it prints nothing and $? is set to 0.

The same happens with /usr/bin/printf instead of the shell builtin.


The engineer working to resync our ksh93 with the latest upstream code from
https://github.com/ksh93/ksh has confirmed this is already fixed upstream
for the ksh builtin.  From a quick look, this appears to be thanks to
https://github.com/ksh93/ksh/commit/93e15a303585df3ecf8184818f2d5ff569ff2ba1
but https://github.com/ksh93/ksh/issues/313 notes that work remains for
other builtins.



Unfortunately that ksh93 still isn't working for printf. After I built 
its current commit 799324b1ffcc2deb55c72547baa1b5ab5918a651 on Fedora 39:


$ ksh -c 'printf "xyzzy\n" || printf "ouch\n" >&2' >/dev/full
ouch
xyzzy
$

Whereas Bash 5.2.21(1) does the right thing:

$ bash -c 'printf "xyzzy\n" || printf "ouch\n" >&2' >/dev/full
bash: line 1: printf: write error: No space left on device
ouch

strace indicates that the ksh93 attempts to write "xyzzy\n" four times 
(!) to standard output and eventually gives up, redirects stderr to 
stdout, and writes "xyzzzy\n" successfully to stderr.


What a mess, huh?




Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2024-01-02 Thread Alan Coopersmith

On 12/21/23 13:46, Alan Coopersmith wrote:

On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.

In that shell, when I run:
   printf "test" /dev/full
it prints nothing and $? is set to 0.

The same happens with /usr/bin/printf instead of the shell builtin.


The engineer working to resync our ksh93 with the latest upstream code from
https://github.com/ksh93/ksh has confirmed this is already fixed upstream
for the ksh builtin.  From a quick look, this appears to be thanks to
https://github.com/ksh93/ksh/commit/93e15a303585df3ecf8184818f2d5ff569ff2ba1
but https://github.com/ksh93/ksh/issues/313 notes that work remains for
other builtins.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris




Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-22 Thread Zack Weinberg
On Fri, Dec 22, 2023, at 8:22 AM, Zack Weinberg wrote:
> (But I'll also see if it's practical to mark this test as an expected
> failure on systems where the write error isn't detected.)

Thus.  Tested only on Linux.  I don't have access to a machine that
has *both* /dev/full and a buggy printf(1).  (Alan, I saw what you
said about zero-cost installation media for Solaris 11.4 but I have
several higher-priority things to resolve and setting up a VM could
easily eat my entire day.)

zw

diff --git a/tests/torture.at b/tests/torture.at
index 288a5a55..d98b92c0 100644
--- a/tests/torture.at
+++ b/tests/torture.at
@@ -291,7 +291,21 @@ AT_CHECK_CONFIG_CREATION(command)
 # Create a link
 AT_CHECK_CONFIG_CREATION(link)
 
-# Now check for write errors
+# Now check for write errors.
+# Depending on the shell, 'printf' might or might not report write
+# errors on stdout.  Check /bin/sh regardless of $SHELL, because
+# config.status always uses /bin/sh.
+# Note: another way to force a write error is with ulimit -f, but
+# depending on the OS it might not be possible to set that limit
+# lower than one disk block, so we'd have to make the tests below
+# produce much more output.
+test_write_errors=false
+if test -w /dev/full && test -c /dev/full; then
+  if /bin/sh -c 'printf "write errors detected?\\n"' > /dev/full 2> /dev/null
+  then :
+  else test_write_errors=:
+  fi
+fi
 
 # Create a file
 AT_CHECK_CONFIG_CREATION_NOWRITE(file)
@@ -301,7 +315,7 @@ AT_CHECK([echo from-stdin | ./config.status --file=file:-],
 AT_CHECK([grep from-stdin file], [], [from-stdin
 ])
 # Force write error creating a file on stdout
-if test -w /dev/full && test -c /dev/full; then
+if $test_write_errors; then
   AT_CHECK([./config.status --file=-:input /dev/full || exit 1],
   [1], [ignore], [ignore])
 fi
@@ -320,7 +334,7 @@ AT_CHECK([./config.status --header=-:input /dev/full || exit 1],
   [1], [ignore], [ignore])
 fi
-- 
2.41.0



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-22 Thread Zack Weinberg
On Thu, Dec 21, 2023, at 11:54 PM, Nick Bowler wrote:
> On 2023-12-21 19:26, Paul Eggert wrote:
>> On 2023-12-21 13:19, Zack Weinberg wrote:
>>> Sorry, I'm with GNU here: failure to report errors on writing to
>>> stdout is a bug.  No excuses will be accepted.
>> 
>> Agreed. printf commands that silently succeed when they can't do the
>> requested action are simply broken.
>
> I tested several modern, current operating systems, including:
>   OpenBSD 7, NetBSD 9, FreeBSD 13, Alpine Linux 3.15
> I also tested several not-so-modern systems, including:
>   DJGPP, HP-UX 11, Solaris 8.
>
> On every single one of these systems, the /usr/bin/printf (or equivalent)
> does not generally diagnose errors that occur when writing to standard
> output, and an exit status of 0 is returned.

Right, I'm starting a campaign when I get back from vacation in January.

(But I'll also see if it's practical to mark this test as an expected
failure on systems where the write error isn't detected.)

zw



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Nick Bowler
On 2023-12-21 19:26, Paul Eggert wrote:
> On 2023-12-21 13:19, Zack Weinberg wrote:
>> Sorry, I'm with GNU here: failure to report errors on writing to
>> stdout is a bug.  No excuses will be accepted.
> 
> Agreed. printf commands that silently succeed when they can't do the
> requested action are simply broken.

I tested several modern, current operating systems, including:
  OpenBSD 7, NetBSD 9, FreeBSD 13, Alpine Linux 3.15
I also tested several not-so-modern systems, including:
  DJGPP, HP-UX 11, Solaris 8.

On every single one of these systems, the /usr/bin/printf (or equivalent)
does not generally diagnose errors that occur when writing to standard
output, and an exit status of 0 is returned.

Further notes:

The shell on FreeBSD has a printf builtin which does diagnose such
errors and does exit with a nonzero status.

The shell on Alpine has a printf builtin which does not diagnose such
errors but does exit with a nonzero status.

The shell on NetBSD has a printf builtin which does not diagnose such
errors and exits with a 0 status.

The DJGPP bash shell has a printf builtin which does not diagnose such
errors and exits with a 0 status.

The version of bash that comes with Solaris 8 has a printf builtin which
does not diagnose such errors and exits with a 0 status.

The other systems tested do not have printf builtins in their shells, so
plain "printf" invokes "simply broken" /usr/bin/printf.

So sure, we can call it a "bug" and we can call these systems "simply
broken" but the reality is that these systems exist and portability means
dealing with this behaviour even if it is not what we wish they would do
or what some piece of paper says they should do.

There are probably a lot more systems with a "simply broken" printf,
as the printf utilities in SVr4 and 4.4BSD will also behave like this...

Cheers,
  Nick



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Paul Eggert

On 2023-12-21 19:56, Nick Bowler wrote:

On 2023-12-21 19:34, Paul Eggert wrote:

   ulimit -f 0
   trap "" XFSZ
   printf "test" >test || echo failed with status $?

which issues the following diagnostics on Solaris 10 /bin/sh:

   printf: write error: File too large
   failed with status 1

I think you might want to double check your test setup.


Oh, you're right. I put /opt/sfw/bin early in my PATH. 
/opt/sfw/bin/printf is part of Solaris (it's in the SFWcoreu package) 
but it is optional and obviously not everybody puts it early.


With PATH='/usr/bin' I get the broken (non-POSIX) behavior.



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Nick Bowler
On 2023-12-21 19:34, Paul Eggert wrote:
>   ulimit -f 0
>   trap "" XFSZ
>   printf "test" >test || echo failed with status $?
> 
> which issues the following diagnostics on Solaris 10 /bin/sh:
> 
>   printf: write error: File too large
>   failed with status 1

I think you might want to double check your test setup.  This error
message is exactly what you'd get if you are running printf from a
recent release of GNU coreutils, rather than the /usr/bin/printf
that comes with Solaris.

I don't have a Solaris 10 box handy for testing right now but neither
Solaris 8 /usr/bin/printf nor heirloom-tools printf (which is ported
from OpenSolaris, contemporaneous with Solaris 10) print this error
message, and neither exit with status 1.

Cheers,
  Nick



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Paul Eggert

On 2023-12-21 13:46, Alan Coopersmith wrote:

On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.

In that shell, when I run:
   printf "test" /dev/full
it prints nothing and $? is set to 0.


This appears to be a regression from Solaris 10 and Solaris 11.3. 
Although they lack /dev/full they do have other ways for printf to fail, 
e.g.:


  ulimit -f 0
  trap "" XFSZ
  printf "test" >test || echo failed with status $?

which issues the following diagnostics on Solaris 10 /bin/sh:

  printf: write error: File too large
  failed with status 1

and the following on Solaris 11.3 /bin/sh:

  /bin/sh[3]: printf: write to 1 failed [File too large]
  failed with status 1

but I guess quietly succeeds on Solaris 11.4 (I lack easy access to a 
Solaris 11.4 box).




Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Paul Eggert

On 2023-12-21 13:19, Zack Weinberg wrote:


Sorry, I'm with GNU here: failure to report errors on writing to stdout
is a bug.  No excuses will be accepted.


Agreed. printf commands that silently succeed when they can't do the 
requested action are simply broken.


Even if one is not convinced by GNU's good-citizen example, POSIX 
requires printf to fail with a diagnostic in this situation. Here's 
chapter and verse:


https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/printf.html#tag_20_94_15

says "CONSEQUENCES OF ERRORS" are "Default", and

https://pubs.opengroup.org/onlinepubs/9699919799.2018edition/utilities/V3_chap01.html#tag_17_04

says that utilities must issue a diagnostic on stderr and exit with 
nonzero status when they cannot do the requested action.




Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Alan Coopersmith

On 12/21/23 13:46, Alan Coopersmith wrote:

On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.

In that shell, when I run:
   printf "test" /dev/full
it prints nothing and $? is set to 0.

The same happens with /usr/bin/printf instead of the shell builtin.


If I run bash instead, with its builtin printf, I see:

bash-5.2$ printf "test" /dev/full
bash: printf: write error: No space left on device

which is presumably what the test suite is expecting.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris




Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Alan Coopersmith

On 12/21/23 10:48, Zack Weinberg wrote:

On Thu, Dec 21, 2023, at 12:34 PM, Alan Coopersmith wrote:

For 119, the code in the Solaris find command that prints the
"find: cannot read dir sub/unwritable" message was modified last year
to make it not print that message if -prune was in effect for the directory,
so it's possible a bug in find was introduced by those changes.


Yes, I believe this is a recently introduced bug in Solaris find.
This sequence of shell commands should reproduce:

mkdir sub
mkdir sub/unwritable
touch sub/unwritable/file
chmod a-wx sub/unwritable
find sub -type d ! -perm -700 -exec chmod u+rwx {} \;


It does - I'll file a bug against Solaris find and you can ignore this
report.  (If anyone else hits it, the simple workaround is to use
/usr/gnu/bin/find instead of /usr/bin/find.)


As previously mentioned, the Solaris 11 machine I have access to is
version 11.3 (unknown patch level; if you know how to get anything
more specific than that, please let me know).


On Solaris 11.4, you can use uname -v, but on Solaris 11.3 the easiest
way I know is "pkg info entire" should have a line like:
  Version: 0.5.11 (Oracle Solaris 11.3.21.5.0)


For 261, Solaris gained a /dev/full device in Solaris 11.4.51.
Since the only purpose of this device is to return ENOSPC, I would
hope that it's fully compatible with the implementations on other OS'es,
but I don't know of any testing done to confirm that.


This may be a bug in your /bin/sh or {/usr,}/bin/printf.  The command
that failed in this test is

./config.status --header=-:input /dev/full

which is *expected* to print an error message (on stderr) and exit
unsuccessfully, but on your test machine it printed nothing and exited
successfully.

When I execute this command on my Linux workstation, using the files
'config.status' and 'input' from your tarball, I get

./config.status: line 978: printf: write error: No space left on device
config.status: error: could not create -

and an unsuccessful exit status.  I would guess that on your machine
the printf built-in and/or standalone printf executable are not
reporting write errors.


On Solaris 11.4, /bin/sh is currently a somewhat modified ksh93u+ -
we're working to resync with the new community upstream still.

In that shell, when I run:
  printf "test" /dev/full
it prints nothing and $? is set to 0.

The same happens with /usr/bin/printf instead of the shell builtin.


Since I don't have access to a Solaris 11.4 machine myself, and since
both of these appear to be plain bugs in the shell and utilities, I'm
currently not planning to make any changes because of these failures.


A two year old version of 11.4 (the 11.4.42 update) is available under terms
we hope are suitable for FOSS developers from
https://www.oracle.com/solaris/solaris11/downloads/solaris-downloads.html
if you have a supported SPARC or x86-64 machine to run it on.  Unfortunately
it doesn't include security or other updates, though we hope to get another
update released sometime in the next year or so.

We're also working to make a SPARC Solaris 11.4 machine available to the
gcc build farm, hopefully in the first part of new year.


Please let me know if you disagree; in which case, please suggest what
we should do, because I don't see any good workaround in Autoconf's code
for either issue.


That sounds fine to me.  As noted in other mail, I didn't see any failures
from configure scripts, just from the test suite.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris




Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Zack Weinberg
On Thu, Dec 21, 2023, at 3:51 PM, Nick Bowler wrote:
> On 2023-12-21 13:48, Zack Weinberg wrote:
>  > and an unsuccessful exit status.  I would guess that on your machine
>  > the printf built-in and/or standalone printf executable are not
>  > reporting write errors.
>
> I think it is not reasonable to expect any utility to report any kind
> of error on writes to standard output.  This is not normal behaviour
> for C programs and, in the case of printf utilities which are not shell
> builtins, such behaviour is likely unique to GNU.

Sorry, I'm with GNU here: failure to report errors on writing to stdout
is a bug.  No excuses will be accepted.

zw



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Nick Bowler

On 2023-12-21 13:48, Zack Weinberg wrote:
> and an unsuccessful exit status.  I would guess that on your machine
> the printf built-in and/or standalone printf executable are not
> reporting write errors.

I think it is not reasonable to expect any utility to report any kind
of error on writes to standard output.  This is not normal behaviour
for C programs and, in the case of printf utilities which are not shell
builtins, such behaviour is likely unique to GNU.

Without /dev/full it is difficult to portably trigger write errors,
but NetBSD 9 has /dev/full and its /usr/bin/printf also does not
report such errors.

You can more reliably get errors by redirecting to a pipe and closing
the read end. since in this case the SIGPIPE will not go unnoticed,
(although an ignored SIGPIPE is inherited from the parent process which
may affect the results).  This can be tricky to setup in a shell script
though.

Cheers,
  Nick



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Zack Weinberg
On Thu, Dec 21, 2023, at 12:34 PM, Alan Coopersmith wrote:
> For 119, the code in the Solaris find command that prints the
> "find: cannot read dir sub/unwritable" message was modified last year
> to make it not print that message if -prune was in effect for the directory,
> so it's possible a bug in find was introduced by those changes.

Yes, I believe this is a recently introduced bug in Solaris find.
This sequence of shell commands should reproduce:

mkdir sub
mkdir sub/unwritable
touch sub/unwritable/file
chmod a-wx sub/unwritable
find sub -type d ! -perm -700 -exec chmod u+rwx {} \;

As -depth is not in use here, find should execute the chmod _before_
attempting to descend into "sub/unwritable", and that should make the
directory accessible again.  I tested the above sequence of commands on
all the following operating systems, and did not encounter any errors:

aarch64c-freebsd14.0
powerpc-aix7.1.5.0
powerpc-aix7.3.1.0
sparc-solaris2.10
sparc-solaris2.11
x86_64-linux
x86_64-freebsd13.2
x86_64-netbsd9.3
x86_64-openbsd7.4

As previously mentioned, the Solaris 11 machine I have access to is
version 11.3 (unknown patch level; if you know how to get anything
more specific than that, please let me know).

> For 261, Solaris gained a /dev/full device in Solaris 11.4.51.
> Since the only purpose of this device is to return ENOSPC, I would
> hope that it's fully compatible with the implementations on other OS'es,
> but I don't know of any testing done to confirm that.

This may be a bug in your /bin/sh or {/usr,}/bin/printf.  The command
that failed in this test is

./config.status --header=-:input /dev/full

which is *expected* to print an error message (on stderr) and exit
unsuccessfully, but on your test machine it printed nothing and exited
successfully.

When I execute this command on my Linux workstation, using the files
'config.status' and 'input' from your tarball, I get

./config.status: line 978: printf: write error: No space left on device
config.status: error: could not create -

and an unsuccessful exit status.  I would guess that on your machine
the printf built-in and/or standalone printf executable are not
reporting write errors.

Since I don't have access to a Solaris 11.4 machine myself, and since
both of these appear to be plain bugs in the shell and utilities, I'm
currently not planning to make any changes because of these failures.
Please let me know if you disagree; in which case, please suggest what
we should do, because I don't see any good workaround in Autoconf's code
for either issue.

Thanks again for testing.
zw



Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Alan Coopersmith

On 12/21/23 06:06, Zack Weinberg wrote:

On Wed, Dec 20, 2023, at 4:57 PM, Alan Coopersmith wrote:

Failed tests:
GNU Autoconf 2.72e test suite test groups:

   NUM: FILE-NAME:LINE TEST-GROUP-NAME
KEYWORDS

11: tools.at:442   autoconf: forbidden tokens, basic
   119: m4sh.at:2115   _AS_CLEAN_DIR
   261: torture.at:189 AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS

I don't see any obvious causes for these.  testsuite.log attached.


#119 and #261 pass for me on sparc64-sun-solaris11.3
(SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise).

Would you mind sending us a tarball of tests/testsuite.dir/{119,261}
from the machine where they failed?


Attached.

For 119, the code in the Solaris find command that prints the
"find: cannot read dir sub/unwritable" message was modified last year
to make it not print that message if -prune was in effect for the directory,
so it's possible a bug in find was introduced by those changes.

For 261, Solaris gained a /dev/full device in Solaris 11.4.51.
Since the only purpose of this device is to return ENOSPC, I would
hope that it's fully compatible with the implementations on other OS'es,
but I don't know of any testing done to confirm that.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris


261.tar.gz
Description: application/gzip


119.tar.gz
Description: application/gzip


Re: [GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-21 Thread Zack Weinberg
On Wed, Dec 20, 2023, at 4:57 PM, Alan Coopersmith wrote:
> Failed tests:
> GNU Autoconf 2.72e test suite test groups:
>
>   NUM: FILE-NAME:LINE TEST-GROUP-NAME
>KEYWORDS
>
>11: tools.at:442   autoconf: forbidden tokens, basic
>   119: m4sh.at:2115   _AS_CLEAN_DIR
>   261: torture.at:189 AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS
>
> I don't see any obvious causes for these.  testsuite.log attached.

#119 and #261 pass for me on sparc64-sun-solaris11.3
(SunOS gcc-solaris11 5.11 11.3 sun4u sparc SUNW,SPARC-Enterprise).

Would you mind sending us a tarball of tests/testsuite.dir/{119,261}
from the machine where they failed?

zw



[GNU Autoconf 2.72e] testsuite: 11 119 261 failed on Solaris 11.4 x86

2023-12-20 Thread Alan Coopersmith

Failed tests:
GNU Autoconf 2.72e test suite test groups:

 NUM: FILE-NAME:LINE TEST-GROUP-NAME
  KEYWORDS

  11: tools.at:442   autoconf: forbidden tokens, basic
 119: m4sh.at:2115   _AS_CLEAN_DIR
 261: torture.at:189 AC_CONFIG_FILES, HEADERS, LINKS and COMMANDS

I don't see any obvious causes for these.  testsuite.log attached.

--
-Alan Coopersmith- alan.coopersm...@oracle.com
 Oracle Solaris Engineering - https://blogs.oracle.com/solaris## -- ##
## GNU Autoconf 2.72e test suite. ##
## -- ##

testsuite: command line was:
  $ tests/testsuite -C tests MAKE=gmake

## -- ##
## ChangeLog. ##
## -- ##

| 2023-12-20  Zack Weinberg  
| 
| 	update NEWS for 2.72e release candidate
| 
| 	spelling errors reported by “make syntax-check”
| 
| 2023-12-19  Zack Weinberg  
| 
| 	Adjust --help and manpages to make it easier to find the Web manual.
| 	Today it came to my attention that, if you don’t already know that all

## - ##
## Platform. ##
## - ##

hostname = also
uname -m = i86pc
uname -r = 5.11
uname -s = SunOS
uname -v = 11.4.66.160.0

/usr/bin/uname -p = i386
/bin/uname -X = System = SunOS
Node = also
Release = 5.11
KernelID = 11.4.66.160.0
Machine = i86pc
BusType = 
Serial = 
Users = 
OEM# = 0
Origin# = 1
NumCPU = 8

/bin/arch  = i86pc
/usr/bin/arch -k   = i86pc
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo  = unknown
/bin/machine   = unknown
/usr/bin/oslevel   = unknown
/bin/universe  = unknown

PATH: /export/alanc/autotools/src/autoconf-2.72e/tests/
PATH: /export/alanc/autotools/src/autoconf-2.72e/tests/
PATH: /usr/bin/
PATH: /usr/gnu/bin/

testsuite: atconfig:
| # Configurable variable values for building test suites.
| # Generated by ./config.status.
| # Copyright (C) 2023 Free Software Foundation, Inc.
| 
| # The test suite will define top_srcdir=/../.. etc.
| at_testdir='tests'
| abs_builddir='/export/alanc/autotools/src/autoconf-2.72e/tests'
| at_srcdir='.'
| abs_srcdir='/export/alanc/autotools/src/autoconf-2.72e/tests'
| at_top_srcdir='..'
| abs_top_srcdir='/export/alanc/autotools/src/autoconf-2.72e'
| at_top_build_prefix='../'
| abs_top_builddir='/export/alanc/autotools/src/autoconf-2.72e'
| 
| # Backward compatibility with Autotest <= 2.59b:
| at_top_builddir=$at_top_build_prefix
| 
| AUTOTEST_PATH='tests'
| 
| SHELL=${CONFIG_SHELL-'/bin/sh'}

testsuite: atlocal:
| # -*- shell-script -*-
| # tests/atlocal.  Generated from atlocal.in by configure.
| # Configurable variable values for Autoconf test suite.
| 
| # Copyright (C) 2000-2001, 2005, 2008-2017, 2020-2023 Free Software
| # Foundation, Inc.
| #
| # This program is free software: you can redistribute it and/or modify
| # it under the terms of the GNU General Public License as published by
| # the Free Software Foundation, either version 3 of the License, or
| # (at your option) any later version.
| #
| # This program is distributed in the hope that it will be useful,
| # but WITHOUT ANY WARRANTY; without even the implied warranty of
| # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
| # GNU General Public License for more details.
| #
| # You should have received a copy of the GNU General Public License
| # along with this program.  If not, see .
| 
| AWK='gawk'
| EGREP='/usr/bin/ggrep -E'
| GREP='/usr/bin/ggrep'
| M4='/usr/bin/gm4'
| PERL='/usr/bin/perl'
| SED='/usr/bin/gsed'
| 
| # We need to know if sh -n is ok.
| SHELL_N='/bin/sh'
| 
| # Check whether the underlying system can manage some unusual
| # symbols in file names.
| if test -z ''; then
|   func_sanitize_file_name () { echo "$@"; }
| else
|   func_sanitize_file_name () { echo "$@" | tr -d ''; }
| fi
| 
| # Can we create directories with trailing whitespace in their names?
| ac_cv_dir_trailing_space='yes'
| if test "$ac_cv_dir_trailing_space" = yes; then
|   func_sanitize_dir_name () { echo "$@"; }
| else
|   func_sanitize_dir_name () { echo "$@" | sed 's/  *$//'; }
| fi
| 
| # AUTOM4TE might be set in the environment.  Override it here so that
| # direct aclocal invocations also use it.
| AUTOM4TE=autom4te
| export AUTOM4TE

./local.at:34: using 1s as timestamp resolution

##  ##
## Tested programs. ##
##  ##

./local.at:25: /export/alanc/autotools/src/autoconf-2.72e/tests/autom4te --version
autom4te (GNU Autoconf) 2.72e
Features: subsecond-mtime

Copyright (C) 2023 Free Software Foundation, Inc.
License GPLv3+/Autoconf: GNU GPL version 3 or later
, 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Written by Akim Demaille.

./local.at:25: /export/alanc/autotools/src/autoconf-2.72e/tests/autoconf --version
autoconf (GNU Autoconf) 2.72e
Copyright (C) 2023 Free Software Foundati