+2000-08-04 Akim Demaille <akim@epita.fr>
+
+ 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 <akim@epita.fr>
* acgeneral.m4: (AC_RUN_IFELSE, AC_LINK_IFELSE, AC_COMPILE_IFELSE):
# 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'])
## --------------------------------------------------- ##
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{:})
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}
# 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'])
## --------------------------------------------------- ##
projects / thirdparty / autoconf.git / commitdiff
