Re: AC_PREFIX_PATH, AS_BASENAME fixes and a new test!

[Paul Eggert]

> From: Akim Demaille <address@hidden>
> Date: 17 Sep 2001 16:12:31 +0200
> 
> | Perhaps this should refer to the AS_DIRNAME macro, as it is actually
> | guaranteed to work, since it has the sed fallback...
> 
> This might no be the proper place to document AS_DIRNAME, but it it OK
> to document the expr and sed based alternative in their full length.

Would that be wise?  The alternative is really tricky and is easy to
get wrong.  (We got it wrong ourselves -- and perhaps it's still
wrong.  :-)

I think it'd be better to document AS_DIRNAME instead.
Something like this, perhaps?

2001-09-17  Paul Eggert  <address@hidden>

        * doc/autoconf.texi (Common Shell Constructs): New node,
        documenting AS_DIRNAME.
        (Limitations of Usual Tools): Refer to it when discussing dirname.
        Also, update discussion of POSIX standard to reflect latest draft.

--- doc/autoconf.texi-1 Mon Sep 17 18:10:19 2001
+++ doc/autoconf.texi   Mon Sep 17 18:28:51 2001
@@ -320,6 +320,7 @@ Programming in M4sugar
 
 * Redefined M4 Macros::         M4 builtins changed in M4sugar
 * Forbidden Patterns::          Catching unexpanded macros
+* Common Shell Constructs::     Working around shell portability problems
 
 Writing Autoconf Macros
 
@@ -6688,6 +6689,8 @@ M4sugar''.
 @menu
 * Redefined M4 Macros::         M4 builtins changed in M4sugar
 * Forbidden Patterns::          Catching unexpanded macros
+* Common Shell Constructs::     Working around shell portability problems
+
 @end menu
 
 @node Redefined M4 Macros
@@ -6791,7 +6794,19 @@ Any token matching @var{pattern} is allo
 @code{m4_pattern_forbid} pattern.
 @end defmac
 
address@hidden Common Shell Constructs
address@hidden Common Shell Constructs
+
+M4sugar provides portable alternatives for some common shell constructs
+that unfortunately are not portable in practice.
 
address@hidden AS_DIRNAME (@var{pathname})
address@hidden DIRNAME
+Return the directory portion of @var{pathname}, using the algorithm
+required by @sc{posix}.  @xref{Limitations of Usual Tools}, for more
+details about what this returns and why it is more portable than the
address@hidden command.
address@hidden defmac
 
 @c=================================================== Writing Autoconf Macros.
 
@@ -8746,17 +8761,18 @@ Some implementations, such as Tru64's, f
 @item @command{dirname}
 @c --------------------
 @prindex @command{dirname}
-Not all hosts have @command{dirname}, but it is reasonably easy to
-emulate, e.g.:
+Not all hosts have a working @command{dirname}, and you should instead
+use @code{AS_DIRNAME} (@pxref{Common Shell Constructs}).  For example.
 
 @example
-dir=`expr "x$file" : 'x\(.*\)/[^/]*' \|
-          '.'      : '.'
+dir=`dirname "$file"` # This is not portable.
+dir=`AS_DIRNAME(["$file"])` # This is more portable.
 @end example
 
 @noindent
-But there are a few subtilities, e.g., under UN*X, should @samp{//1}
-give @samp{/}?  Paul Eggert answers:
+This handles a few subtleties in the standard way required by
address@hidden  For example, under UN*X, should @samp{dirname //1} give
address@hidden/}?  Paul Eggert answers:
 
 @quotation
 No, under some older flavors of Unix, leading @samp{//} is a special
@@ -8766,15 +8782,11 @@ to @samp{/}; but leading @samp{//} is sp
 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{//}.
address@hidden 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