Path: ...!eternal-september.org!feeder3.eternal-september.org!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From: Rainer Weikusat <rweikusat@talktalk.net>
Newsgroups: comp.unix.programmer
Subject: Re: Default PATH setting - reduce to something more sensible?
Date: Tue, 14 Jan 2025 19:23:41 +0000
Lines: 49
Message-ID: <87ed155hdu.fsf@doppelsaurus.mobileactivedefense.com>
References: <vm5dei$2c7to$1@dont-email.me>
	<87ikqh5n9u.fsf@doppelsaurus.mobileactivedefense.com>
	<53xhP.976$GtJ8.93@fx48.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net fQEpVcHZ/L6792pgL4A/GwVDSzIj7G4ngK8AkDOf0PK/3kYK0=
Cancel-Lock: sha1:JffcZp3VJCx+mgWkcoLSkksRadw= sha1:tvOOwRgtgcDjucQkWddM+6SoNwA= sha256:zP+LCHTNtIRjqfBNT3Dp/qLyocPk+hoJee2K1rAfE8I=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Bytes: 3257

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.