Date: Wed, 15 May 2024 09:19:06 -0400
From: Chet Ramey <chet.ra...@case.edu>
Message-ID: <86e381d8-dc83-4ef8-90e6-122468fa4...@case.edu>
| Why make it different from other PATH-like variables, where a null
| component is equivalent to "."?
Because having two ways to do the same thing is unnecessary, if "." is
meant, one can simply write "." - so having a null entry mean the same
thing adds no functionality, but means one needs to take more care when
composing PATH out of fragments, one cannot simply append ":newvalue"
to $PATH in case $PATH happened to be unset or empty.
But changing that wasn't what I actually suggested, as that would mean
either having two different PATH like scanning routines, or one which
would need to test an extra flag every time it found an empty entry (which
depending upon the implementation might alter the API). All I suggested
was having a BASH_SOURCE_PATH set to the empty string mean that no path
lookup should be done, and any attempt to use a relative path (and you
can exclude ./anything or ../anything from that if you prefer - ie:
exclude anything which would skip the PATH-like search anyway) would
simply fail (not just return itself and be attempted relative to ".")
That's a test that can be added to the code for the dot command, before
the PATH like search starts, and only in the case where BASH_SOURCE_PATH
is set, and would be used.
| So let's move the state of the art forward.
That isn't going to happen if you make the path searched have a BASH_*
variable name.
If you meant for PATH searches in general, that would be wildly breaking
backward compat, and I doubt you'd attempt to justify that, and nor would
I, regardless of it being an obvious improvement.
kre
