autoconf-patches
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: document AS_BASENAME


From: Stepan Kasal
Subject: Re: document AS_BASENAME
Date: Sat, 1 Apr 2006 21:20:56 +0200
User-agent: Mutt/1.4.1i

Hello Eric,

in short: this patch shall be put off after 2.60 release.

On Sat, Apr 01, 2006 at 09:47:47AM -0700, Eric Blake wrote:
> According to Stepan Kasal on 4/1/2006 8:35 AM:
> > I think it would be simpler to handle the corner cases once, by a shell
> > ``case,'' and use expr||sed only for the non-trivial one.
> 
> I like the idea.  Nits below.

thank you very much for your review.

> > -# This section is lexicographically sorted.
> > -
> 
> Why not sort it?  I just posted a patch along this line in another mail.

I committed your patch and refreshed my one then.

> > +AS_CASE([$1],
> > +  [[*[!/]/*[!/]*]],
> 
> Are negated character classes portable?

I thought so.  But in the node "(autoconf.info)Limitations of Builtins",
under the item "`test' (strings)", I found this:

     Alas, negated character classes are probably not portable,
     although no shell is known to not support the Posix syntax `[!...]'
        ...
     Many shells do not support the alternative syntax `[^...]'
     (Solaris, Digital Unix, etc.).

This means that my patch might be a bit risky.
I suggest to put it off now, and try it after 2.60.

> > +  [[//|//[!/]*]],
> > +    [(dirname $1) 2>/dev/null || echo //],
> 
> Save a process.

... only in the unusual case that the parameter starts with // ?

> I would just blindly echo, rather than trying to use dirname here.
> After all, on systems where // is not special, it is still
> a correct output, even if it doesn't match dirname.

Yes, but it may surprise the user of such system.
It's not worth it.

> > +  [//], [$as_basename $1 || echo //],
> 
> Likewise - just echo // rather than trying basename.

Likewise. ;-)

> > +  [''], [$as_basename $1 || echo .],
> 
> This bothers me a bit.  Normally, if "$file" does not exist, then 'cd
> `dirname "$file"`; ls `basename "$file"`' will also fail.  But by making
> the empty string evaluate to a valid filename, you are violating this
> assumption.

You meant
        cd `dirname "$file"`; ls "`basename "$file"`"
right?
But that wouldn't be portable, so you have to use
        cd `dirname "$file"`; base=`basename "$file"`; ls "$base"

With the code you used, ls would have been called with no parameter.
I think this episode shows that this whole issue is tricky.

My code is designed so that it gives the same output as previous version
of AS_BASENAME.

> GNU basename intentionally makes the empty string return the
> empty string, for the safety factor of catching empty input filenames.

Again, I think we should respect the native `basename'.
But I'm not sure what should be the default if that fails, let's wait
for opinion of other readers.

Attached please find the updated patch.  But let's hold this back after 2.60.

Have a nice fortnight,
        Stepan

Attachment: autoconf-20060401-as-basename2.patch
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]