On 3/9/23 5:42 PM, Moshe Looks wrote:
Thank you this is very illuminating and makes it clear that my naive
one-line fix would be inappropriate. Given the current state of
affairs there is really no good reason for PATH to ever be unset or
set to empty vs. explicitly set to '.', right? So might be
On 3/8/23 1:33 PM, Moshe Looks wrote:
Bash Version: 5.1
Patch Level: 16
Release Status: release
Description:
When PATH is empty, the command_not_found_handle function is not
called when a command is not found.
I agree that bash should do a path search in the current directory when
PATH is the
Thank you this is very illuminating and makes it clear that my naive
one-line fix would be inappropriate. Given the current state of
affairs there is really no good reason for PATH to ever be unset or
set to empty vs. explicitly set to '.', right? So might be worth
spelling out in the docs that thi
Date:Thu, 09 Mar 2023 09:26:18 +0100
From:Andreas Schwab
Message-ID:
| But an unset PATH is *not* the same as PATH=.
That might be true, but POSIX says:
If PATH is unset or is set to null, or if a path prefix in PATH
contains a character ('%'), t
On Mär 08 2023, Grisha Levit wrote:
> I think it might make sense to change code that looks at the value of
> PATH to explicitly treat an empty value as `.' so that all such
> behavior is consistent.
But an unset PATH is *not* the same as PATH=.
--
Andreas Schwab, SUSE Labs, sch...@suse.de
GPG
On Wed, Mar 8, 2023 at 4:28 PM Moshe Looks wrote:
> This is very old code and I have no idea what the original intention
> was in returning 'name' here or if doing so is still performing useful
> work, but the tests pass at least.
A null $PATH component is treated as the current directory, and ba
Configuration Information [Automatically generated, do not change]:
Machine: x86_64
OS: linux-gnu
Compiler: gcc
Compilation CFLAGS: -g -O2 -flto=auto -ffat-lto-objects -flto=auto
-ffat-lto-objects -fstack-protector-strong -Wformat
-Werror=format-security -Wall
uname output: Linux xi 5.15.0-67-gener
