| Sysop: | Amessyroom |
|---|---|
| Location: | Fayetteville, NC |
| Users: | 26 |
| Nodes: | 6 (0 / 6) |
| Uptime: | 58:29:26 |
| Calls: | 481 |
| Files: | 1,071 |
| Messages: | 95,939 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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> writes:
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.
[ NFS snipped ]
"_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.
On 16.01.2025 12:51, Rainer Weikusat wrote:
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
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.
"_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.
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').
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!)
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)
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:
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.
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.
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:
[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.
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.
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.
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.
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.
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. [...]
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."
[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?"
"_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."
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."
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."
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,