[Top][All Lists]

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

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

From: n952162
Subject: Re: bug-bash Digest, Vol 218, Issue 19
Date: Wed, 13 Jan 2021 19:43:39 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.6.0

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.

reply via email to

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