Re: Tru64/OSF: BIN_SH revisited
Stepan Kasal [EMAIL PROTECTED] writes: These two changes would make the following patch; OK to commit? Yes, except you need to modify the Autoconf documentation accordingly.
Re: Tru64/OSF: BIN_SH revisited
Hello, 0a) Revert the change to set BIN_SH in Autoconf, [...] IMHO this is a very good idea. First, BIN_SH is set in macro AS_BOURNE_COMPATIBLE, but it doesn't belong there: this macro contains things like set -o posix, which i) have an immediate effect inside the current instance ii) are not inhereted in subsequent calls to the shell (Because of (ii), AS_BOURNE_COMPATIBLE is called from _AS_RUN.) Second, if this change 0b) Additionally, prepend /usr/bin/posix/ to the path walk of _AS_DETECT_BETTER_SHELL, [...] make things work on OSF, then the BIN_SH assignment becomes redundant cruft, right? We shall remove it now, before is is conserved by a release. (If the problem re-appears when 2.60 will be widely used, we can then add BIN_SH to the right place (the detect better shell stuff), and with a comment explaining the situation where it was necessary.) Does this sound convincing? Moreover, I think that the line DUALCASE=1; export DUALCASE doesn't belong to AS_BOURNE_COMPATIBLE either, the reason is the same as above; I think it shall go to AS_SHELL_SANITIZE. These two changes would make the following patch; OK to commit? Have a nice day, Stepan 2006-03-17 Stepan Kasal [EMAIL PROTECTED] * lib/m4sugar/m4sh.m4 (AS_BOURNE_COMPATIBLE): Removed BIN_SH=xpg4, moved DUALCASE=1 ... (AS_SHELL_SANITIZE): ... here. Index: lib/m4sugar/m4sh.m4 === RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v retrieving revision 1.162 diff -u -r1.162 m4sh.m4 --- lib/m4sugar/m4sh.m4 16 Mar 2006 13:33:18 - 1.162 +++ lib/m4sugar/m4sh.m4 17 Mar 2006 15:20:12 - @@ -172,8 +172,6 @@ else case `(set -o) 2/dev/null` in *posix*) set -o posix;; esac fi -BIN_SH=xpg4; export BIN_SH # for Tru64 -DUALCASE=1; export DUALCASE # for MKS sh ]) @@ -320,6 +318,7 @@ ## - ## AS_BOURNE_COMPATIBLE +DUALCASE=1; export DUALCASE # for MKS sh # PATH needs CR _AS_CR_PREPARE
Re: Tru64/OSF: BIN_SH revisited
Hi Paul, Stepan, * Paul Eggert wrote on Fri, Mar 17, 2006 at 08:55:14AM CET: Ralf Wildenhues [EMAIL PROTECTED] writes: 0a) Revert the change to set BIN_SH in Autoconf, in order to be consistent. 0b) Additionally, prepend /usr/bin/posix/ to the path walk of _AS_DETECT_BETTER_SHELL, to choose the right shell right away, inside Autoconf. This sounds good to me. The first patch below does (0b), the second (3). I'm tending toward (0b), unsure whether to add (0a) for good measure. What do you think? (0b) is good. I see your point about (0a) but let's go ahead and try it, for Autoconf. Thanks. OK. I've applied (0b) only for now, and dropped the Libtool patch. Thanks for the review! * Stepan Kasal wrote on Fri, Mar 17, 2006 at 04:27:09PM CET: Second, if this change 0b) Additionally, prepend /usr/bin/posix/ to the path walk of _AS_DETECT_BETTER_SHELL, [...] make things work on OSF, then the BIN_SH assignment becomes redundant cruft, right? That depends on whether anything below (spawned by) configure ever calls `sh' unadorned. We shall remove it now, before is is conserved by a release. Without deciding over this change: iff you apply it, please also adjust autoconf.texi which currently states that BIN_SH is set. Moreover, I think that the line DUALCASE=1; export DUALCASE doesn't belong to AS_BOURNE_COMPATIBLE either, the reason is the same as above; I think it shall go to AS_SHELL_SANITIZE. FWIW, I'm don't know about this one either. Cheers, Ralf
Re: Tru64/OSF: BIN_SH revisited
Hello,
On Fri, Mar 17, 2006 at 11:20:49AM -0800, Paul Eggert wrote:
Yes, except you need to modify the Autoconf documentation accordingly.
I checked in the version attached to this mail.
Stepan
2006-03-17 Stepan Kasal [EMAIL PROTECTED]
* lib/m4sugar/m4sh.m4 (AS_BOURNE_COMPATIBLE): Removed BIN_SH=xpg4,
moved DUALCASE=1 ...
(AS_SHELL_SANITIZE): ... here.
* doc/autoconf.texi (Special Shell Variables) BIN_SH: Do not say
that it is set.
Index: lib/m4sugar/m4sh.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v
retrieving revision 1.162
diff -u -r1.162 m4sh.m4
--- lib/m4sugar/m4sh.m4 16 Mar 2006 13:33:18 - 1.162
+++ lib/m4sugar/m4sh.m4 17 Mar 2006 15:20:12 -
@@ -172,8 +172,6 @@
else
case `(set -o) 2/dev/null` in *posix*) set -o posix;; esac
fi
-BIN_SH=xpg4; export BIN_SH # for Tru64
-DUALCASE=1; export DUALCASE # for MKS sh
])
@@ -320,6 +318,7 @@
## - ##
AS_BOURNE_COMPATIBLE
+DUALCASE=1; export DUALCASE # for MKS sh
# PATH needs CR
_AS_CR_PREPARE
Index: doc//autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.967
diff -u -r1.967 autoconf.texi
--- doc/autoconf.texi 17 Mar 2006 03:59:05 - 1.967
+++ doc/autoconf.texi 17 Mar 2006 17:19:17 -
@@ -11091,7 +11091,6 @@
@evindex BIN_SH
In Tru64, if @env{BIN_SH} is set to @code{xpg4}, subsidiary invocations of
the standard shell conform to Posix.
-Autoconf-generated scripts export this variable when they start up.
@item CDPATH
@evindex CDPATH
Tru64/OSF: BIN_SH revisited
This started out here and here:
http://lists.gnu.org/archive/html/libtool/2004-07/msg00070.html
http://lists.gnu.org/archive/html/autoconf-patches/2004-07/msg3.html
and led to (CVS) Autoconf exporting BIN_SH=xpg4 (don't be fooled by the
patches posted; they do not fully reflect what was committed :-/ ).
Given a package using CVS Autoconf and (1.5.x or HEAD) Libtool. On OSF,
the configure script will restart itself with /bin/sh, but with
BIN_SH=xpg4 in the environment. So 'sh' starts the posix shell,
/usr/bin/posix/sh[1]. There is no good `echo' on the system, but that
posix shell understands `print -r', so this is what $ECHO gets set to in
Libtool's _LT_PROG_ECHO_BACKSLASH (named _LT_AC_PROG_ECHO_BACKSLASH in
branch-1-5).
But then building fails: `libtool' is executed but not with $BIN_SH set
in its environment, so the Bourne shell is invoked, which does not know
`print'. The next time config.status is started by `make', BIN_SH won't
be set beforehand either, so it will barf heavily, too.
I see several ways out of this:
0a) Revert the change to set BIN_SH in Autoconf, in order to be
consistent.
0b) Additionally, prepend /usr/bin/posix/ to the path walk of
_AS_DETECT_BETTER_SHELL, to choose the right shell right away, inside
Autoconf.
1) Always restart with BIN_SH set in both config.status and libtool.
Ugh!
2) Document that the user please do
BIN_SH=xpg4; export BIN_SH
in his environment (or set CONFIG_SHELL). Not so nice, but possible.
3) Get the right shell, but only in Libtool:
We could try to choose /usr/bin/posix/sh before testing whether `print
-r' works. That we this gets us the right shell, sets SHELL accordingly
in Makefile, and thus all should be well.
The first patch below does (0b), the second (3). I'm tending toward
(0b), unsure whether to add (0a) for good measure. What do you think?
Note HP-UX and AIX also have /usr/bin/posix/sh. With (0b), we still
choose /bin/sh on AIX; and /usr/bin/posix/sh on HP-UX 10.20, which seems
ok. Did I forget any relevant systems[1]?
It should be noted that so far, no stable Autoconf release exists which
forces Libtool to support this issue; it would thus be good to be fixed
before the release.
Please note that the Posix shell understands `print -r -' as well; but
since the separator is an orthogonal issue, I don't want to attack it in
Libtool ATM.
Cheers,
Ralf
[1] To see what /usr/bin/posix/sh is on some systems:
http://www.in-ulm.de/~mascheck/various/shells/
* lib/m4sugar/m4sh.m4 (_AS_DETECT_BETTER_SHELL): Prepend
the directory `/usr/bin/posix' in the shell search, to prefer
the Posix shell not only in subsequent spawns as with `$BIN_SH'
on Tru64.
Index: lib/m4sugar/m4sh.m4
===
RCS file: /cvsroot/autoconf/autoconf/lib/m4sugar/m4sh.m4,v
retrieving revision 1.162
diff -u -r1.162 m4sh.m4
--- lib/m4sugar/m4sh.m4 16 Mar 2006 13:33:18 - 1.162
+++ lib/m4sugar/m4sh.m4 16 Mar 2006 21:00:53 -
@@ -226,7 +226,7 @@
_AS_RUN([_AS_DETECT_SUGGESTED_BODY]) 2 /dev/null],
[],
[as_candidate_shells=
-_AS_PATH_WALK([/bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH],
+
_AS_PATH_WALK([/usr/bin/posix$PATH_SEPARATOR/bin$PATH_SEPARATOR/usr/bin$PATH_SEPARATOR$PATH],
[case $as_dir in
/*)
for as_base in sh bash ksh sh5; do
* libltdl/m4/libtool.m4 (_LT_PROG_ECHO_BACKSLASH): If we could
not find a working `echo' program, try whether /usr/bin/posix/sh
exists before trying `print -r'; /usr/bin/posix/sh gets us the
Posix shell whether or not BIN_SH was set before. Allows to
build libtool on OSF.
Index: libltdl/m4/libtool.m4
===
RCS file: /cvsroot/libtool/libtool/libltdl/m4/libtool.m4,v
retrieving revision 1.60
diff -u -r1.60 libtool.m4
--- libltdl/m4/libtool.m4 9 Feb 2006 16:04:01 - 1.60
+++ libltdl/m4/libtool.m4 16 Mar 2006 21:00:45 -
@@ -997,7 +997,18 @@
if test X$ECHO = Xecho; then
# We didn't find a better echo, so look for alternatives.
- if test X`{ print -r '\t'; } 2/dev/null` = 'X\t'
+ # We have to test Tru64 /usr/bin/posix/sh before testing
+ # `print -r', because a restart with BIN_SH=xpg4 would have
+ # given us this shell, but we then need this reflected in $SHELL.
+ if test -f /usr/bin/posix/sh
+ test X$CONFIG_SHELL != X/usr/bin/posix/sh; then
+# If we have posix/sh, try running configure again with it.
+ORIGINAL_CONFIG_SHELL=${CONFIG_SHELL-/bin/sh}
+export ORIGINAL_CONFIG_SHELL
+CONFIG_SHELL=/usr/bin/posix/sh
+export CONFIG_SHELL
+exec $CONFIG_SHELL [$]0 --no-reexec ${1+[$]@}
+ elif test X`{ print -r '\t'; } 2/dev/null` = 'X\t'
echo_testing_string=`{ print -r $echo_test_string; } 2/dev/null`
test X$echo_testing_string =
Re: Tru64/OSF: BIN_SH revisited
Ralf Wildenhues [EMAIL PROTECTED] writes: 0a) Revert the change to set BIN_SH in Autoconf, in order to be consistent. 0b) Additionally, prepend /usr/bin/posix/ to the path walk of _AS_DETECT_BETTER_SHELL, to choose the right shell right away, inside Autoconf. This sounds good to me. The first patch below does (0b), the second (3). I'm tending toward (0b), unsure whether to add (0a) for good measure. What do you think? (0b) is good. I see your point about (0a) but let's go ahead and try it, for Autoconf. Thanks.
