Date: Thu, 09 Mar 2023 09:26:18 +0100 From: Andreas Schwab <sch...@suse.de> Message-ID: <mvm5ybagwk5....@suse.de>
| 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 <percent-sign> character ('%'), the path search is implementation-defined. Ignore the "or if" part, but what the rest of that says is that bash (or any other shell) gets to define where to search (which could be nowhere, or '.', or some standard path setup) when PATH is unset, or (as in the case from the OP) when PATH='' So, if bash wants to define PATH= as being the same as PATH=. that's just fine - and more than that, is probably the right thing to do as PATH=:/bin is the same as PATH=.:/bin and PATH=/bin: is the same as PATH=/bin:. and PATH=/bin::/usr/bin is ... - an empty component of PATH is treated as '.' (always has been in all Bourne shells), PATH= is really just a path with only one component, which is empty. The case for an unset PATH is not so clear, and either doing no search at all, or searching a system defined standard command path, is probably a better choice in those cases, rather than treating it as '.' (two ways to say '.' is arguably overkill already, three is too much). But that case isn't the OP's case, so is irrelevant in the current discussion. kre ps: whatever bash decides to do, it should be consistent for all uses of PATH of course, not different for searching then for completion, or for "not found" handlers.