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

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

In article <vm5dei$2c7to$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>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.

>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.

>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.

>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.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> 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.

Rainer Weikusat <rweikusat@talktalk.net> writes:
>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> 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.

On 2025-01-14, Scott Lurndal <scott@slp53.sl.home> wrote:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>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.

--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca

scott@slp53.sl.home (Scott Lurndal) writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> 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.

Rainer Weikusat <rweikusat@talktalk.net> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>>> 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.

>
>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.

[Followup-To: comp.unix.shell]

In article <poBhP.1243903$bYV2.919023@fx17.iad>,
Scott Lurndal <slp53@pacbell.net> wrote:
>Rainer Weikusat <rweikusat@talktalk.net> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> [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.
>
>>
>>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.

scott@slp53.sl.home (Scott Lurndal) writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:

[...]

>>>>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.

[...]

>>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

Rainer Weikusat <rweikusat@talktalk.net> writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>
>[...]
>
>>>>>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.

> 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.

>
>[...]
>
>>>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.

scott@slp53.sl.home (Scott Lurndal) writes:
> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>scott@slp53.sl.home (Scott Lurndal) writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>>Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>
>>[...]
>>
>>>>>>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.

>> 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.

On 15.01.2025 20:19, Rainer Weikusat wrote:
> scott@slp53.sl.home (Scott Lurndal) writes:
>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
[...]

> 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

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>On 15.01.2025 20:19, Rainer Weikusat wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>[...]
>
>> 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.

>
> "_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.

In article <vm9err$35gfs$1@dont-email.me>,
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>[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.

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 15.01.2025 20:19, Rainer Weikusat wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>
>> 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.

>
> "_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 <janis_papanagnou+ng@hotmail.com> wrote:
> On 15.01.2025 20:19, Rainer Weikusat wrote:
>> scott@slp53.sl.home (Scott Lurndal) writes:
>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>> scott@slp53.sl.home (Scott Lurndal) writes:
>>>>>>> Rainer Weikusat <rweikusat@talktalk.net> writes:
>>>>>>>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> [...]
>
>> 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.

> "_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.

--
Waldek Hebisch

antispam@fricas.org (Waldek Hebisch) writes:

[...]

> 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,

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.