[Top][All Lists]

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

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

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

On 1/10/21 6:00 PM, bug-bash-request@gnu.org wrote:
Message: 3
Date: Sun, 10 Jan 2021 16:49:50 +0100
From: Ángel <angel@16bits.net>
To: bug-bash@gnu.org
Subject: Re: non-executable files in $PATH cause errors
Content-Type: text/plain; charset="ISO-8859-15"

On 2021-01-10 at 08:52 +0100, n952162 wrote:

I consider it a bug that bash (and its hash functionality) includes
non-executable files in its execution look-up and then (inevitably)
simply reports an error, because its such files aren't executable.

Perhaps it's there to support PATH look up for arguments to the bash
command. That would also be a bug. Why should it be okay to execute
non-executable script? 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.

I can't reproduce what you report.

$ mkdir foo bar
$ printf '#!/bin/sh\necho Program "$0"\n' > foo/program
$ printf '#!/bin/sh\necho Program "$0"\n' > bar/program
$ PATH="$PATH:$PWD/foo:$PWD/bar"
$ chmod +x bar/program
$ program

It is executing bar/program, not foo/program which is earlier in the
path, but not executable.

Maybe you just made the earlier program not executable, and the old
path is still being remembered? You should run hash -r after
making executable changes that will make an already-executed command
find a different program in the path (in the example above, making
foo/program executable, or removing again its +x bit).

Best regards

I unfortunately can't reproduce it, either, right now.  I can't remember
if I reconfigured something or was doing something special.  When I
encounter it again, I'll investigate it better.

But here's a bug for you, in readline:

- edit a line

- go to some character

- replace that character with another, using the "r" command.

- cruise further down the line to another character

- hit the "." repeat command

The replace operation will not be executed, but rather the "x" operation.

This has actually improved over the years.  A while back, repeating an
earlier operation like that would get characters tangled up. Now, it
seems at least to be deterministic.

reply via email to

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