bug-bash
[Top][All Lists]
Advanced

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

Re: bash 4.2 breaks source finding libs in lib/filename...


From: Eric Blake
Subject: Re: bash 4.2 breaks source finding libs in lib/filename...
Date: Wed, 29 Feb 2012 12:42:34 -0700
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.1) Gecko/20120216 Thunderbird/10.0.1

On 02/29/2012 12:26 PM, Linda Walsh wrote:

>> Any pathname that contains a / should not be subject to PATH searching.

Agreed - as this behavior is _mandated_ by POSIX, for both sh(1) and for
execlp(2) and friends.

> Pathnames that *start* with '/' are called an "absolute" pathnames,
> 
> while paths not starting with '/' are relative.

And among the set of relative pathnames, there are two further
divisions: anchored (contains at least one '/') and unanchored (no '/').
 PATH lookup is defined as happening _only_ for unanchored names.

> Try 'C', if you include a include file with "/", it scans for it in each
> .h root.

The C compiler _isn't_ doing a PATH search, so it follows different rules.

> Almost all normal utils take their 'paths to be the 'roots' of
> trees that contain files.  Why should bash be different?

Because that's what POSIX says.

> 
> It goes against 'common sense' and least surprise -- given it's the
> norm in so many other applications.

About the best we can do is accept a patch (are you willing to write it?
if not, quit complaining) that would add a new shopt, off by default, to
allow your desired alternate behavior.  But I won't write such a patch,
and if such a patch is written, I won't use it, because I'm already used
to the POSIX behavior.

-- 
Eric Blake   address@hidden    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

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