Re: bash 4.4-rc1 EXECIGNORE not fully working?

[Eric Blake]

On 03/18/2016 10:35 AM, Greg Wooledge wrote:
> On Fri, Mar 18, 2016 at 10:27:54AM -0600, Eric Blake wrote:
>> What were you expecting to have happen?  EXECIGNORE only controls
>> whether a file matching the glob is excluded from tab completions (which
>> it sounds like it did), not whether bash will avoid executing it (and
>> you proved that it is still executable).
> 
> The man page says,
> 
>        EXECIGNORE
>               A colon-separated list of shell patterns (see Pattern  Matching)
>               defining  the list of filenames to be ignored by command search.
>               Files whose full pathnames match one of these patterns  are  not
>               considered  executable  files for the purposes of completion and
>               command execution.
> 
> I believe this agrees more with Dennis's interpretation.

Then we have a documentation bug in my feature submission; Chet changed
the wording I proposed, which was:

https://lists.gnu.org/archive/html/bug-bash/2015-04/msg00130.html

address@hidden EXECIGNORE
+A colon-separated list of extended glob patterns (@pxref{Pattern
+Matching}). Files with full paths matching one of these patterns are
+not considered executable for the purposes of completion and PATH
+searching, but the @code{[}, @code{[[}, and @code{test} builtins are
+not affected. Use this variable to ignore shared library files that
+must have the executable bit set, but which are not actually
+executable.

We've demonstrated that it affects PATH searching insofar that 'type -a'
no longer lists the program, but it does NOT change any exec[lv]p() PATH
searching (if the kernel searches for 'ls', it will find it no matter
what bash has in EXECIGNORE).  But I don't know whether bash is calling
exec[lv] with a canonicalized name instead of exec[lv]p() with the
kernel doing the lookup; nor do I have any strong opinions about whether
EXECIGNORE should be able to completely blacklist the execution of a
particular program, so much as only hiding it from tab-completion.

Maybe the compromise is calling this report a doc bug, and changing
Chet's wording to nuke the trailing "and command execution", so that it
remains as documented mention that it affects ONLY completion (since
'type -a' is similar to completion in nature).

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature