On Nov 01 2021, Oğuz wrote:
> On Mon, Nov 1, 2021 at 1:33 PM Mike Jonkmans wrote:
>> Temporarily using a default value of PATH is akin to modifying it.
>
> But they are not the same thing, and you know this. The standard is
> neither on your side nor mine.
I think it can be considered a bug eith
On 11/1/21 11:26 AM, Chet Ramey wrote:
> On 10/31/21 12:06 PM, Roger Morris wrote:
>> Thanks for the reply. Though POSIX may allow this, still the last
>> line of the following example is rather unexpected behavior
>>
>> $
>> $ echo echo MY LOCAL tmp/date SCRIPT > tmp/date
>> $ chmod +x tmp/date
>
On 10/31/21 12:06 PM, Roger Morris wrote:
> Thanks for the reply. Though POSIX may allow this, still the last
> line of the following example is rather unexpected behavior
>
> $
> $ echo echo MY LOCAL tmp/date SCRIPT > tmp/date
> $ chmod +x tmp/date
> $
> $ PATH=.:/bin
> $ date
> Sun 31 Oct 2021
On Mon, Nov 01, 2021 at 03:42:11PM +0700, Robert Elz wrote:
> ...
> which is how it should be - the hash table is intended to speed PATH
> searches for commonly used commands, nothing should be found there
> which wouldn't be found from a PATH search - with the sole exception
> that the shell isn't
On 11/1/21 4:42 AM, Robert Elz wrote:
> I agree, this looks to be broken in bash - "command -p cmd" is (logically)
>
> oldpath=$PATH
> PATH=/standard:/system:/path
> cmd
> PATH=$oldpath
>
> and should act (as if) that way.
Clearly that's not the case. None of the side eff
On Mon, Nov 1, 2021 at 1:33 PM Mike Jonkmans wrote:
> Temporarily using a default value of PATH is akin to modifying it.
But they are not the same thing, and you know this. The standard is
neither on your side nor mine.
On Mon, Nov 01, 2021 at 12:21:41PM +0300, Oğuz wrote:
> On Mon, Nov 1, 2021 at 10:58 AM Mike Jonkmans wrote:
> > This wording does not cover it wholly, in my opinion.
> > Because when the utility's hashed path is not in $PATH,
> > then the utility should not have been searched for at all.
> > It s
On Mon, Nov 1, 2021 at 10:58 AM Mike Jonkmans wrote:
> This wording does not cover it wholly, in my opinion.
> Because when the utility's hashed path is not in $PATH,
> then the utility should not have been searched for at all.
> It should not be found, even if it is remembered.
Is the rest of th
I agree, this looks to be broken in bash - "command -p cmd" is (logically)
oldpath=$PATH
PATH=/standard:/system:/path
cmd
PATH=$oldpath
and should act (as if) that way.
What's more, from all the shells I have tested, bash is the only one
to behave like this, every
On Mon, Nov 01, 2021 at 09:09:19AM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 10:26 PM Mike Jonkmans wrote:
> > POSIX is also silent on this.
>
> I think ``Once a utility has been searched for and found [...], an
> implementation may remember its location and need not search for the
> utility a
On Sun, Oct 31, 2021 at 10:26 PM Mike Jonkmans wrote:
> POSIX is also silent on this.
I think ``Once a utility has been searched for and found [...], an
implementation may remember its location and need not search for the
utility again unless the PATH variable has been the subject of an
assignmen
On Sun, Oct 31, 2021 at 08:36:49PM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 7:07 PM Mike Jonkmans wrote:
> >
> > On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> > > 31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
> > > >
> > > > Using the hash as alias for commands, that are not in
On Sun, Oct 31, 2021 at 7:07 PM Mike Jonkmans wrote:
>
> On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> > 31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
> > >
> > > Using the hash as alias for commands, that are not in your PATH,
> > > seems risky though.
> >
> > Why? Risky how?
>
> R
On Sun, Oct 31, 2021 at 05:23:03PM +0200, Oğuz wrote:
> 31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
> >
> > Using the hash as alias for commands, that are not in your PATH,
> > seems risky though.
>
> Why? Risky how?
Risky, mostly on a cognitive level.
'command -p foo' doesn't look like i
Thanks for the reply. Though POSIX may allow this, still the last
line of the following example is rather unexpected behavior
$
$ echo echo MY LOCAL tmp/date SCRIPT > tmp/date
$ chmod +x tmp/date
$
$ PATH=.:/bin
$ date
Sun 31 Oct 2021 11:59:07 AM EDT
$ hash -l
builtin hash -p /bin/date date
$ cd
31 Ekim 2021 Pazar tarihinde Mike Jonkmans yazdı:
>
> Using the hash as alias for commands, that are not in your PATH,
> seems risky though.
Why? Risky how?
--
Oğuz
On Sun, Oct 31, 2021 at 03:33:07PM +0300, Oğuz wrote:
> On Sun, Oct 31, 2021 at 2:15 PM Mike Jonkmans wrote:
> > PATH=/dev/null
> > command -p hostname
> > hostname # executes /bin/hostname via the hash table
> >
> > I agree with OP that the behaviour is a bug, or at least
On Sun, Oct 31, 2021 at 2:15 PM Mike Jonkmans wrote:
> PATH=/dev/null
> command -p hostname
> hostname # executes /bin/hostname via the hash table
>
> I agree with OP that the behaviour is a bug, or at least unwanted behaviour.
I'd say it's a feature, and a good one too. N
On Sat, Oct 30, 2021 at 01:53:55PM -0400, Chet Ramey wrote:
> On 10/29/21 6:06 PM, Roger Morris wrote:
>
> > Bash Version: 5.0
> > Patch Level: 17
> > Release Status: release
> >
> > Description:
> > I believe there's a bug in bash 4.4 (and still in 5.1) that wasn't
> > there in 4.3.30
> >
> > W
On 10/29/21 6:06 PM, Roger Morris wrote:
Bash Version: 5.0
Patch Level: 17
Release Status: release
Description:
I believe there's a bug in bash 4.4 (and still in 5.1) that wasn't
there in 4.3.30
When 'command -p' runs, it no longer seems to restore the hash to its
previous value.
This came i
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2
-fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=.
-fstack-protector-strong -Wformat -Werror=format-security -Wall
-Wno-parentheses -Wno-format-security
uname out
21 matches
Mail list logo
