hokey@plus5.UUCP (Hokey) (08/01/85)
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? The following shar file demosntrates the bug using "make" on my machine. Additionally, if the unpacking is done in, for example, /tmp, the bug can also be demonstrated by the sequence: $ cd /tmp $ PATH=/: $ ls -l showbug -rwxrwxr-x 1 hokey usr 9 Aug 1 00:54 showbug $ showbug showbug: not found --- # This is a shell archive. Remove anything before this line, # then unpack it by saving it in a file and typing "sh file". # # Wrapped by hokey on Thu Aug 1 00:56:39 CDT 1985 # Contents: makefile showbug echo x - makefile sed 's/^@//' > "makefile" <<'@//E*O*F makefile//' # If the next line reads "PATH=/usr/bin:/bin:." then all is well. PATH=/usr/bin:/bin: SHELL=/bin/sh all: set ; showbug @//E*O*F makefile// chmod u=rw,g=rw,o=r makefile echo x - showbug sed 's/^@//' > "showbug" <<'@//E*O*F showbug//' echo Foo @//E*O*F showbug// chmod u=rwx,g=rwx,o=rx showbug exit 0 -- Hokey ..ihnp4!plus5!hokey 314-725-9492
henry@utzoo.UUCP (Henry Spencer) (08/02/85)
> 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. Try two trailing colons. If you read the (post-V7) manual page very carefully, this behavior is documented: colon is effectively functioning as a terminator rather than as a separator. It is agreed that this (a) is a botch, and (b) ought to be documented more prominently. -- Henry Spencer @ U of Toronto Zoology {allegra,ihnp4,linus,decvax}!utzoo!henry
guy@sun.uucp (Guy Harris) (08/06/85)
> 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
guy@sun.uucp (Guy Harris) (08/06/85)
> > 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. > > Try two trailing colons. If you read the (post-V7) manual page very > carefully, this behavior is documented: colon is effectively functioning > as a terminator rather than as a separator. For those without a) post-V7 documentation for the Bourne shell or b) the patience to try to find it, the magic sentence is: Execution ...Note that the current directory is specified by a null path name, which can appear immediately after the equal sign or *between the colon delimiters* anywhere else in the path list. The italicized phrase is the obscure clue. Guy Harris
mash@mips.UUCP (John Mashey) (08/07/85)
> > 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. > > I have noticed this bug under Vr0 and Vr2. Is this problem more widespread > > than just my vendor? > ...... > 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 fix should be obvious (look in "service.c") - unless this is a feature, > not a bug... It is clearly a bug, not a feature, because it does not work like execvp(2), which is supposed to be the canonical definition of what exec $PATH search is. To verify this (from Bourne shell, with command in current directory): PATH=:/bin time command (works) PATH=/bin: time command (works) PATH=/bin: command (not found) This is clearly wrong; a long time ago, far away, we went to some pain to get the identical path-search code into every command .... except /bin/sh. sigh. -- -john mashey UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash DDD: 415-960-1200 USPS: MIPS Computer Systems, 1330 Charleston Rd, Mtn View, CA 94043
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/09/85)
> For those without a) post-V7 documentation for the Bourne shell or b) the > patience to try to find it, the magic sentence is: > > Execution > ...Note that the current directory is specified by a > null path name, which can appear immediately after the > equal sign or *between the colon delimiters* anywhere > else in the path list. > > The italicized phrase is the obscure clue. Yeah, but the manual entry is just documenting the bug, not justifying it. PATH=/bin:/usr/bin names TWO directories, not ONE. There seems to be no good reason why the null path (current directory) shouldn't be treated the same as every other entry in the colonized ( :-) ) string. In fact, I think I'll fix this in the BRL Bourne shell tonight. I hate bugs; especially I hate hearing them called features! This is a particularly obnoxious bug, since to avoid tripping over land mines planted by mischievous turkeys, one wants to search the current directory LAST, and this is just where the bug bites.
lda@bonnie.UUCP (Larry Auton) (08/09/85)
In article <2562@sun.uucp> guy@sun.uucp (Guy Harris) writes: >> 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.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 If you consider the ':' in the PATH to be the terminator, and the end of the string to be a terminator only by necessity (i.e. convenience), then the "bug is not a bug". If PATH=:/bin:/usr/bin then the first component in the string is NULL, and thus by default, points to the current directory. If PATH=/bin::/usr/bin Then the second component is NULL, and the current directory is searched. Finally, if PATH=/bin:/usr/bin: then there *is no third component to the path*, and so the current directory is not searched. It's only a convenience to the user to allow paths that do not end with a ':'. All paths "should" end with a ':', just as all interrogatory sentences "should" end with a '?'. See what I mean -- Larry Auton (201)386-4272 ihnp4!bonnie!lda
hokey@plus5.UUCP (Hokey) (08/10/85)
> Try two trailing colons. If you read the (post-V7) manual page very > carefully, this behavior is documented: colon is effectively functioning > as a terminator rather than as a separator. OK, the there is a bug in csh, because my .login contains: set path=(/usr/local/bin /bin /usr/bin /etc /usr/games .) which sets my PATH to be: PATH=/usr/local/bin:/bin:/usr/bin:/etc:/usr/games: -- Hokey ..ihnp4!plus5!hokey 314-725-9492
jim@ISM780B.UUCP (08/11/85)
Is there anyone at AT&T responsible (ha ha) for bug fixes and/or quality control who reads the net and acts upon these bug reports? If so could they please respond on the net? If not, why not? (Can you say b u r e a u c r a c y ? I thought you could.) -- Jim Balter, INTERACTIVE Systems (ima!jim)
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (08/15/85)
> If you consider the ':' in the PATH to be the terminator, and the > end of the string to be a terminator only by necessity (i.e. convenience), > then the "bug is not a bug". Oh, yuck. What sort of specification is this? It's a bug! (Fix has been posted.)