Discussion:
OT: Extension to PATH environment variable's "API"
(too old to reply)
Christof Warlich
2018-10-28 11:13:04 UTC
Permalink
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 briefly discuss here.

Currently, there are two options when installing new binaries that
should "just be found" through the PATH environment variable:

1) Adding the binaries to a directory that typically is already part of
the PATH environment variable.
2) Putting the binaries into a new, dedicated directory and adding that
directory to the PATH environment variable.

Both approaches have considerable disadvantages: The first one leads to
cluttered directories (consider /user/bin on typical Linux
distributions), e.g. missing the capability to group the binaries into
the packages they belong, while the second causes a long and cluttered
PATH. And both approaches more or less fail for binaries with
conflicting (i.e. same) names.
Christof Warlich
2018-10-28 11:15:48 UTC
Permalink
Sorry, please disregard this post, I just sent it accidently, so it is
just not finished.
Post by Christof Warlich
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 briefly discuss here.
Currently, there are two options when installing new binaries that
1) Adding the binaries to a directory that typically is already part
of the PATH environment variable.
2) Putting the binaries into a new, dedicated directory and adding
that directory to the PATH environment variable.
Both approaches have considerable disadvantages: The first one leads
to cluttered directories (consider /user/bin on typical Linux
distributions), e.g. missing the capability to group the binaries into
the packages they belong, while the second causes a long and cluttered
PATH. And both approaches more or less fail for binaries with
conflicting (i.e. same) names.
Christof Warlich
2018-10-28 13:31:34 UTC
Permalink
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
Dennis Williamson
2018-10-28 15:31:40 UTC
Permalink
Post by Christof Warlich
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
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
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.
Christof Warlich
2018-10-29 09:52:22 UTC
Permalink
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.

Agreed, but this is why I suggested that such a feature could be
enabled through a switch, similar to e.g. -o pipefail. In this case,
backward incompatibitities would not matter.

Further note the inconsistency of the current behavior: If the current
working directory is not listed in PATH,

$ ./executable_in_working_dir

would find and execute executable_in_working_dir, whereas

$ executable_in_working_dir

would not be found.

On the other hand, both

$subdir/executable_in_subdir_of_working_dir

and

$./subdir/executable_in_subdir_of_working_dir

are found and executed.

But anyhow, if bash's policy in general is that no new feature
(improvements) are desired, I'm totaly fine: You guys may have your
(good) reasons.

Loading...