Re: bug-bash Digest, Vol 218, Issue 19

[n952162]

On 1/13/21 6:00 PM, bug-bash-request@gnu.org wrote:
> and then (inevitably)
> > simply reports an error, because its such files aren't  executable.
> But it is not inevitable. Using 'cp' as an example.  Assuming
> you have /usr/bin in your PATH, but ~/bin is in your PATH before
> /usr/bin, then try:
> "touch ~/bin/cp", then
> "hash -u" (to clear the hash lookup), then type
> "cp"<RETURN>, you will find that it returns the
> value in /usr/bin, ignoring the non-executable file that was
> first in your PATH.  So if an executable is in your PATH, it will
> return that in preference to a non-executable.  Only when it can't
> find an executable does it return the non-executable.


Okay, that's probably the situation I was in ... I have a cover script
for ftp, that I'd disabled.  I discovered that I had to install ftp -
once I'd done that, the problem wasn't reproducible.


> As for why this is useful?  Perhaps someone just created a
> script script 'foo' in "~/bin", but forgot to toggle
> the execution bit. Then they know that they forgot to
> toggle the execution bit.
>
> So it only reports the non-executable when there is no other
> option -- not 'inevitably', which is useful because it reminds
> people they need to toggle the 'x' bit.
>
> Make sense?

Maybe.  But I think the original comment is relevant here:

"Supporting users who are too lazy to chmod a
file ought to be less important than supporting users who want
fine-grain control over what's executable and what's not."

But I concede that the method implemented is probably an acceptable compromise.