Re: Tru64 losing files.

[tow21]

Paul Eggert: [Wed, Jul 28, 2004 at 11:47:01AM -0700]:
> Toby White <address@hidden> writes:
> 
> > I've managed to generate two shortish (~1000 line) configure scripts 
> > demonstrating the difference in behaviour. The only difference 
> > between the two (apart from version numbers in comments) is the 
> > changed LINENO code.
> 
> Is the LINENO code being triggered for you?  That is, are the scripts
> creating a file configure.lineno and executing that file?  If so,
> can you capture these two configure.lineno files and post them?

Nope; it's not being triggered. After some examination, what's happening
is that:
/bin/sh is the Bourne shell (according to the man page). 
This does not have the LINENO variable, so configure gets re-executed 
under bash.
This is confirmed by executing 'bash configure' explicitly. In this
case, LINENO works properly first time round, and the script fails as 
previously described.

If I remove the chunk which tests for LINENO, and let /bin/sh execute
the script itself, then it succeeds; albeit all the error messages
will presumably refer to a non-existent $LINENO.

In config.works, however, the LINENO-detection code is buggy;
as_lineno_1 and as_lineno_2 are computed; but both are blank.
Adding 1 to blank results in blank again, so when it does:

as_lineno_1=`(expr $as_lineno_1 + 1) 2>/dev/null`
if test "x$as_lineno_1" != "x$as_lineno_2"; then

the test evaluates to x != x, and the if is not taken; so the
script is not re-executed, and succeeds under /bin/sh. This
is presumably why this code was replaced.

Ah! A further discovery by reading the manpage. If I do 
export BIN_SH=xpg4
it puts the shell into posix mode. Now LINENO works correctly, the
script doesn't try to relaunch itself as bash, and the whole
script works correctly.

So it looks like there's a buggy version of bash installed here. Hmm.
I'll try and cut the failing script down to a meaningful size and
report it to the sysadmin.

Would it be sensible in any case for autoconf to try setting the
native shell into POSIX mode first, before trying a possibly
buggy third-party installed shell?

Toby 

-- 
Dr. Toby White, Dept. of Earth Sciences, Downing Street, Cambridge CB2 3EQ. UK
Email: <address@hidden>
Tel: +44 1223 333409
Fax: +44 1223 333450