bug-bash
[Top][All Lists]
Advanced

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

Re: Possible Bug in command and type posix compliance


From: Chet Ramey
Subject: Re: Possible Bug in command and type posix compliance
Date: Fri, 5 Apr 2019 11:00:03 -0400
User-agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.6.1

On 4/5/19 2:28 AM, Michael S wrote:
> Hello,
> 
> I believe I have found a bug when using the posix compliant bash. From this
> page point 53
> https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html it
> states that type and command should not return a binary that is non
> executable. For most cases this is currently true and the check when
> searching the patch ensures this in type.def. However in the case that the
> user has tried to execute the program and the command has been added to
> that hash table the check fails.

It's not clear that this is a POSIX conformance problem. Behavior varies.
Bash and ash-derived shells (dash/*BSD sh) behave as you observed, ksh-like
shells (ksh93, mksh) don't fall back to files without the excute bit set in
$PATH or put these `non-executables' into the hash table.

The issue is that POSIX makes it clear that the only way to determine
whether or not a file is an executable file is to try and execute it. By
the time that happens, you're running in a subshell and it's too late to
do anything about the parent's command hash table.

Maybe the best thing to do is not to insert a command from $PATH that
doesn't have the execute bit set into the hash table, but still return
it as the fallback possibility to attempt for execution.

Chet
-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, UTech, CWRU    chet@case.edu    http://tiswww.cwru.edu/~chet/



reply via email to

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