Re: [Help-bash] OT: Extension to PATH environment variable's "API"

[Dennis Williamson]

On Sun, Oct 28, 2018, 8:32 AM Christof Warlich <address@hidden wrote:

> Hi,
>
> I marked this as off-topic as this is not a request for help, but the
> suggestion of an idea to slightly extend the utility of the "PATH"
> environment variable that I'd like to discuss.
>
> Currently, there are two options when installing new executables that
> should "just be found" through the "PATH" environment variable:
>
> 1) Adding the executables to a directory that typically is already part
> of the "PATH", e.g. "/usr/bin".
> 2) Putting the executables into a new, dedicated directory and adding
> that directory to the "PATH".
>
> Both approaches have considerable disadvantages: The first one leads to
> cluttered directories (consider "/user/bin" on typical Linux
> distributions), missing the capability to group the binaries into the
> packages they belong to, while the second approach ultimately causes a
> long and cluttered "PATH". And both approaches more or less fail for
> executables with conflicting (i.e. same) names.
>
> Instead, my idea would suggest to allow _subdirectories_ relative to the
> entries of the "PATH" when calling executables. An example may help to
> illustrate what I mean:
>
> Consider the "/usr/bin" directory. Instead of putting all excutables
> there, "/usr/bin" would contain package subdirectories, each containing
> its related executables, e.g. "/usr/bin/arm/gcc", "/usr/bin/arm/g++",
> .... for an ARM toolchain. The "PATH" would still just only include
> "/usr/bin", but when calling e.g. "arm/gcc", Bash would find and execute
> "/usr/bin/arm/gcc".
>
> Note that this would still allow users to call executables relative to
> the current working directory by prepending them with "./", i.e.
> "./arm/gcc", which is very similar to the current behavior considering
> that e.g. "./ls" would require an executable to be in the current
> working directory, whereas "ls" would be searched for by consulting "PATH".
>
> Further note that this would only be a rather unlikely break w.r.t.
> backward compatibility, because currently, subdirectories of directories
> listed in the "PATH" hardly exist in the wild. And even in case of
> remaining compatibility concerns, this feature could be enabled by an
> option passed to bash, e.g. "-o subdirs".
>
> What do you guys think: Does that make sense in a context of bash being
> a (much better) Bourne Shell? And is anyone aware of another shell that
> already has (an option to enable) this behavior?
>
> Cheers,
>
> Chris
>
>


Here's the first problem with that. Currently

./arm/gcc

means the same thing as

arm/gcc

and that's an expected and long established behavior. Your proposal would
break that or conflict with it.