Re: Default PATH setting - reduce to something more sensible?

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