Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Posting-Version: version B 2.10.2 9/18/84 SMI; site sun.uucp Path: utzoo!linus!decvax!decwrl!sun!guy From: guy@sun.uucp (Guy Harris) Newsgroups: net.bugs.usg Subject: Re: PATH bug? Message-ID: <2562@sun.uucp> Date: Tue, 6-Aug-85 01:16:38 EDT Article-I.D.: sun.2562 Posted: Tue Aug 6 01:16:38 1985 Date-Received: Wed, 7-Aug-85 04:24:05 EDT References: <807@plus5.UUCP> Organization: Sun Microsystems, Inc. Lines: 35 > If the current directory is specified as the last directory searched using > a trailing ":" instead of ":." (in $PATH) then sh will not find executable > files in the current directory. > > The problem only seems to occur when the current directory is searched last. > > I have noticed this bug under Vr0 and Vr2. Is this problem more widespread > than just my vendor? Yup, sure is. I tried it here on our Sun and it occurs there, too. Wait a minnit, Sun UNIX is 4.2 and has the V7 shell... Yes, it's even more widespread than you might think. I suspect it's in every Bourne shell (except for the ones that've fixed it). The problem is that the routine "catpath", which extracts the next element from the path string it's handed as its first argument, concatentates its second argument to it (with an intervening '/' unless the element it's concatenating it with is a null string), and returns a pointer to the element following the one it concatenated, returns a null pointer (indicating "no more elements") if the path element after the one it concatenated is null - *not* just if there is no such element. I.e., it doesn't know the difference between /bin:/usr/bin and /bin:/usr/bin: The fix should be obvious (look in "service.c") - unless this is a feature, not a bug... Guy Harris