dirname.
+2000-11-02 Akim Demaille <akim@epita.fr>
+
+ * doc/autoconf.texi (Limitations of Usual Tools): Some about
+ dirname.
+
2000-11-02 Pavel Roskin <proski@gnu.org>
* ifnames.sh: Put the opening brace on the same line with
Aaaaarg!
@end example
+
@item @command{cat}
@cindex @command{cat}
Don't rely on any option.
+
+@item @command{dirname}
+@cindex @command{dirname}
+Not all hosts have @command{dirname}, but it is reasonably easy to
+emulate, e.g.:
+
+@example
+dir=`expr "x$file" : 'x\(.*\)/[^/]*' \|
+ '.' : '.'
+@end example
+
+@noindent
+But there are a few subtilities, e.g., under UN*X, should @samp{//1}
+give @samp{/}? Paul Eggert answers:
+
+@quotation
+No, under some older flavors of Unix, leading @samp{//} is a special
+path name: it refers to a "super-root" and is used to access other
+machines' files. Leading @samp{///}, @samp{////}, etc. are equivalent
+to @samp{/}; but leading @samp{//} 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 @samp{//}.
+It says that the behavior of dirname on path names of the form
+@samp{//([^/]+/*)?} is implementation defined. In these cases, GNU
+@command{dirname} returns @samp{/}, but it's more portable to return
+@samp{//} as this works even on those older flavors of Unix.
+
+I have heard rumors that this special treatment of @samp{//} may be
+dropped in future versions of POSIX, but for now it's still the
+standard.
+@end quotation
+
+
@item @command{egrep}
@cindex @command{egrep}
The empty alternative is not portable, use @samp{?} instead. For
# Simulate running `dirname(1)' on PATHNAME, not all systems have it.
# This macro must be usable from inside ` `.
#
-# 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.
-#
# 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
# Simulate running `dirname(1)' on PATHNAME, not all systems have it.
# This macro must be usable from inside ` `.
#
-# 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.
-#
# 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