Re: ksh bug on Tru64 UNIX causes current libtool failure
Ralf Wildenhues [EMAIL PROTECTED] writes:
* doc/autoconf.texi (Limitations of Builtins) case: Mention
Tru64 ksh pattern matching bug.
Thanks. I installed the following slightly-different patch into
autoconf.
--- autoconf.texi 8 Jun 2005 07:13:50 - 1.907
+++ autoconf.texi 8 Jun 2005 07:55:29 - 1.908
@@ -10899,6 +10899,16 @@ $
Even with this, SunOS 5.7 ksh matches a backslash if the set contains any
of the characters @samp{|}, @samp{}, @samp{(}, or @samp{)}.
+Conversely, Tru64 @command{ksh} (circa 2003) erroneously always matches
+a closing parenthesis if not specified in a character class:
+
[EMAIL PROTECTED]
+$ @kbd{case foo in *\)*) echo fail ;; esac}
+fail
+$ @kbd{case foo in *')'*) echo fail ;; esac}
+fail
[EMAIL PROTECTED] example
+
Some shells, such as Ash 0.3.8, are confused by an empty
@code{case}/@code{esac}:
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
[ This thread starts at
http://lists.gnu.org/archive/html/libtool/2005-05/msg00137.html
and continues at
http://lists.gnu.org/archive/html/libtool/2005-06/msg5.html ]
* Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST:
On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
Could you as well please: run the script I sent in another message in
this thread and report the exact ksh version this is on, so we can
mention it in the Autoconf portability section?
[EMAIL PROTECTED] [~] /bin/ksh
$ set -o emacs
$ Version M-11/16/88f
Proposed patch for autoconf.texi below.
Regards,
Ralf
* doc/autoconf.texi (Limitations of Builtins) case: Mention
Tru64 ksh pattern matching bug. Reported against Libtool by
Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].
Index: doc/autoconf.texi
===
RCS file: /cvsroot/autoconf/autoconf/doc/autoconf.texi,v
retrieving revision 1.906
diff -u -r1.906 autoconf.texi
--- doc/autoconf.texi 6 Jun 2005 08:01:32 - 1.906
+++ doc/autoconf.texi 7 Jun 2005 09:15:29 -
@@ -10931,6 +10931,14 @@
Even with this, SunOS 5.7 ksh matches a backslash if the set contains any
of the characters @samp{|}, @samp{}, @samp{(}, or @samp{)}.
+On the other hand, Tru64 ksh erroneously always matches a closing parenthesis
+if not specified in a character class:
+
[EMAIL PROTECTED]
+$ @kbd{case foo in *\)*) echo false ;; esac}
+false
[EMAIL PROTECTED] example
+
Some shells, such as Ash 0.3.8, are confused by an empty
@code{case}/@code{esac}:
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
Hi Nicolas,
* Nicolas Joly wrote on Thu, Jun 02, 2005 at 01:02:32AM CEST:
On Wed, May 25, 2005 at 06:22:37PM +0200, Ralf Wildenhues wrote:
OK to apply this patch to branch-2-0 and HEAD, and then backport to
branch-1-5?
Sorry for the delay.
No problem. Sorry for not providing a branch-1-5 patch right away.
The backport is straightforward, patch below.
OTOH..
Unfortunately, i was unable to bootstrap libtool HEAD on my Tru64 unix
workstation. Next step was to bootstrap it on another machine
(NetBSD/amd64); back to the Tru64 machine ... another failure.
that just helped us find more HEAD bug(s). :-/
First, could you post the exact output of `bootstrap' on Tru64?
The first failure seems to be related to missing `print' command in
default `/bin/sh':
[EMAIL PROTECTED] [~] /bin/sh
$ print -r '\t'
print: not found
[EMAIL PROTECTED] [~] BIN_SH=xpg4 /bin/sh
$ print -r '\t'
\t
Oh, brother. How do we solve this? I suppose
$ /bin/sh
$ BIN_SH=xpg4; export BIN_SH
$ print -r '\t'
does not work, right? Can we set
CONFIG_SHELL = BIN_SH=xpg4 /bin/sh
(and also SHELL) in the Makefile? I can easily spot places where this
breaks in our own Makefile.am, let alone any client Makefile's.
We could have near the top of libtool something like
case $host in
$whatever_fits_tru64) BIN_SH=xpg4 exec $SHELL ${1+$@} ;;
esac
Alternatively, the better option might be to tweak *DETECT_BETTER_SHELL
to prefer ksh over bin/sh..
[EMAIL PROTECTED] [~] /bin/ksh
$ print -r '\t'
\t
but that sucks too, as it has nontrivial consequences on other systems.
Or maybe search for ksh before testing `print -r'..
By the way, since tru64 seems a rather interesting target for libtool:
If anyone could provide access to such a system, it would be easier to
prevent regressions.
Regards,
Ralf
* ltmain.in (compile mode): In order to find out
about forbidden characters in output, check with grep after checking
func_quote_for_eval result. Also, warn instead of fail.
(func_infer_tag, compile mode, link mode, install mode):
Revert SunOS sh bug workaround patch from 2004-12-28 as it
triggers bugs in the Tru64 5.1B shell.
Reported by Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].
Index: ltmain.in
===
RCS file: /cvsroot/libtool/libtool/Attic/ltmain.in,v
retrieving revision 1.334.2.70
diff -u -r1.334.2.70 ltmain.in
--- ltmain.in 31 May 2005 03:47:34 - 1.334.2.70
+++ ltmain.in 2 Jun 2005 08:34:11 -
@@ -133,7 +133,6 @@
execute_dlfiles=
lo2o=s/\\.lo\$/.${objext}/
o2lo=s/\\.${objext}\$/.lo/
-quote_scanset='[[~#^*{};?''' ]'
#
# Shell function definitions:
@@ -192,7 +191,7 @@
CC_quoted=
for arg in $CC; do
case $arg in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \ ]*|*]*|)
arg=\$arg\
;;
esac
@@ -213,7 +212,7 @@
for arg in $CC; do
# Double-quote args containing other shell metacharacters.
case $arg in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \ ]*|*]*|)
arg=\$arg\
;;
esac
@@ -627,7 +626,7 @@
# Many Bourne shells cannot handle close brackets correctly
# in scan sets, so we specify it separately.
case $arg in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \ ]*|*]*|)
arg=\$arg\
;;
esac
@@ -662,7 +661,7 @@
# in scan sets (worked around with variable expansion),
# and furthermore cannot handle '|' '' '(' ')' in scan sets
# at all, so we specify them separately.
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]*|*]*|)
lastarg=\$lastarg\
;;
esac
@@ -737,13 +736,12 @@
qlibobj=`$echo X$libobj | $Xsed -e $sed_quote_subst`
case $qlibobj in
- *$quote_scanset* | *]* | *\|* | *\* | *\(* | *\)* | )
+ *[\[\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]*|*]*|)
qlibobj=\$qlibobj\ ;;
esac
-if test X$libobj != X$qlibobj; then
- $echo $modename: libobj name \`$libobj' may not contain shell special
characters.
- exit $EXIT_FAILURE
-fi
+test X$libobj != X$qlibobj \
+$echo X$libobj | grep '[]~#^*{};?''' ()|`$[]' \
+$echo $modename: libobj name \`$libobj' may not contain shell
special characters.
objname=`$echo X$obj | $Xsed -e 's%^.*/%%'`
xdir=`$echo X$obj | $Xsed -e 's%/[^/]*$%%'`
if test X$xdir = X$obj; then
@@ -824,7 +822,7 @@
fi
qsrcfile=`$echo X$srcfile | $Xsed -e $sed_quote_subst`
case $qsrcfile in
- *$quote_scanset* | *]* | *\|* |
Re: ksh bug on Tru64 UNIX causes current libtool failure
Greetings, On 2005 Jun 2 , at 10.37, Ralf Wildenhues wrote: Alternatively, the better option might be to tweak *DETECT_BETTER_SHELL to prefer ksh over bin/sh.. I don't really want to intervene in this debate, but: wince. ksh has at least the unfortunate property that all file descriptors other than 0, 1, 2 are closed before an exec, and so aren't inherited by process children. Ksh seems unique in this, though it isn't listed as a problem in the autoconf section on shell portability issues. It's not a major problem -- and may not be a problem at all for libtool -- but it does make some otherwise attractive idioms impossible. By the way, since tru64 seems a rather interesting target for libtool: Oooh yes; oh yes indeedy. I've come to the conclusion that if your application builds on Tru64 and OS X, then it'll build just about anywhere. All the best, Norman -- -- Norman Gray : Physics Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk
Re: ksh bug on Tru64 UNIX causes current libtool failure
Ralf, On 2005 Jun 2 , at 13.03, Ralf Wildenhues wrote: ksh has at least the unfortunate property that all file descriptors other than 0, 1, 2 are closed before an exec, and so aren't inherited by process children. Ksh seems unique in this, though it isn't listed as a problem in the autoconf section on shell portability issues. It's not a major problem -- and may not be a problem at all for libtool -- but it does make some otherwise attractive idioms impossible. Could you be bothered to suggest a patch to the Autoconf folks? A good idea -- I'll do that. Aside from that, do you use this within any autoconf-generated configure scripts? Because the modified search *will* affect any package that uses AC_PROG_LIBTOOL aka LT_INIT. I did use this (inheriting FDs) in autoconf macros at one time, but had to rip it out when I discovered that autoconf-generated configure scripts preferred ksh to /bin/sh on Tru64, because /bin/sh didn't support $LINENO (as if I cared!). Hehe. I believe Libtool has got OS X covered quite well, unlike Tru64 (and maybe IRIX, HPUX). Libraries are a headache on OS X, but not in any way libtool can help with, unfortunately. For what it's worth, in managing the build of a large software set libtool has always been fine for me on Tru64. So thanks for that All the best, Norman -- -- Norman Gray : Physics Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: Oooh yes; oh yes indeedy. I've come to the conclusion that if your application builds on Tru64 and OS X, then it'll build just about anywhere. I'm surprised by this comment. Tru64 has a more common C API than say AIX or IRIX, and I think HP-UX has only recently caught up some. I've always found it easier to port to Tru64 than the aforementioned platforms. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
Tim, On 2005 Jun 2 , at 17.50, Tim Mooney wrote: In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: Oooh yes; oh yes indeedy. I've come to the conclusion that if your application builds on Tru64 and OS X, then it'll build just about anywhere. I'm surprised by this comment. Tru64 has a more common C API than say AIX or IRIX, and I think HP-UX has only recently caught up some. I've always found it easier to port to Tru64 than the aforementioned platforms. I can't speak for Ralf, but for me Tru64 has always been useful because it has an agreeably bad-tempered set of C and Fortran compilers, which stamp their feet and sulk at almost any sort of non-standard behaviour, along with a slightly quixotic set of C headers, which test how well my code is conditionalised for portability. Alphas also have a store-0 rounding mode by default, which tests another category of portability problems. But this is perhaps drifting a little off-topic for the libtool list. All the best, Norman -- -- Norman Gray : Physics Astronomy, Glasgow University, UK http://www.astro.gla.ac.uk/users/norman/ : www.starlink.ac.uk ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 25, 2005 at 06:22:37PM +0200, Ralf Wildenhues wrote: [ Alexander, the patch to work around shell bugs on your platform breaks on other ones. As the failure on yours are more harmless, I'd like to revert them. See the thread on the libtool mailing list. ] * Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST: On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote: * Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST: I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B workstation: *snip* /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o ltdl.lo ltdl.c libtool: compile: libobj name `ltdl.lo' may not contain shell special characters. *** Exit 1 That'll teach me to ever do fatal errors based on shell correctness assumptions again. :( OK to apply this patch to branch-2-0 and HEAD, and then backport to branch-1-5? Sorry for the delay. Unfortunately, i was unable to bootstrap libtool HEAD on my Tru64 unix workstation. Next step was to bootstrap it on another machine (NetBSD/amd64); back to the Tru64 machine ... another failure. The first failure seems to be related to missing `print' command in default `/bin/sh': [EMAIL PROTECTED] [~] /bin/sh $ print -r '\t' print: not found [EMAIL PROTECTED] [~] BIN_SH=xpg4 /bin/sh $ print -r '\t' \t [EMAIL PROTECTED] [~] /bin/ksh $ print -r '\t' \t gmake[3]: Entering directory `/home/njoly/temp/libtool-2.1a/libltdl' source='loaders/preopen.c' object='libltdl_la-preopen.lo' libtool=yes \ DEPDIR=.deps depmode=tru64 /bin/sh ../config/depcomp \ /bin/sh ../libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H=config.h -DLTDL -I. -I. -I.. -DLTDLOPEN=libltdl -I. -I. -I./libltdl -g -c -o libltdl_la-preopen.lo `test -f 'loaders/preopen.c' || echo './'`loaders/preopen.c ../libtool: print: not found ../libtool: print: not found ../libtool: : Permission denied ../libtool: print: not found sh: /: cannot execute gmake[3]: *** [libltdl_la-preopen.lo] Error 1 -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris.
Re: ksh bug on Tru64 UNIX causes current libtool failure
[ Alexander, the patch to work around shell bugs on your platform breaks
on other ones. As the failure on yours are more harmless, I'd like to
revert them. See the thread on the libtool mailing list. ]
* Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST:
On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
* Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST:
I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B
workstation:
*snip*
/bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.
-I. -g -c -o ltdl.lo ltdl.c
libtool: compile: libobj name `ltdl.lo' may not contain shell special
characters.
*** Exit 1
That'll teach me to ever do fatal errors based on shell correctness
assumptions again. :(
OK to apply this patch to branch-2-0 and HEAD, and then backport to
branch-1-5?
BTW, I have been working on actually allowing these special characters
in object file names. Just not done yet (and that will certainly not be
backported).
Regards,
Ralf
* config/ltmain.m4sh (func_mode_compile): In order to find out
about forbidden characters in output, check with grep after checking
func_quote_for_eval result. Also, warn instead of fail.
* config/general.m4sh (func_quote_for_eval, func_quote_for_expand):
Revert SunOS sh bug workaround patch from 2004-12-28 as it
triggers bugs in the Tru64 5.1B shell.
Reported by Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.66
diff -u -r1.66 ltmain.m4sh
--- config/ltmain.m4sh 27 Apr 2005 11:30:38 - 1.66
+++ config/ltmain.m4sh 25 May 2005 16:06:23 -
@@ -1228,7 +1228,8 @@
func_quote_for_eval $libobj
test X$libobj != X$func_quote_for_eval_result \
- func_fatal_error libobj name \`$libobj' may not contain shell
special characters.
+ $ECHO X$libobj | $GREP ['[@:@~#^*{};?''' ()|`$@:@]'] \
+ func_warning libobj name \`$libobj' may not contain shell special
characters.
func_basename $obj
objname=$func_basename_result
func_dirname $obj /
Index: config/general.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/general.m4sh,v
retrieving revision 1.17
diff -u -r1.17 general.m4sh
--- config/general.m4sh 22 Apr 2005 10:10:30 - 1.17
+++ config/general.m4sh 25 May 2005 16:06:23 -
@@ -96,9 +96,6 @@
# Same as above, but do not quote variable references.
double_quote_subst='s/\([[`\\]]\)/\\\1/g'
-# Protect character class for func_quote_* by variable expansion.
-quote_scanset='[[@:@~#^*{};?''' ]]'
-
# Re-`\' parameter expansions in output of double_quote_subst that were
# `\'-ed in input to the same. If an odd number of `\' preceded a '$'
# in input to double_quote_subst, that '$' was protected from expansion.
@@ -286,11 +283,9 @@
# Double-quote args containing shell metacharacters to delay
# word splitting, command substitution and and variable
# expansion for a subsequent eval.
- # in scan sets, and some SunOS ksh mistreat backslash-escaping
- # in scan sets (worked around with variable expansion),
- # and furthermore cannot handle '|' '' '(' ')' in scan sets
- # at all, so we specify them separately.
- *$quote_scanset* | *@:@* | *\|* | *\* | *\(* | *\)* | )
+ # Many Bourne shells cannot handle close brackets correctly
+ # in scan sets, so we specify it separately.
+ *[[\@:@\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]]*|*@:@*|)
func_quote_for_eval_result=\$func_quote_for_eval_unquoted_result\
;;
*)
@@ -316,11 +311,8 @@
# Double-quote args containing shell metacharacters to delay
# word splitting and command substitution for a subsequent eval.
# Many Bourne shells cannot handle close brackets correctly
- # in scan sets, and some SunOS ksh mistreat backslash-escaping
- # in scan sets (worked around with variable expansion),
- # and furthermore cannot handle '|' '' '(' ')' in scan sets
- # at all, so we specify them separately.
- *$quote_scanset* | *@:@* | *\|* | *\* | *\(* | *\)* | )
+ # in scan sets, so we specify it separately.
+ *[[\@:@\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]]*|*@:@*|)
my_arg=\$my_arg\
;;
esac
Re: ksh bug on Tru64 UNIX causes current libtool failure
[ Alexander, the patch to work around shell bugs on your platform breaks
on other ones. As the failure on yours are more harmless, I'd like to
revert them. See the thread on the libtool mailing list. ]
* Nicolas Joly wrote on Thu, May 19, 2005 at 12:39:43AM CEST:
On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
* Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST:
I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B
workstation:
*snip*
/bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I.
-I. -g -c -o ltdl.lo ltdl.c
libtool: compile: libobj name `ltdl.lo' may not contain shell special
characters.
*** Exit 1
That'll teach me to ever do fatal errors based on shell correctness
assumptions again. :(
OK to apply this patch to branch-2-0 and HEAD, and then backport to
branch-1-5?
BTW, I have been working on actually allowing these special characters
in object file names. Just not done yet (and that will certainly not be
backported).
Regards,
Ralf
* config/ltmain.m4sh (func_mode_compile): In order to find out
about forbidden characters in output, check with grep after checking
func_quote_for_eval result. Also, warn instead of fail.
* config/general.m4sh (func_quote_for_eval, func_quote_for_expand):
Revert SunOS sh bug workaround patch from 2004-12-28 as it
triggers bugs in the Tru64 5.1B shell.
Reported by Albert Chin [EMAIL PROTECTED] and
Nicolas Joly [EMAIL PROTECTED].
Index: config/ltmain.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/ltmain.m4sh,v
retrieving revision 1.66
diff -u -r1.66 ltmain.m4sh
--- config/ltmain.m4sh 27 Apr 2005 11:30:38 - 1.66
+++ config/ltmain.m4sh 25 May 2005 16:06:23 -
@@ -1228,7 +1228,8 @@
func_quote_for_eval $libobj
test X$libobj != X$func_quote_for_eval_result \
- func_fatal_error libobj name \`$libobj' may not contain shell
special characters.
+ $ECHO X$libobj | $GREP ['[@:@~#^*{};?''' ()|`$@:@]'] \
+ func_warning libobj name \`$libobj' may not contain shell special
characters.
func_basename $obj
objname=$func_basename_result
func_dirname $obj /
Index: config/general.m4sh
===
RCS file: /cvsroot/libtool/libtool/config/general.m4sh,v
retrieving revision 1.17
diff -u -r1.17 general.m4sh
--- config/general.m4sh 22 Apr 2005 10:10:30 - 1.17
+++ config/general.m4sh 25 May 2005 16:06:23 -
@@ -96,9 +96,6 @@
# Same as above, but do not quote variable references.
double_quote_subst='s/\([[`\\]]\)/\\\1/g'
-# Protect character class for func_quote_* by variable expansion.
-quote_scanset='[[@:@~#^*{};?''' ]]'
-
# Re-`\' parameter expansions in output of double_quote_subst that were
# `\'-ed in input to the same. If an odd number of `\' preceded a '$'
# in input to double_quote_subst, that '$' was protected from expansion.
@@ -286,11 +283,9 @@
# Double-quote args containing shell metacharacters to delay
# word splitting, command substitution and and variable
# expansion for a subsequent eval.
- # in scan sets, and some SunOS ksh mistreat backslash-escaping
- # in scan sets (worked around with variable expansion),
- # and furthermore cannot handle '|' '' '(' ')' in scan sets
- # at all, so we specify them separately.
- *$quote_scanset* | *@:@* | *\|* | *\* | *\(* | *\)* | )
+ # Many Bourne shells cannot handle close brackets correctly
+ # in scan sets, so we specify it separately.
+ *[[\@:@\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]]*|*@:@*|)
func_quote_for_eval_result=\$func_quote_for_eval_unquoted_result\
;;
*)
@@ -316,11 +311,8 @@
# Double-quote args containing shell metacharacters to delay
# word splitting and command substitution for a subsequent eval.
# Many Bourne shells cannot handle close brackets correctly
- # in scan sets, and some SunOS ksh mistreat backslash-escaping
- # in scan sets (worked around with variable expansion),
- # and furthermore cannot handle '|' '' '(' ')' in scan sets
- # at all, so we specify them separately.
- *$quote_scanset* | *@:@* | *\|* | *\* | *\(* | *\)* | )
+ # in scan sets, so we specify it separately.
+ *[[\@:@\~\#\^\\*\(\)\{\}\|\;\\\?\'\ \]]*|*@:@*|)
my_arg=\$my_arg\
;;
esac
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Sun, May 15, 2005 at 06:35:33AM +0200, Ralf Wildenhues wrote: Hi Albert, * Albert Chin wrote on Sun, May 15, 2005 at 04:27:05AM CEST: * ltmain.in: New variable quote_scanset to work around SunOS ksh `case' backslash-escaping bug: protect character class by variable expansion. Reported by Alexander Kurz [EMAIL PROTECTED]. Unfortunately, due to an apparent ksh bug on Tru64 UNIX, this breaks: Screaming in pain. case foobar in *\)*) echo bar ;; esac $ ./quote + echo bar bar I don't see an obvious workaround except for removing *\)* from the case statement. Well, how about using either *)* or *')'* as pattern? Does that work? If so (and if it works on the systems I have access to), I'll copy Alexander to see whether that works with his ksh as well. Neither work. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
Hi Albert,
* Albert Chin wrote on Tue, May 17, 2005 at 11:04:33PM CEST:
On Sun, May 15, 2005 at 06:35:33AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sun, May 15, 2005 at 04:27:05AM CEST:
case foobar in
*\)*)
echo bar ;;
esac
$ ./quote
+ echo bar
bar
I don't see an obvious workaround except for removing *\)* from the
case statement.
Well, how about using either *)* or *')'* as pattern? Does that work?
Neither work.
Does the following work?
pat=')'
case foobar in
*$pat*) echo bad;;
esac
case foo\\bar in
*$pat*) echo bad;;
esac
case foo\)bar in
*$pat*) ;;
*) echo bad;;
esac
Note that you also need to check for false negatives, unfortunately.
If not, let me see: This failure only causes quote.test to fail, and
causes a lot of extra quotes in the libtool output, but no real failure.
Is that correct?
Could you mail the output of attached script? Please replace echo by an
echo program which does not interpret backslashes, and the shell path
with the correct one.
Regards, and thanks,
Ralf
#! /bin/ksh
: ${echo='print -r'}
for t in \\ \| \ \; \ \ \( \) \$ \` \ \' \* \? \# \~ \= \% '[' ']' \{ \} '
' ' ' \* b
do
for c in '[\]' '[|]' '[]' '[;]' '[]' '[]' '[(]' '[)]' '[$]' '[`]' \
'[]' ['] '[?]' '[#]' '[~]' '[=]' '[%]' \
'[[]' '[]]' '[a^]' '[*]' '[{]' '[}]' '[ ]' '[]' '[*]' '[b]' \
'[\\]' '[\|]' '[\]' '[\;]' '[\]' '[\]' '[\(]' '[\)]' '[\$]'
'[\`]' \
'[\]' '[\''']' '[\?]' '[\#]' '[\~]' '[\=]' '[\%]' \
'[\[]' '[\]]' '[\^]' '[\*]' '[\{]' '[\}]' '[\ ]' '[\ ]' '[\*]'
'[\b]' \
'\' '|' '' ';' '' '' '(' ')' '$' '`' \
'' ' '?' '#' '~' '=' '%' \
'[' ']' '*' '{' '}' ' ' '' '*' 'b' \
'\\' '\|' '\' '\;' '\' '\' '\(' ')' '\$' '\`' \
'\' \' '\?' '\#' '\~' '\=' '\%' \
'\[' '\]' '\*' '\{' '\}' '\ ' '\ ' '\*' '\b'
do
case $t in
$c) $echo match: $t in $c.
esac
done
done | tr '\t' X
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 18, 2005 at 08:33:01AM +0200, Ralf Wildenhues wrote: If not, let me see: This failure only causes quote.test to fail, and causes a lot of extra quotes in the libtool output, but no real failure. Is that correct? Not really. I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B workstation: [EMAIL PROTECTED] [~] sizer -v Compaq Tru64 UNIX V5.1B (Rev. 2650); Fri Jun 18 18:36:47 CEST 2004 [EMAIL PROTECTED] [src/libtool-1.5.18] make No suffix list. Making all in . No suffix list. CONFIG_FILES=libtoolize CONFIG_HEADERS= /bin/ksh ./config.status config.status: creating libtoolize config.status: executing depfiles commands chmod +x libtoolize Making all in libltdl make all-am /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o ltdl.lo ltdl.c libtool: compile: libobj name `ltdl.lo' may not contain shell special characters. *** Exit 1 -- Nicolas Joly Biological Software and Databanks. Institut Pasteur, Paris. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 18, 2005 at 08:33:01AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Tue, May 17, 2005 at 11:04:33PM CEST:
On Sun, May 15, 2005 at 06:35:33AM +0200, Ralf Wildenhues wrote:
* Albert Chin wrote on Sun, May 15, 2005 at 04:27:05AM CEST:
case foobar in
*\)*)
echo bar ;;
esac
$ ./quote
+ echo bar
bar
I don't see an obvious workaround except for removing *\)* from the
case statement.
Well, how about using either *)* or *')'* as pattern? Does that work?
Neither work.
Does the following work?
pat=')'
case foobar in
*$pat*) echo bad;;
esac
case foo\\bar in
*$pat*) echo bad;;
esac
case foo\)bar in
*$pat*) ;;
*) echo bad;;
esac
I get the following output:
+ pat=)
+ echo bad
bad
+ echo bad
bad
The last 'echo bad' does not get executed.
If not, let me see: This failure only causes quote.test to fail, and
causes a lot of extra quotes in the libtool output, but no real failure.
Is that correct?
libtool no longer works on this platform.
Could you mail the output of attached script? Please replace echo by an
echo program which does not interpret backslashes, and the shell path
with the correct one.
Below. I used echo='print -r' as 'prnit -r' does not interpret
backslashes.
--
albert chin ([EMAIL PROTECTED])
-- snip snip
match: \ in [\].
match: \ in [\\].
match: \ in [\|].
match: \ in [\].
match: \ in [\;].
match: \ in [\].
match: \ in [\].
match: \ in [\(].
match: \ in [\)].
match: \ in [\$].
match: \ in [\`].
match: \ in [\].
match: \ in [\'].
match: \ in [\?].
match: \ in [\#].
match: \ in [\~].
match: \ in [\=].
match: \ in [\%].
match: \ in [\[].
match: \ in [\^].
match: \ in [\*].
match: \ in [\{].
match: \ in [\}].
match: \ in [\ ].
match: \ in [\X].
match: \ in [\*].
match: \ in [\b].
match: \ in \.
match: \ in ?.
match: \ in *.
match: \ in *.
match: \ in \*.
match: \ in \*.
match: | in [|].
match: | in [\|].
match: | in |.
match: | in ?.
match: | in *.
match: | in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: ; in [;].
match: ; in [\;].
match: ; in ;.
match: ; in ?.
match: ; in *.
match: ; in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: ( in [(].
match: ( in [\(].
match: ( in (.
match: ( in ?.
match: ( in *.
match: ( in *.
match: ) in [)].
match: ) in [\)].
match: ) in ).
match: ) in ?.
match: ) in *.
match: ) in *.
match: ) in ).
match: $ in [$].
match: $ in [\$].
match: $ in $.
match: $ in ?.
match: $ in *.
match: $ in *.
match: ` in [`].
match: ` in [\`].
match: ` in `.
match: ` in ?.
match: ` in *.
match: ` in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: ' in ['].
match: ' in [\'].
match: ' in '.
match: ' in ?.
match: ' in *.
match: ' in *.
match: * in [*].
match: * in [*].
match: * in [\*].
match: * in [\*].
match: * in ?.
match: * in *.
match: * in *.
match: ? in [?].
match: ? in [\?].
match: ? in ?.
match: ? in *.
match: ? in *.
match: # in [#].
match: # in [\#].
match: # in ?.
match: # in #.
match: # in *.
match: # in *.
match: ~ in [~].
match: ~ in [\~].
match: ~ in ?.
match: ~ in ~.
match: ~ in *.
match: ~ in *.
match: = in [=].
match: = in [\=].
match: = in ?.
match: = in =.
match: = in *.
match: = in *.
match: % in [%].
match: % in [\%].
match: % in ?.
match: % in %.
match: % in *.
match: % in *.
match: [ in [[].
match: [ in [\[].
match: [ in ?.
match: [ in [.
match: [ in *.
match: [ in *.
match: ] in []].
match: ] in ?.
match: ] in ].
match: ] in *.
match: ] in *.
match: { in [{].
match: { in [\{].
match: { in ?.
match: { in *.
match: { in {.
match: { in *.
match: } in [}].
match: } in [\}].
match: } in ?.
match: } in *.
match: } in }.
match: } in *.
match: in [ ].
match: in [\ ].
match: in ?.
match: in *.
match: in .
match: in *.
match: X in [X].
match: X in [\X].
match: X in ?.
match: X in *.
match: X in X.
match: X in *.
match: * in [*].
match: * in [*].
match: * in [\*].
match: * in [\*].
match: * in ?.
match: * in *.
match: * in *.
match: b in [b].
match: b in [\b].
match: b in ?.
match: b in *.
match: b in *.
match: b in b.
___
http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 18, 2005 at 05:03:05PM +0200, Nicolas Joly wrote: On Wed, May 18, 2005 at 08:33:01AM +0200, Ralf Wildenhues wrote: If not, let me see: This failure only causes quote.test to fail, and causes a lot of extra quotes in the libtool output, but no real failure. Is that correct? Not really. I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B workstation: [EMAIL PROTECTED] [~] sizer -v Compaq Tru64 UNIX V5.1B (Rev. 2650); Fri Jun 18 18:36:47 CEST 2004 [EMAIL PROTECTED] [src/libtool-1.5.18] make No suffix list. Making all in . No suffix list. CONFIG_FILES=libtoolize CONFIG_HEADERS= /bin/ksh ./config.status config.status: creating libtoolize config.status: executing depfiles commands chmod +x libtoolize Making all in libltdl make all-am /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o ltdl.lo ltdl.c libtool: compile: libobj name `ltdl.lo' may not contain shell special characters. *** Exit 1 This is a result of the ksh bug. -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
Hi Nicolas, * Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST: On Wed, May 18, 2005 at 08:33:01AM +0200, Ralf Wildenhues wrote: If not, let me see: This failure only causes quote.test to fail, and causes a lot of extra quotes in the libtool output, but no real failure. Is that correct? Not really. I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B workstation: *snip* /bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I. -g -c -o ltdl.lo ltdl.c libtool: compile: libobj name `ltdl.lo' may not contain shell special characters. *** Exit 1 That'll teach me to ever do fatal errors based on shell correctness assumptions again. :( Could you as well please: run the script I sent in another message in this thread and report the exact ksh version this is on, so we can mention it in the Autoconf portability section? Just to see whether I have missed any other occurrences: Does libtool compile and work with the patch below (except maybe a lot of extraneous quotes)? And for possible workarounds: Does Tru64 ship another shell suitable for use as CONFIG_SHELL? Please try with CONFIG_SHELL=/bin/foosh /bin/foosh path/to/libtool/configure [OPTIONS] I believe it might be the best to just completely back out the other patch again (as well as the one below). :( Regards, Ralf diff -u -r1.334.2.69 ltmain.in --- ltmain.in 4 May 2005 13:52:10 - 1.334.2.69 +++ ltmain.in 18 May 2005 21:07:44 - @@ -742,7 +742,6 @@ esac if test X$libobj != X$qlibobj; then $echo $modename: libobj name \`$libobj' may not contain shell special characters. - exit $EXIT_FAILURE fi objname=`$echo X$obj | $Xsed -e 's%^.*/%%'` xdir=`$echo X$obj | $Xsed -e 's%/[^/]*$%%'` ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: And for possible workarounds: Does Tru64 ship another shell suitable for use as CONFIG_SHELL? Please try with CONFIG_SHELL=/bin/foosh /bin/foosh path/to/libtool/configure [OPTIONS] You might try /usr/bin/posix/sh . I'm not sure if it's suitable; hopefully libtool's configure can determine that? As I recall, that's been available since version 4.0, so it's not an option for version 3.2g and earlier. Tim -- Tim Mooney [EMAIL PROTECTED] Information Technology Services (701) 231-1076 (Voice) Room 242-J6, IACC Building (701) 231-8541 (Fax) North Dakota State University, Fargo, ND 58105-5164 ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 18, 2005 at 11:09:21PM +0200, Ralf Wildenhues wrote:
Hi Nicolas,
* Nicolas Joly wrote on Wed, May 18, 2005 at 05:03:05PM CEST:
On Wed, May 18, 2005 at 08:33:01AM +0200, Ralf Wildenhues wrote:
If not, let me see: This failure only causes quote.test to fail, and
causes a lot of extra quotes in the libtool output, but no real failure.
Is that correct?
Not really.
I can't even compile libtool 1.5.18 on my Tru64 unix V5.1B
workstation:
*snip*
/bin/ksh ./libtool --tag=CC --mode=compile cc -DHAVE_CONFIG_H -I. -I. -I.
-g -c -o ltdl.lo ltdl.c
libtool: compile: libobj name `ltdl.lo' may not contain shell special
characters.
*** Exit 1
That'll teach me to ever do fatal errors based on shell correctness
assumptions again. :(
Could you as well please: run the script I sent in another message in
this thread and report the exact ksh version this is on, so we can
mention it in the Autoconf portability section?
[EMAIL PROTECTED] [~] /bin/ksh
$ set -o emacs
$ Version M-11/16/88f
script output attached.
Just to see whether I have missed any other occurrences: Does libtool
compile and work with the patch below (except maybe a lot of extraneous
quotes)?
It seems to work fine. I only noticed ksh quotation warnings and
quote.test failure ...
And for possible workarounds: Does Tru64 ship another shell suitable
for use as CONFIG_SHELL? Please try with
CONFIG_SHELL=/bin/foosh /bin/foosh path/to/libtool/configure [OPTIONS]
AFAIK only /bin/ksh and /bin/sh are available ...
I believe it might be the best to just completely back out the other
patch again (as well as the one below). :(
Regards,
Ralf
diff -u -r1.334.2.69 ltmain.in
--- ltmain.in 4 May 2005 13:52:10 - 1.334.2.69
+++ ltmain.in 18 May 2005 21:07:44 -
@@ -742,7 +742,6 @@
esac
if test X$libobj != X$qlibobj; then
$echo $modename: libobj name \`$libobj' may not contain shell special
characters.
- exit $EXIT_FAILURE
fi
objname=`$echo X$obj | $Xsed -e 's%^.*/%%'`
xdir=`$echo X$obj | $Xsed -e 's%/[^/]*$%%'`
___
http://lists.gnu.org/mailman/listinfo/libtool
--
Nicolas Joly
Biological Software and Databanks.
Institut Pasteur, Paris.
match: \ in [\].
match: \ in [\\].
match: \ in [\|].
match: \ in [\].
match: \ in [\;].
match: \ in [\].
match: \ in [\].
match: \ in [\(].
match: \ in [\)].
match: \ in [\$].
match: \ in [\`].
match: \ in [\].
match: \ in [\'].
match: \ in [\?].
match: \ in [\#].
match: \ in [\~].
match: \ in [\=].
match: \ in [\%].
match: \ in [\[].
match: \ in [\^].
match: \ in [\*].
match: \ in [\{].
match: \ in [\}].
match: \ in [\ ].
match: \ in [\X].
match: \ in [\*].
match: \ in [\b].
match: \ in \.
match: \ in ?.
match: \ in *.
match: \ in *.
match: \ in \*.
match: \ in \*.
match: | in [|].
match: | in [\|].
match: | in |.
match: | in ?.
match: | in *.
match: | in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: ; in [;].
match: ; in [\;].
match: ; in ;.
match: ; in ?.
match: ; in *.
match: ; in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: ( in [(].
match: ( in [\(].
match: ( in (.
match: ( in ?.
match: ( in *.
match: ( in *.
match: ) in [)].
match: ) in [\)].
match: ) in ).
match: ) in ?.
match: ) in *.
match: ) in *.
match: ) in ).
match: $ in [$].
match: $ in [\$].
match: $ in $.
match: $ in ?.
match: $ in *.
match: $ in *.
match: ` in [`].
match: ` in [\`].
match: ` in `.
match: ` in ?.
match: ` in *.
match: ` in *.
match: in [].
match: in [\].
match: in .
match: in ?.
match: in *.
match: in *.
match: ' in ['].
match: ' in [\'].
match: ' in '.
match: ' in ?.
match: ' in *.
match: ' in *.
match: * in [*].
match: * in [*].
match: * in [\*].
match: * in [\*].
match: * in ?.
match: * in *.
match: * in *.
match: ? in [?].
match: ? in [\?].
match: ? in ?.
match: ? in *.
match: ? in *.
match: # in [#].
match: # in [\#].
match: # in ?.
match: # in #.
match: # in *.
match: # in *.
match: ~ in [~].
match: ~ in [\~].
match: ~ in ?.
match: ~ in ~.
match: ~ in *.
match: ~ in *.
match: = in [=].
match: = in [\=].
match: = in ?.
match: = in =.
match: = in *.
match: = in *.
match: % in [%].
match: % in [\%].
match: % in ?.
match: % in %.
match: % in *.
match: % in *.
match: [ in [[].
match: [ in [\[].
match: [ in ?.
match: [ in [.
match: [ in *.
match: [ in *.
match: ] in []].
match: ] in ?.
match: ] in ].
match: ] in *.
match: ] in *.
match: { in [{].
match: { in [\{].
match: { in ?.
match: { in *.
match: { in {.
match: { in *.
match: } in [}].
match: } in [\}].
match: } in ?.
match: } in *.
match: } in }.
match: } in *.
match: in [ ].
match: in [\ ].
match: in ?.
match: in *.
match: in .
match: in *.
match: X in [X].
match: X in [\X].
match: X in ?.
match: X in *.
Re: ksh bug on Tru64 UNIX causes current libtool failure
On Wed, May 18, 2005 at 05:34:45PM -0500, Tim Mooney wrote: In regard to: Re: ksh bug on Tru64 UNIX causes current libtool failure,...: And for possible workarounds: Does Tru64 ship another shell suitable for use as CONFIG_SHELL? Please try with CONFIG_SHELL=/bin/foosh /bin/foosh path/to/libtool/configure [OPTIONS] You might try /usr/bin/posix/sh . I'm not sure if it's suitable; hopefully libtool's configure can determine that? $ ls -ldi /bin/ksh /usr/bin/posix/sh 3380 -rwxr-xr-x 2 bin bin 274400 Feb 7 2003 /bin/ksh 3380 -rwxr-xr-x 2 bin bin 274400 Feb 7 2003 /usr/bin/posix/sh -- albert chin ([EMAIL PROTECTED]) ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: ksh bug on Tru64 UNIX causes current libtool failure
Hi Albert, * Albert Chin wrote on Sun, May 15, 2005 at 04:27:05AM CEST: * ltmain.in: New variable quote_scanset to work around SunOS ksh `case' backslash-escaping bug: protect character class by variable expansion. Reported by Alexander Kurz [EMAIL PROTECTED]. Unfortunately, due to an apparent ksh bug on Tru64 UNIX, this breaks: Screaming in pain. case foobar in *\)*) echo bar ;; esac $ ./quote + echo bar bar I don't see an obvious workaround except for removing *\)* from the case statement. Well, how about using either *)* or *')'* as pattern? Does that work? If so (and if it works on the systems I have access to), I'll copy Alexander to see whether that works with his ksh as well. Regards, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
