Re: document AS_BASENAME

[Eric Blake]

Hi Ralf,

> > 
> > After my recent patch submission to coreutils, GNU dirname/basename will
> > now return // on platforms (for now, cygwin) that have // distinct from /.
> >  So the documentation needs an update; in the process, I noticed that
> > AS_DIRNAME is documented but not AS_BASENAME.
> 
> Yep.  I always thought that was because `basename' is fairly portable.

The problem is not so much whether basename/dirname conform to
POSIX (although that is an issue), but whether they even exist.  The
AS_ variants do try basename/dirname before falling back on expr/sed.
But looking at the source to AS_BASENAME, even recent Solaris
mishandles "basename /" with an empty line instead of "/".

However, I just noticed that AS_BASENAME does not do suffix
stripping (such as "AS_BASENAME([foo.c], [.c])" expanding to
"foo"), so I have the bigger task of actually implementing that
portably in m4sh before this patch can be applied.

> 
> > Also, do we want to remove this line about m4sh, that was picked up in the
> > context of my first hunk? "For the time being, it is not mature enough to
> > be widely used."
> 
> If you'd like an opinion, I'd still like a warning, maybe a bit weaker
> than that.  The discussion about my pending documentation patch also
> shows how immature it still is.

OK, I'll work up an alternative wording when I resubmit my patch.

> 
> A small nit:
> 
> > address@hidden AS_BASENAME (@var{file-name})
> > address@hidden
> > +Return the filename portion of @var{file-name}, using the algorithm
> > +required by Posix.  @xref{Limitations of Usual Tools}, for more
> 
> Required?  See below.
> 
> > +details about what this returns and why it is more portable than the
> > address@hidden command.
> > address@hidden defmac


> > +Unfortunately, neither of the above commands work if @code{$file} ends
> > +in newline, since @address@hidden removes all trailing newlines.
> > +
> > address@hidden
> > +This handles a few subtleties in the standard way required by
> > +Posix.  For example, Posix permits implementations to treat leading
> > address@hidden//} with special semantics,
> 
> I sense a contradiction between "required" and "permits" here.

POSIX provides an algorithm for basename that is deterministic
for all input except "" and "//", and for those two, mandates that
an implementation must output either "" or "." for the former,
and either "/" or "//" for the latter.  Likewise, dirname is
deterministic for everything except "//", where the choice is
still limited to "/" or "//".  But I can see how adding more
words to this effect (or something similar to Paul's original
example of "//1") could clarify the situation.  I'll give it another
shot.

> Are there basename implementations that turn /// into ///?

Not that I am aware of.

> If yes, that does not get very clear here, and I think the
> previous quoted comment by Paul was a bit clearer here.

-- 
Eric Blake