Subject: Re: Bug? execvp w/dead NFS server (fwd)
To: Brian C. Grayson <email@example.com>
From: John F. Woods <firstname.lastname@example.org>
Date: 09/30/1997 08:23:12
> ``/usr/local/bin/acrobat exists, and I can cksum it, so why does
> the shell complain that a resource is temporarily unavailable when
> I try to run it without specifying a full path name, while it
> works if a full path name is specified?''
I have seen that behavior on every NFS system I've used. I think it's
a (mis)feature, rather than a bug. You can get similar behavior with an
ailing disk drive in an early part of your $PATH.
As to the possibility that the shell could continue to march down $PATH
after more errors than it does: suppose that there had been an executable
named "acrobat" on that NFS partition, one with some extra flags added,
and the reason the NFS partition's directory came first in $PATH is that
you WANTED that one instead of the one in /usr/local/bin. (It is not at
all uncommon for people to install improved versions of standard utilities
in /usr/local/bin, for example.) The shell cannot tell whether the failed
component of $PATH was supposed to contain the executable you wanted to
use in preference to a later one, so it really should stop and complain.