From: Akim Demaille Date: Fri, 4 Aug 2000 09:13:16 +0000 (+0000) Subject: Solaris' /usr/ucb/expr, and SunOS' /usr/bin/expr fail with the `:' X-Git-Tag: autoconf-2.50~668 X-Git-Url: http://git.ipfire.org/cgi-bin/gitweb.cgi?a=commitdiff_plain;h=ee125c3a4e2ce30c7c4e11e575f09b55508914cf;p=thirdparty%2Fautoconf.git Solaris' /usr/ucb/expr, and SunOS' /usr/bin/expr fail with the `:' operator when \(\) is used, and matches a string longer than 120 characters. Reported by Geoff Keating. * doc/autoconf.texi (Limitations of Usual Tools): Some words about this. * acgeneral.m4 (_AC_SHELL_DIRNAME): Fall back to echo|sed if expr fails. From Paul Eggert. --- diff --git a/ChangeLog b/ChangeLog index 34037a9ea..e0910f960 100644 --- a/ChangeLog +++ b/ChangeLog @@ -1,3 +1,16 @@ +2000-08-04 Akim Demaille + + Solaris' /usr/ucb/expr, and SunOS' /usr/bin/expr fail with the `:' + operator when \(\) is used, and matches a string longer than 120 + characters. + Reported by Geoff Keating. + + * doc/autoconf.texi (Limitations of Usual Tools): Some words about + this. + * acgeneral.m4 (_AC_SHELL_DIRNAME): Fall back to echo|sed if expr + fails. + From Paul Eggert. + 2000-08-04 Akim Demaille * acgeneral.m4: (AC_RUN_IFELSE, AC_LINK_IFELSE, AC_COMPILE_IFELSE): diff --git a/acgeneral.m4 b/acgeneral.m4 index 80d1c466f..8f77e1bd0 100644 --- a/acgeneral.m4 +++ b/acgeneral.m4 @@ -796,26 +796,39 @@ done; } # Paul Eggert answers: # Question: Under UN*X, should `//1' give `/'? # -# No, under some older flavors of Unix, leading // is a special path -# name: it refers to a "super-root" and is used to access other -# machines' files. Leading ///, ////, etc. are equivalent to /; but -# leading // is special. I think this tradition started with Apollo -# Domain/OS, an OS that is still in use on some older hosts. -# -# POSIX.2 allows but does not require the special treatment for //. -# It says that the behavior of dirname on path names of the form -# //([^/]+/*)? is implementation defined. In these cases, GNU dirname -# returns /, but it's more portable to return // as this works even on -# those older flavors of Unix. -# -# I have heard rumors that this special treatment of // may be dropped -# in future versions of POSIX, but for now it's still the standard. +# No, under some older flavors of Unix, leading // is a special path +# name: it refers to a "super-root" and is used to access other +# machines' files. Leading ///, ////, etc. are equivalent to /; but +# leading // is special. I think this tradition started with Apollo +# Domain/OS, an OS that is still in use on some older hosts. +# +# POSIX.2 allows but does not require the special treatment for //. +# It says that the behavior of dirname on path names of the form +# //([^/]+/*)? is implementation defined. In these cases, GNU dirname +# returns /, but it's more portable to return // as this works even on +# those older flavors of Unix. +# +# I have heard rumors that this special treatment of // may be dropped +# in future versions of POSIX, but for now it's still the standard. +# +# Prefer expr to echo|sed, since expr is usually faster and it handles +# backslashes and newlines correctly. However, older expr +# implementations (e.g. SunOS 4 expr and Solaris 8 /usr/ucb/expr) have +# a silly length limit that causes expr to fail if the matched +# substring is longer than 120 bytes. So fall back on echo|sed if +# expr fails. define([_AC_SHELL_DIRNAME], [expr X$1 : 'X\(.*[[^/]]\)//*[[^/][^/]]*/*$' \| \ X$1 : 'X\(//\)[[^/]]' \| \ X$1 : 'X\(//\)$' \| \ X$1 : 'X\(/\)' \| \ - . : '\(.\)']) + . : '\(.\)' 2>/dev/null || +echo "X$1" | sed ' + /^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/p; q; } + /^X\(\/\/\)[^/].*/{ s//\1/p; q; } + /^X\(\/\/\)$/{ s//\1/p; q; } + /^X\(\/\).*/{ s//\1/p; q; } + s/.*/./p; q']) ## --------------------------------------------------- ## diff --git a/doc/autoconf.texi b/doc/autoconf.texi index b80e1a1c2..93f264ca7 100644 --- a/doc/autoconf.texi +++ b/doc/autoconf.texi @@ -5396,8 +5396,6 @@ the specification has been changed to match traditional Unix's behavior Avoid this portability problem by avoiding the empty string. - - Don't use @code{length}, @code{substr}, @code{match} and @code{index}. @item @command{expr} (@samp{:}) @@ -5405,6 +5403,11 @@ Don't use @code{length}, @code{substr}, @code{match} and @code{index}. Don't use @samp{\?}, @samp{\+} and @samp{\|} in patterns, they are not supported on Solaris. +Older @commant{expr} implementations (e.g. SunOS 4 @comamnd{expr} and +Solaris 8 @command{/usr/ucb/expr}) have a silly length limit that causes +@commant{expr} to fail if the matched substring is longer than 120 +bytes. In this case, you might want to fall back on @samp{echo|sed} if +@command{expr} fails. @item @command{grep} diff --git a/lib/autoconf/general.m4 b/lib/autoconf/general.m4 index 80d1c466f..8f77e1bd0 100644 --- a/lib/autoconf/general.m4 +++ b/lib/autoconf/general.m4 @@ -796,26 +796,39 @@ done; } # Paul Eggert answers: # Question: Under UN*X, should `//1' give `/'? # -# No, under some older flavors of Unix, leading // is a special path -# name: it refers to a "super-root" and is used to access other -# machines' files. Leading ///, ////, etc. are equivalent to /; but -# leading // is special. I think this tradition started with Apollo -# Domain/OS, an OS that is still in use on some older hosts. -# -# POSIX.2 allows but does not require the special treatment for //. -# It says that the behavior of dirname on path names of the form -# //([^/]+/*)? is implementation defined. In these cases, GNU dirname -# returns /, but it's more portable to return // as this works even on -# those older flavors of Unix. -# -# I have heard rumors that this special treatment of // may be dropped -# in future versions of POSIX, but for now it's still the standard. +# No, under some older flavors of Unix, leading // is a special path +# name: it refers to a "super-root" and is used to access other +# machines' files. Leading ///, ////, etc. are equivalent to /; but +# leading // is special. I think this tradition started with Apollo +# Domain/OS, an OS that is still in use on some older hosts. +# +# POSIX.2 allows but does not require the special treatment for //. +# It says that the behavior of dirname on path names of the form +# //([^/]+/*)? is implementation defined. In these cases, GNU dirname +# returns /, but it's more portable to return // as this works even on +# those older flavors of Unix. +# +# I have heard rumors that this special treatment of // may be dropped +# in future versions of POSIX, but for now it's still the standard. +# +# Prefer expr to echo|sed, since expr is usually faster and it handles +# backslashes and newlines correctly. However, older expr +# implementations (e.g. SunOS 4 expr and Solaris 8 /usr/ucb/expr) have +# a silly length limit that causes expr to fail if the matched +# substring is longer than 120 bytes. So fall back on echo|sed if +# expr fails. define([_AC_SHELL_DIRNAME], [expr X$1 : 'X\(.*[[^/]]\)//*[[^/][^/]]*/*$' \| \ X$1 : 'X\(//\)[[^/]]' \| \ X$1 : 'X\(//\)$' \| \ X$1 : 'X\(/\)' \| \ - . : '\(.\)']) + . : '\(.\)' 2>/dev/null || +echo "X$1" | sed ' + /^X\(.*[^/]\)\/\/*[^/][^/]*\/*$/{ s//\1/p; q; } + /^X\(\/\/\)[^/].*/{ s//\1/p; q; } + /^X\(\/\/\)$/{ s//\1/p; q; } + /^X\(\/\).*/{ s//\1/p; q; } + s/.*/./p; q']) ## --------------------------------------------------- ##