Default PATH setting - reduce to something more sensible?

[Janis Papanagnou]

When I recently inspected an 'strace' log and saw the huge amount
of system-calls done for a simple standard command (like 'rm') -
it's more than a dozen! and most lead just to ENOENT - I wondered
about the default PATH definition which is for my system
/usr/lib/lightdm/lightdm
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
(here I'm omitting my own additions, '~/bin' and '.', and I separated
them, one on each line for a better visualization of the "problem" or,
maybe better, for the "questions".)

The above PATH components are for a terminal running under some
window manager, a plain console window will not show the 'lightdm'
entry (but I rarely work on plain consoles).

This raises a few questions, and someone may shed some light on the
rationale for above default settings... (and how to "fix" it best)

Why do I need 'lightdm/lightdm' in the user's PATH variable defined?
(That directory contains just one special script and one executable.)
This entry is what annoys me most; it also reminds me of systems that
have every program vendor add an own PATH entry for their products.
Would it be safe to just remove that (in my '~/.profile') from PATH?
Or can I make it vanish by some other change, to not appear in the
in the PATH first place? (Of course without destabilizing the system
by that.)

There's no files in '/usr/local/sbin' (on my system); no admins with
special tools desires.

I don't seem to use executables from all the 'sbin' directories; I'm
positive I need /usr/bin, /bin, and I've also installed some things
in /usr/local/bin. It seems to me that, as a normal user, the PATH
(and with it the path-search) could be drastically reduced. Is there
a method to only have them in the PATH when 'sudo'ing any programs
that require root privileges and the privileged programs in 'sbin'?

I mean, if I 'sodo' a shell I get - and I think this is sensible! -
only /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
(no 'lightdm', no 'games', and no personal settings) anyway, and I
seem to have those entries available independent of any parent
process's setting; PATH=/usr/bin sudo ksh will still provide all
the 'sbin' directories in the privileged shell's own PATH setting.

So my thought is, for the moment as a workaround, to edit the PATH
in the .profile, and _remove_ all 'sbin' and the 'lightdm' entries,
or just explicitly _define_ PATH without the spurious parts). (Or
would it be advisable to do that change in all the shells' .rc
files?) Or is there yet a better place to "fix" things system-wide?

(Or better not touch a running system? - but it looks so messy!)

Janis

[Dan Cross]

[Meta note: This is more of a comp.unix.shell sort of post; not
so much comp.unix.programmer. Followup-To: set accordingly.]

Post by Janis Papanagnou
When I recently inspected an 'strace' log and saw the huge amount
of system-calls done for a simple standard command (like 'rm') -
it's more than a dozen! and most lead just to ENOENT - I wondered
about the default PATH definition which is for my system
/usr/lib/lightdm/lightdm
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
(here I'm omitting my own additions, '~/bin' and '.', and I separated
them, one on each line for a better visualization of the "problem" or,
maybe better, for the "questions".)

On a single-user system, it's not a huge deal, but on a
multiuser system where you may `cd` into a directory writable by
anyone (such as /tmp), `.` in $PATH is a known security problem.
YMMV, but caveat emptor.

Post by Janis Papanagnou
The above PATH components are for a terminal running under some
window manager, a plain console window will not show the 'lightdm'
entry (but I rarely work on plain consoles).
This raises a few questions, and someone may shed some light on the
rationale for above default settings... (and how to "fix" it best)
Why do I need 'lightdm/lightdm' in the user's PATH variable defined?
(That directory contains just one special script and one executable.)
This entry is what annoys me most; it also reminds me of systems that
have every program vendor add an own PATH entry for their products.
Would it be safe to just remove that (in my '~/.profile') from PATH?
Or can I make it vanish by some other change, to not appear in the
in the PATH first place? (Of course without destabilizing the system
by that.)

If you don't feel like you need to run that executable, and the
window manager works ok without it, I don't see why it would be
a problem to remove it from $PATH.

Post by Janis Papanagnou
There's no files in '/usr/local/sbin' (on my system); no admins with
special tools desires.
I don't seem to use executables from all the 'sbin' directories; I'm
positive I need /usr/bin, /bin, and I've also installed some things
in /usr/local/bin. It seems to me that, as a normal user, the PATH
(and with it the path-search) could be drastically reduced. Is there
a method to only have them in the PATH when 'sudo'ing any programs
that require root privileges and the privileged programs in 'sbin'?

Yes, `sudo` can be configured to set $PATH for the programs that
it invokes; see sudoers(5) and look for `secure_path`. If you
don't invoke those from your normal shell, I don't see a problem
removing them from the default.

Post by Janis Papanagnou
I mean, if I 'sodo' a shell I get - and I think this is sensible! -
only /usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin
(no 'lightdm', no 'games', and no personal settings) anyway, and I
seem to have those entries available independent of any parent
process's setting; PATH=/usr/bin sudo ksh will still provide all
the 'sbin' directories in the privileged shell's own PATH setting.
So my thought is, for the moment as a workaround, to edit the PATH
in the .profile, and _remove_ all 'sbin' and the 'lightdm' entries,
or just explicitly _define_ PATH without the spurious parts). (Or
would it be advisable to do that change in all the shells' .rc
files?) Or is there yet a better place to "fix" things system-wide?
(Or better not touch a running system? - but it looks so messy!)

Personally, I'd let well enough alone, but I suppose this
alludes to a larger question: does having those entries in $PATH
affect the operation of the system in any materially negative
way? Is this just a preference for tidiness kind of thing?

There's no harm in cleaning up, but I suspect any marginal
resource savings has already been offset by thinking about it
at all. :-)

What is the desired end-state here?

- Dan C.

[Rainer Weikusat]

Post by Janis Papanagnou
When I recently inspected an 'strace' log and saw the huge amount
of system-calls done for a simple standard command (like 'rm') -
it's more than a dozen! and most lead just to ENOENT - I wondered
about the default PATH definition which is for my system
/usr/lib/lightdm/lightdm
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
(here I'm omitting my own additions, '~/bin' and '.', and I separated
them, one on each line for a better visualization of the "problem" or,
maybe better, for the "questions".)
The above PATH components are for a terminal running under some
window manager, a plain console window will not show the 'lightdm'
entry (but I rarely work on plain consoles).
This raises a few questions, and someone may shed some light on the
rationale for above default settings... (and how to "fix" it best)

Why do you want to change that? At worst, this will make seven execve to
execute binary. Usually, it will rather be 4. That's not going to take a
noticeable amount of time.

As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

[Scott Lurndal]

Post by Rainer Weikusat

Post by Janis Papanagnou
When I recently inspected an 'strace' log and saw the huge amount
of system-calls done for a simple standard command (like 'rm') -
it's more than a dozen! and most lead just to ENOENT - I wondered
about the default PATH definition which is for my system
/usr/lib/lightdm/lightdm
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
(here I'm omitting my own additions, '~/bin' and '.', and I separated
them, one on each line for a better visualization of the "problem" or,
maybe better, for the "questions".)
The above PATH components are for a terminal running under some
window manager, a plain console window will not show the 'lightdm'
entry (but I rarely work on plain consoles).
This raises a few questions, and someone may shed some light on the
rationale for above default settings... (and how to "fix" it best)

Why do you want to change that? At worst, this will make seven execve to
execute binary. Usually, it will rather be 4. That's not going to take a
noticeable amount of time.
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

[Kaz Kylheku]

Post by Scott Lurndal

Post by Rainer Weikusat
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

If it doesn't hurt, that "hash -r" stuff in Bash and probably other
shells has to be just developer gold plating. :)

I suspect that machines becoming faster *and* process creation becoming
more complex and heavier (e.g. attaching multiple shared libraries and
resolving symbols) has allowed us to get away with longer PATHs without
noticing.

[Rainer Weikusat]

Post by Scott Lurndal

Post by Rainer Weikusat

Post by Janis Papanagnou
When I recently inspected an 'strace' log and saw the huge amount
of system-calls done for a simple standard command (like 'rm') -
it's more than a dozen! and most lead just to ENOENT - I wondered
about the default PATH definition which is for my system
/usr/lib/lightdm/lightdm
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
(here I'm omitting my own additions, '~/bin' and '.', and I separated
them, one on each line for a better visualization of the "problem" or,
maybe better, for the "questions".)
The above PATH components are for a terminal running under some
window manager, a plain console window will not show the 'lightdm'
entry (but I rarely work on plain consoles).
This raises a few questions, and someone may shed some light on the
rationale for above default settings... (and how to "fix" it best)

Why do you want to change that? At worst, this will make seven execve to
execute binary. Usually, it will rather be 4. That's not going to take a
noticeable amount of time.
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span ⅕ of the planet and hence, the latencies certainly
ought to be a lot lower.

I'm growing a bit allergic to NFS as universal example of deviant
behaviour --- that's a problem of NFS and not of code innocently and
unknowingly making use of it.

[Scott Lurndal]

Post by Rainer Weikusat

Post by Scott Lurndal

Post by Rainer Weikusat

Post by Janis Papanagnou
When I recently inspected an 'strace' log and saw the huge amount
of system-calls done for a simple standard command (like 'rm') -
it's more than a dozen! and most lead just to ENOENT - I wondered
about the default PATH definition which is for my system
/usr/lib/lightdm/lightdm
/usr/local/sbin
/usr/local/bin
/usr/sbin
/usr/bin
/sbin
/bin
/usr/games
(here I'm omitting my own additions, '~/bin' and '.', and I separated
them, one on each line for a better visualization of the "problem" or,
maybe better, for the "questions".)
The above PATH components are for a terminal running under some
window manager, a plain console window will not show the 'lightdm'
entry (but I rarely work on plain consoles).
This raises a few questions, and someone may shed some light on the
rationale for above default settings... (and how to "fix" it best)

Why do you want to change that? At worst, this will make seven execve to
execute binary. Usually, it will rather be 4. That's not going to take a
noticeable amount of time.
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span ⅕ of the planet and hence, the latencies certainly
ought to be a lot lower.

You seem to have have forgotten that the NFS server needs to
do a directory lookup on the file server, which adds to the R/T
latency, sometimes significantly on a busy filesystem. Add
two or three NFS-based directories in the PATH variable and it
starts to become noticable. Even on a 100Gb/sec ethernet
LAN.

Post by Rainer Weikusat
I'm growing a bit allergic to NFS as universal example of deviant
behaviour --- that's a problem of NFS and not of code innocently and
unknowingly making use of it.

It is something that people run into every day in the real world.

[Dan Cross]

[Followup-To: comp.unix.shell]

Post by Scott Lurndal

Post by Rainer Weikusat

[snip]
There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span ⅕ of the planet and hence, the latencies certainly
ought to be a lot lower.

You seem to have have forgotten that the NFS server needs to
do a directory lookup on the file server, which adds to the R/T
latency, sometimes significantly on a busy filesystem. Add
two or three NFS-based directories in the PATH variable and it
starts to become noticable. Even on a 100Gb/sec ethernet
LAN.

Post by Rainer Weikusat
I'm growing a bit allergic to NFS as universal example of deviant
behaviour --- that's a problem of NFS and not of code innocently and
unknowingly making use of it.

It is something that people run into every day in the real world.

Remember wuarchive? They used to used to provide access to the
collection via (read-only) NFS. When I was young, someone at
our site had added that to the automounter maps.

There was a local sysadmin who was, er, not exactly highly
regarded. At one point another sysadmin logged into a machine
and saw that the load was really, really high; this would have
been a Sun 4/380 class computer and load was like 3 or 4, all
uninterruptable kernel reads. Anyway, it turns out the first
guy had added some directory in the automounted wuarchive tree
to his $PATH. And that's the sort of thing one does to become
"poorly regarded by colleagues."

- Dan C.

[Rainer Weikusat]

[...]

Post by Scott Lurndal

Post by Rainer Weikusat

Post by Scott Lurndal

Post by Rainer Weikusat
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span â…• of the planet and hence, the latencies certainly
ought to be a lot lower.

You seem to have have forgotten that the NFS server needs to
do a directory lookup on the file server, which adds to the R/T
latency, sometimes significantly on a busy filesystem.

Well, then, which is it? Local file system operations or network
latencies? Local file system operations on a NFS server are no different
from local file system operations on some other multi-user machine, eg,
the abovementioned PDP-11.

[...]

Post by Scott Lurndal

Post by Rainer Weikusat
I'm growing a bit allergic to NFS as universal example of deviant
behaviour --- that's a problem of NFS and not of code innocently and
unknowingly making use of it.

It is something that people run into every day in the real world.

Maybe they do. But certainly not on Linux installations using only local
file systems. I'm also (barely) old enough to remember DCE clusters
based on DEC servers using AFS/ NFS to provide "home directories" and
"software" to diskless workstations and to know how real-world PATHs of
traditional UNIX installation used to look like, basically, every
software package installed into its own hierarchy and all glued together
with PATH into a seamless whole. These PATHs used to have a lot more
than just seven elements. I don't remember latencies being a particular
problem in this enivronment¹.

¹ A whose class B in a single, happy, broadcast domain and using
shared-medium yellowcable and even older technologies in the more
outlying areas

[Scott Lurndal]

Post by Rainer Weikusat
[...]

Post by Scott Lurndal

Post by Rainer Weikusat

Post by Scott Lurndal

Post by Rainer Weikusat
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span â • of the planet and hence, the latencies certainly
ought to be a lot lower.

You seem to have have forgotten that the NFS server needs to
do a directory lookup on the file server, which adds to the R/T
latency, sometimes significantly on a busy filesystem.

Well, then, which is it? Local file system operations or network
latencies?

Clearly both factor into latency.

Post by Rainer Weikusat
Local file system operations on a NFS server are no different
from local file system operations on some other multi-user machine, eg,
the abovementioned PDP-11.

Clearly the PDP-11 cannot be rationally compared with a modern
lab with thousands of pooled servers sharing storage over NFS.

Post by Rainer Weikusat
[...]

Post by Scott Lurndal

Post by Rainer Weikusat
I'm growing a bit allergic to NFS as universal example of deviant
behaviour --- that's a problem of NFS and not of code innocently and
unknowingly making use of it.

It is something that people run into every day in the real world.

Maybe they do. But certainly not on Linux installations using only local
file systems.

Our production grid has several _thousand_ linux boxes sharing
storage using a dozen NFS servers. The load in the NFS servers
can be considerable, even with a 100Gb backbone network.

[Rainer Weikusat]

Post by Scott Lurndal

Post by Rainer Weikusat
[...]

Post by Scott Lurndal

Post by Rainer Weikusat

Post by Scott Lurndal

Post by Rainer Weikusat
As far as I could determine, some sort of path searching has existed
since the 6th edition of UNIX (., /bin and /usr/bin hardcoded in the
shell) and in its present form, it has existed since the 7th edition of
UNIX. Which means PATH searching was used on PDP-11 16-bit minicomputers
in the 1970s. It didn't cause performance problems back
then and will thus certainly don't cause any today.

There are cases where it _does_ cause performance degradation, if one or
more of the PATH elements refer to NFS filesystems, for example.

The internet RTT from Reading/ UK to Dallas/ Texas is about
0.12s. That's fast enough that there's no noticeable latency in
interactive shell sessions. I doubt that many real-world NFS
installations span â…• of the planet and hence, the latencies certainly
ought to be a lot lower.

You seem to have have forgotten that the NFS server needs to
do a directory lookup on the file server, which adds to the R/T
latency, sometimes significantly on a busy filesystem.

Well, then, which is it? Local file system operations or network
latencies?

Clearly both factor into latency.

Trivially, they do. But NFS means Network Filesystem and hence, bringing
it up suggests that that's about ... well ... network operations and not
local filesystem operations.

Post by Scott Lurndal

Post by Rainer Weikusat
Local file system operations on a NFS server are no different
from local file system operations on some other multi-user machine, eg,
the abovementioned PDP-11.

Clearly the PDP-11 cannot be rationally compared with a modern
lab with thousands of pooled servers sharing storage over NFS.

The PDP-11 can be rationally compared with the situation of the OP,
namely, doing local filesystem operations on a single
computer. PATH-searching was supported on PDP-11s serving multiple
users. Hence, it's very unlikely that that's going to be a real
performance problem on a single-user Linux installation on current PC
hardware, especiall if the path has only seven elements.

[Janis Papanagnou]

[...]

Post by Rainer Weikusat
The PDP-11 can be rationally compared with the situation of the OP,
namely, doing local filesystem operations on a single computer. [...]

Since you're referring to me, the OP, please note that most arguments
here have quickly made a relation to a straw man (a performance theme)
or made other deviations from the basic question(s) that concerned me.

Essentially there were two questions I had that I can reformulate in a
more compact form as

"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

But we've seen mostly only statements maneuvering around the questions.

Please don't take that hint as offense, I just think it may be time to
put it on track again. - Thanks.

Janis

[Scott Lurndal]

Post by Janis Papanagnou
[...]

Post by Rainer Weikusat
The PDP-11 can be rationally compared with the situation of the OP,
namely, doing local filesystem operations on a single computer. [...]

Since you're referring to me, the OP, please note that most arguments
here have quickly made a relation to a straw man (a performance theme)
or made other deviations from the basic question(s) that concerned me.
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

Fundamentally, it's an implementation choice. For example,
the Fedora root user will have

/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin

as the PATH variable.

Novice users likely never change from the default path,
and one hopes (absent duplicate command names) that the
PATH variable places the most likely elements towards
the front of the list.

For korn shell, it will remember the element on a hit
and subsequent invocations of the command will get
a hit in the shell cache and will not search PATH.

If one has a custom command that clashes with one in the
distribution, one can simply include that directory in the
path before the rest (e.g. /usr/local/sbin above), but I
wouldn't expect to find that most general linux users
ever touch PATH.

In a multi-user environment (grid or multiuser machine),
it is not uncommon to place executables on an NFS exported
filesystem (e.g. for CAD tools), and include the NFS
directory in the default PATH for the CAD users in
e.g. /profile, or in an evironment initailization
script.

Post by Janis Papanagnou
"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

Iteratively remove elements. If things don't work, put them back.

[Janis Papanagnou]

Post by Scott Lurndal

Post by Janis Papanagnou
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

Fundamentally, it's an implementation choice. For example,
the Fedora root user will have
/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin
as the PATH variable.

Yes, when sudo'ing commands these will also have a restricted
PATH (almost like that) in my Xubuntu environment. That's IMO
a good thing. (And I wished it were similar in the "ordinary
user"'s PATH.)

Post by Scott Lurndal
Novice users likely never change from the default path,
and one hopes (absent duplicate command names) that the
PATH variable places the most likely elements towards
the front of the list.
For korn shell, it will remember the element on a hit
and subsequent invocations of the command will get
a hit in the shell cache and will not search PATH.
If one has a custom command that clashes with one in the
distribution, one can simply include that directory in the
path before the rest (e.g. /usr/local/sbin above), but I
wouldn't expect to find that most general linux users
ever touch PATH.

In the 1990's we used to explicitly specify a well-defined short
PATH at the beginning of shell scripts - primarily for safety
considerations - but, frankly, I got sloppy over the decades in
my personal Unix environments.

Post by Scott Lurndal
[ NFS snipped ]

Post by Janis Papanagnou
"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

Iteratively remove elements. If things don't work, put them back.

The shell configuration components don't seem to be responsible for
PATH entries like '/usr/lib/lightdm/lightdm', at least I haven't
found them in any global (less so in local) shell settings.

I should probably just ignore any default path setting and add my
own settings in my shell profiles and/or in my shell scripts.

Janis

[Dan Cross]

[snip]
Since you're referring to me, the OP, please note that most arguments
here have quickly made a relation to a straw man (a performance theme)
or made other deviations from the basic question(s) that concerned me.
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

Not particularly.

The system has, probably for no really principled reason,
evolved over time such that that's simply the set of things that
are in $PATH by default on that particular machine. Another
machine might be different.

If I had to hazard a guess, I imagine some of it comes from the
folks who put together the distribution, some upgrades, and the
choices of e.g. the window manager you're using (recalling that
at least one $PATH component appeared to come from that).

"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

There are many ways you could do this. Probably the easiest is
just to explicitly set $PATH in your shell's startup files to
those directories you care about; that's what I usually do. If
you make a mistake with it, you won't affect the rest of the
system.

If you want to set it globally for all users, there's likely
some file in /etc or similar that sets the defaults; on my Linux
machine I see a number of things in /etc/profile and
/etc/profile.d/* that seem relevant and there's /etc/login.defs;
PAM has its own way to set up $PATH. I'm not sure I'd bother,
though, if setting it up for your own account is sufficient.

- Dan C.

[Rainer Weikusat]

Post by Janis Papanagnou
[...]

Post by Rainer Weikusat
The PDP-11 can be rationally compared with the situation of the OP,
namely, doing local filesystem operations on a single computer. [...]

Since you're referring to me, the OP, please note that most arguments
here have quickly made a relation to a straw man (a performance theme)
or made other deviations from the basic question(s) that concerned me.
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

Because someone thinks that all these locations should be searched for
commands in the order specified. Eg, the point of the lightdm entry is
very likely to enable lightdm to 'override' arbitrary user commands by
making sure that the shell will find lightdm-commands of the same name
first.

OTOH, that's pretty much a truism.

Post by Janis Papanagnou
"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

As already written above: They are part of PATH because someone thinks
that's sensible. Whether or not they're necessary in a certain situation
is an entirely different question. If you want to work out empirically
what's "necessary" for you, remove them all and add directories to the
default PATH one-by-one as the need arises.

OTOH, what's the point? My flat contains more light switches than I
actually need, with some of them being (as far as I could determine)
entirely blind/ connected to lamps I don't use and some of them being
redundant because they switch lamps on or off which can also be switched
on or off with another light switch. But as they're just sitting on the
wall and removing them would require work, I haven't even considered
doing so.

[Janis Papanagnou]

Post by Rainer Weikusat

Post by Janis Papanagnou
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

Because someone thinks that all these locations should be searched for
commands in the order specified. Eg, the point of the lightdm entry is
very likely to enable lightdm to 'override' arbitrary user commands by
making sure that the shell will find lightdm-commands of the same name
first.

That's a thought that I had as well. But upon reconsideration I thought
that it wouldn't be necessary to _export_ that path component into the
user environment.

Post by Rainer Weikusat
OTOH, that's pretty much a truism.

Post by Janis Papanagnou
"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

As already written above: They are part of PATH because someone thinks
that's sensible. Whether or not they're necessary in a certain situation
is an entirely different question. If you want to work out empirically
what's "necessary" for you, remove them all and add directories to the
default PATH one-by-one as the need arises.

Well, I have a clear idea what I need and what is necessary. Since I
cannot remove that 'lightdm' thing I may just define the PATH anew in
my (shell-)environment.

Post by Rainer Weikusat
OTOH, what's the point? My flat contains more light switches than I
actually need, with some of them being (as far as I could determine)
entirely blind/ connected to lamps I don't use and some of them being
redundant because they switch lamps on or off which can also be switched
on or off with another light switch. But as they're just sitting on the
wall and removing them would require work, I haven't even considered
doing so.

That are different things. The switches are put in advance at places
that are reasonable. And you wouldn't put a switch below the WC, I'm
sure (read: "WC" ~ 'lightdm').

Janis

[Rainer Weikusat]

Post by Janis Papanagnou

Post by Rainer Weikusat

Post by Janis Papanagnou
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

Because someone thinks that all these locations should be searched for
commands in the order specified. Eg, the point of the lightdm entry is
very likely to enable lightdm to 'override' arbitrary user commands by
making sure that the shell will find lightdm-commands of the same name
first.

That's a thought that I had as well. But upon reconsideration I thought
that it wouldn't be necessary to _export_ that path component into the
user environment.

How else is it supposed to affect/ benefit users¹?

¹ According to the changelog of the Debian lightdm package, a 'gdm
flexiserver' script used to to be included with lightdm until 2014 and
the PATH addition was needed by that. Now, 2014 is 11 years ago. Maybe,
a software update could help?

[...]

Post by Janis Papanagnou

Post by Rainer Weikusat

Post by Janis Papanagnou
"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

As already written above: They are part of PATH because someone thinks
that's sensible. Whether or not they're necessary in a certain situation
is an entirely different question. If you want to work out empirically
what's "necessary" for you, remove them all and add directories to the
default PATH one-by-one as the need arises.

Well, I have a clear idea what I need and what is necessary. Since I
cannot remove that 'lightdm' thing I may just define the PATH anew in
my (shell-)environment.

You absolutely can removed the lightdm path entry. That's going to be
set during session or shell initialization, ie, either from some file
used by pam_nev (=> pam_env(7)) or in a shell initialization script (for
bournlike-shells, /etc/profile and /etc/profile.d).

Post by Janis Papanagnou

Post by Rainer Weikusat
OTOH, what's the point? My flat contains more light switches than I
actually need, with some of them being (as far as I could determine)
entirely blind/ connected to lamps I don't use and some of them being
redundant because they switch lamps on or off which can also be switched
on or off with another light switch. But as they're just sitting on the
wall and removing them would require work, I haven't even considered
doing so.

That are different things. The switches are put in advance at places
that are reasonable. And you wouldn't put a switch below the WC, I'm
sure (read: "WC" ~ 'lightdm').

I have a switch next to my garden door which does nothing. I think
that's most unreasonable because I sometimes press it because of
mistakenly believing it should turn the bedroom lamp on. I then usually
remember this when the lamp fails to turn on (or off).

[Keith Thompson]

Rainer Weikusat <***@talktalk.net> writes:
[...]

Post by Rainer Weikusat
I have a switch next to my garden door which does nothing. I think
that's most unreasonable because I sometimes press it because of
mistakenly believing it should turn the bedroom lamp on. I then usually
remember this when the lamp fails to turn on (or off).

"In my house there's this light switch that doesn't do anything. Every
so often I would flick it on and off just to check. Yesterday, I got a
call from a woman in Madagascar. She said, 'Cut it out.'"
― Steven Wright

[Waldek Hebisch]

Post by Janis Papanagnou
[...]

Post by Rainer Weikusat
The PDP-11 can be rationally compared with the situation of the OP,
namely, doing local filesystem operations on a single computer. [...]

Since you're referring to me, the OP, please note that most arguments
here have quickly made a relation to a straw man (a performance theme)
or made other deviations from the basic question(s) that concerned me.
Essentially there were two questions I had that I can reformulate in a
more compact form as
"Why, in the first place, are all these path components
part of the default PATH for ordinary users? - Is there
any [functional] rationale or necessity for that?"

On my Debian system PATH is:

/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games

'/bin' is a symlink to '/usr/bin', so AFAICS '/bin' could be
safely removed from the path. '/usr/local/games' and
'/usr/games' are empty and I do not intend to put anything
there, so they could be removed too. I have programs in
'/usr/local/bin' so for me minimal PATH could be

/usr/local/bin:/usr/bin

Note: On Debian when as a normal user I need something from
'/sbin' I use full pathname. That is purely matter of
convenience.

Note2: Some programs depend on specific PATH settings. IMO
it is responsibility of the program to ensure proper PATH.
In particular "main" program invoked by users may be a shell
scripts which sets up needed environment variables (including
PATH) and then execs acutal program.

Post by Janis Papanagnou
"_If_ many of the default PATH components are unnecessary,
where and how to best reduce these settings to a sensible
subset? - Without spoiling the system, of course."

Arguably, as long as standard system utilities are in the
PATH, nothing should brake. That is if some programs wants
something extra in PATH this is a bug in the program or at best
inconvenient user interface.

[Rainer Weikusat]

***@fricas.org (Waldek Hebisch) writes:

[...]

Post by Waldek Hebisch
/usr/local/bin:/usr/bin:/bin:/usr/local/games:/usr/games
'/bin' is a symlink to '/usr/bin', so AFAICS '/bin' could be
safely removed from the path. '/usr/local/games' and
'/usr/games' are empty and I do not intend to put anything
there,

Games packaged by Debian will usually install their binaries/ programs
in /usr/games. For as long as you don't actually install any games,
/usr/games sitting at the end of the path will have no effect except
increasing the time until a "command not found" error is displayed by an
immeasurably small amount.