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 ebl...@redhat.com +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
