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

[Eric Blake]

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   eblake@redhat.com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature