Path: ...!weretis.net!feeder8.news.weretis.net!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: Wed, 15 Jan 2025 19:19:36 +0000
Lines: 52
Message-ID: <8734hjga0n.fsf@doppelsaurus.mobileactivedefense.com>
References: <vm5dei$2c7to$1@dont-email.me>
	<87ikqh5n9u.fsf@doppelsaurus.mobileactivedefense.com>
	<53xhP.976$GtJ8.93@fx48.iad>
	<87ed155hdu.fsf@doppelsaurus.mobileactivedefense.com>
	<poBhP.1243903$bYV2.919023@fx17.iad>
	<877c6wf5o2.fsf@doppelsaurus.mobileactivedefense.com>
	<rRQhP.65293$XfF8.23235@fx04.iad>
Mime-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Trace: individual.net 1IUdM5wRvrivrJrx3KDg9Aao5sxBK86B0APuciOqMxcrd4M+c=
Cancel-Lock: sha1:4hyecTxHJxQYuokVOcAC+dFOc7A= sha1:JZw5Ah1M3mpIY2ahy4VshAv89Cw= sha256:/xL1Plzs1hxHq5EioWBSVJCHAXzUhqklwb+PmteRygw=
User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.1 (gnu/linux)
Bytes: 3607

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.