Re: [PATCH v2 5/8] builtins/source: parse the -i option

[Robert Elz]

    Date:        Thu, 16 May 2024 11:36:50 -0400
    From:        Chet Ramey <chet.ramey@case.edu>
    Message-ID:  <613852f3-c9ef-43d8-821b-37be3d9e941b@case.edu>

  | You can already do this; there's no reason to add these semantics to a
  | variable setting.

How?   What I'm looking for is a way to catch accidental ". foo" type
things (by causing them to fail, regardless of whether "./foo" (or some
other random "foo") exists and contains valid sh code).

  | > can exclude ./anything or ../anything from that if you prefer - ie:
  | Those are not relative paths.

Of course they are, that "." (or "..") is relative to something, it
isn't referring to a fixed location in the file system tree (like "/foo"
would be).

You might choose to categorise them differently, that's fine, but
there's no semantic difference between "./foo" and "dir/foo" - both
look for some directory ("." or "dir") within some other directory,
which usually depends upon other factors (such as the current PWD).

  | > exclude anything which would skip the PATH-like search anyway) would
  | > simply fail (not just return itself and be attempted relative to ".")
  |
  | Is this really valuable?

I think so, and given that any other reasonable interpretation I can
think of has alternative (just as simple) mechanisms to accomplish,
it seems to me like it would be reasonable.   If you want BASH_SOURCE_PATH=.
then that's exactly that easy to accomplish.   You can make the default
when BASH_SOURCE_PATH is unset be whatever you like (like using PATH,
or doing something entirely different), but having it set to "" seems
like it ought mean "no path search".

  | Maybe. We'll have to see. People will object no matter what the name is.

It isn't a matter of objecting, I have no objection to BASH_SEARCH_PATH,
but I'm never going to implement that var (just as I wouldn't implement
BASH_VERSION or any of the other BASH_XXX vars that exist).  If some
script wants to set BASH_xxx for any random xxx, that's fine, but it
will never be anything but be a variable (and because of the possibility
that the var picked might one day conflict with one you add, I'd suggest
that people not generally do that, and other shells than bash, never).

It's hard to get consensus on something when it isn't possible to even
agree on a name all can use - if I'm using a different name for a similar
function, I have no reason to implement the same sematic as you do, and
all we end up with is yet another divergent system, which would be where
the posix people come along and invent POSIX_SOURCE_PATH (which no-one
implements) with some random sub/super-set of the way the various
implementations work.   That's not something to work towards, IMO.

  | I have high hopes for `GLOBSORT', though.

That is at least a plausible name - never heard of it, and my bash man
page (still at 5.2, I have a 5.3-a1 binary, but haven't installed its
man page anywhere) doesn't mention it.   What does it do?

kre