Re: bison-1.29c 'configure' problems on Solaris 8.

[Paul Eggert]

> Date: Tue, 2 Oct 2001 23:13:28 +0200
> From: address@hidden
> 
> On Tue, Oct 02, 2001 at 11:25:58AM -0700, Paul Eggert wrote:
> > The 'configure' script distributed with bison-1.29c has problems with
> > the Solaris 8 /bin/sh.  Here are two examples.
> > 
> > First, '.' is not in my PATH.  Hence the code in "configure" that
> > attempts to decipher the working directory of "configure" does not
> > work if I run the command "sh configure", as "sh configure" does not
> > consult PATH to find "configure".
> 
> Err, you see me confused, as, as far I know, configure had the same
> dependency wrt to PATH before.  Typically, that's the code triggered
> by AC_CONFIG_SRCDIR:
> 
> # Find the source files, if location was not specified.
> if test -z "$srcdir"; then
>   ac_srcdir_defaulted=yes
>   # Try the directory containing this script, then its parent.
>   ac_prog=$0
>   ac_confdir=`echo "$ac_prog" | sed 's%[\\/][^\\/][^\\/]*$%%'`
>   test "x$ac_confdir" = "x$ac_prog" && ac_confdir=.
>   srcdir=$ac_confdir
>   if test ! -r $srcdir/$ac_unique_file; then
>     srcdir=..
>   fi
> else
>   ac_srcdir_defaulted=no
> fi

But that code works correctly for "sh configure"; it sets the source
directory to ".".  The problem isn't in that code; it's in
the "Find who we are" code in the line number stoff.

> What would you suggest?

I would use the above code to "find who we are", and not have a buggy
near-duplicate in the line-number-handling code.

> > $ sh configure
> > configure: test: argument expected

This is because of the "Find who we are" problem mentioned above.

> > $ sh ./configure
> > awk: syntax error near line 3
> > awk: illegal statement near line 3
> 
> This, I must say, escapes my understanding.  AFAICS, I wrote portable
> AWK.  What's the problem?

Solaris 8 'awk' is old awk, which doesn't have the sub() function.
And even if it did, you can't put spaces between 'sub' and '(', as old
awk requires there to be no space between a function identifier and
the '('.

I'll let you handle this one.  Personally, I'm not sure that the
current line-numbering scheme is going to be portable enough -- not
that I fully understand what is going on.

How about just hard-coding the line numbers in 'configure', rather
than having 'configure' generated a hard-coded version of itself?
That way, we don't have to worry about buggy awks and the like.



> > $ sh -x configure
> 
> You bad boy...
> 
> Just FMI, you *really* write things like this?

Yes.  'sh configure' was in a makefile wrapper.  It works even if the
file 'configure' is not executable for one reason or another.

> I've always felt dumping all the envvar was too indiscreet.  Some people
> have told me they wanted `env` in config.log or/and testsuite.log, what
> is your own opinion?  And what is knick? ;)

One of our fileservers.  It's a Network Appliance Corporation (NAC)
box -- and now you know where the name "knick" came from.


> Paul, your knowledge (and mainly the number of machines you have
> access to) is bigger than mine.  Would care fixing CVS Autoconf, and
> especially its `.' and `source' documentation?  Or just gimme some
> hints...

OK, I changed "source" to "." in autoconf/lib/m4sugar/m4sh.m4
(AS_SHELL_SANITIZE), and installed the following patch to the
documentation.  The old example was misguided, as "." does not consult
PATH when given an argument like "foo/bar".  Also, I don't like
putting DOS-isms in the code or documentation when they break things
on non-DOS hosts.  (These DOS-isms happened to be incorrect anyway, so
out they go.  :-)

2001-10-02  Paul Eggert  <address@hidden>

        * doc/autoconf.texi (Limitations of Builtins): You can't use
        "source"; it's not portable.  Remove confusing and
        somewhat-incorrect example involving "." and "/".

Index: autoconf.texi
===================================================================
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.544
diff -p -u -2 -r1.544 autoconf.texi
--- autoconf.texi       2001/10/02 14:37:07     1.544
+++ autoconf.texi       2001/10/02 23:24:16
@@ -8299,28 +8299,10 @@ the @samp{x} into account later in the p
 @item @command{.}
 @prindex @command{.}
address@hidden @command{source}
 Use @command{.} only with regular files (use @samp{test -f}).  Bash
 2.03, for instance, chokes on @samp{. /dev/null}.  Also, remember that
address@hidden is not expected to look in the current directory, hence you
-might need some wrapper code for relative paths:
address@hidden uses @env{PATH} if its argument contains no slashes, so if
+you want to use @command{.} on a file @file{foo} in the current
+directory, you must use @samp{. ./foo}.
 
address@hidden
-# Some versions of Bash will fail to source /dev/null (special
-# files actually), so we avoid doing that.
-if test -r "$file" && test -f "$file"; then
-  case $file in
-    [\\/]* | ?:[\\/]* ) . $file;;
-    *)                  . ./$file;;
-  esac
-fi
address@hidden example
-
-Almost all the shells have a special handling for filenames containing
-no slash, but they are not portable.  For instance, Zsh sticks to
address@hidden for @command{.}, while it first looks in the current
-directory with @command{source}.  Bash makes no difference between
address@hidden and @command{source} and looks in the current directory if
-the file was not found in the @code{$PATH}.
-
 @item @command{!}
 @prindex @command{!}
@@ -8562,5 +8544,7 @@ risc/os} 4.52 refuses to do it.
 @item @command{source}
 @c -------------------
-See the item @command{.} above.
address@hidden @command{source}
+This command is not portable, as @sc{posix} does not require it; use
address@hidden instead.