* Bug in code which searches for executables
@ 1991-11-16 2:21 David J. Fiander
1991-11-17 1:20 ` Paul D. Swasey
1991-11-17 4:23 ` Chris Siebenmann
0 siblings, 2 replies; 7+ messages in thread
From: David J. Fiander @ 1991-11-16 2:21 UTC (permalink / raw)
To: rc
I just found a bug in the code which searches for executables.
The problem was unearthed because I do not keep "." in my path.
The problem is that when you type "bin/foo", the program is not
found, but "./bin/foo" works. To reproduce, remove "." from
your path (since searching the path will find it), cd to / and
type
bin/echo hi
You should be told that bin/echo could not be found.
The problem is in which(). As you can see from the patch, I
have changed a call to "isabsolute()" which checks to see if
the path starts with /, ./, or ../, to a call to "strchr()" to
see if a "/" appears anywhere in the string for which we are
searching.
*** Standard Input Fri Nov 15 12:40:09 1991
--- which.c Fri Nov 15 09:56:23 1991
***************
*** 98,104 ****
#endif
}
! if (isabsolute(name)) /* absolute pathname? */
return rc_access(name, verbose) ? name : NULL;
len = strlen(name);
--- 98,104 ----
#endif
}
! if (strchr(name, '/')) /* explicit pathname? */
return rc_access(name, verbose) ? name : NULL;
len = strlen(name);
--
David J. Fiander |A man ought to read just as inclination leads him; for
<david@golem.uucp> |what he reads as a task will do him little good.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in code which searches for executables
1991-11-16 2:21 Bug in code which searches for executables David J. Fiander
@ 1991-11-17 1:20 ` Paul D. Swasey
1991-11-18 18:09 ` steve
1991-11-17 4:23 ` Chris Siebenmann
1 sibling, 1 reply; 7+ messages in thread
From: Paul D. Swasey @ 1991-11-17 1:20 UTC (permalink / raw)
To: rc
I used to think that ``begins with ./, ../, or /'' was correct. A
quick check shows ksh/sh working like your fix... hmm.
Rc let's you run programs in subdirectories of components of your
path... If I have a directory foo in $home/bin...and $home/bin is in
my path...and $home/bin/foo/bar is execuable, foo/bar will run
$home/bin/foo/bar from rc but not sh or ksh. Those other shells are
making a special case of the current directory. I like rc's behavior
more... anyone care to comment?
-dave
ps3u+@andrew.cmu.edu
R746PS3U@VB.CC.CMU.EDU
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in code which searches for executables
1991-11-16 2:21 Bug in code which searches for executables David J. Fiander
1991-11-17 1:20 ` Paul D. Swasey
@ 1991-11-17 4:23 ` Chris Siebenmann
1 sibling, 0 replies; 7+ messages in thread
From: Chris Siebenmann @ 1991-11-17 4:23 UTC (permalink / raw)
To: rc
This is not a bug, this is feature. rc is behaving exactly as the
manpage says it will (and as the Plan 9 rc does) in not presuming
an implicit './' in front of command names with slashes in them.
Various people consider this a feature, Rob Pike among them (I
overheard him commenting about this to someone else as the summer
Usenix), and it's been discussed on the mailing list in the
past.
- cks
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in code which searches for executables
1991-11-17 1:20 ` Paul D. Swasey
@ 1991-11-18 18:09 ` steve
0 siblings, 0 replies; 7+ messages in thread
From: steve @ 1991-11-18 18:09 UTC (permalink / raw)
To: rc
Paul D. Swasey writes in reference to <13027.690258112@golem>:
> Rc let's you run programs in subdirectories of components of your
> path... If I have a directory foo in $home/bin...and $home/bin is in
> my path...and $home/bin/foo/bar is execuable, foo/bar will run
> $home/bin/foo/bar from rc but not sh or ksh. Those other shells are
> making a special case of the current directory. I like rc's behavior
> more... anyone care to comment?
I prefer rc's way of doing things as well. Although I've never needed the
capability, I can easily imagine situations where I'd like to have it.
Mostly, I like the generality where ``foo/bar'' as a name is not treated in
any special/different way from ``bar''. That is, rather than view it as
rc letting me "run programs in subdirectories of components of [my] path",
I like to look at is as "components of my path specify fixed points to
search for the names of executables (where a name may or may not have a
``/'' contained within it) that are not bound to an absolute path
(e.g. ./foo/bar)".
Also, the current behavior of rc with respect to ``.'' in both path and
cdpath is identical. I'd hate to see an inconsistancy thrown into the works,
and the cdpath behavior seems quite logical (to me, at least).
Just my $0.02...
Steve Rezsutek
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in code which searches for executables
[not found] <9111170123.AA04583@piggy.ucsb.edu>
@ 1991-11-17 4:54 ` David J. Fiander
0 siblings, 0 replies; 7+ messages in thread
From: David J. Fiander @ 1991-11-17 4:54 UTC (permalink / raw)
To: Robert Earl; +Cc: rc
>From: Robert Earl <piggy.ucsb.edu!chupchup@rutgers.uucp>
>Actually, that's correct and documented behavior - both the manpage
>and the original implementors agree that's how it should work. I
>brought this up a while ago and Byron refused to change it then; I've
>kind of gotten used to it :-)
You're right! I never noticed that before. The problem is,
once again, that I am expecting the (k c '')^sh behaviour, but
Paul D. Swasey always thought that the rc behaviour was the way
they all behaved. It _is_ more consistent. I guess I'll just
have to get used to typing "./foo/bar" (I refuse to have '.' in
my path).
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in code which searches for executables
@ 1991-11-17 4:48 Scott Schwartz
0 siblings, 0 replies; 7+ messages in thread
From: Scott Schwartz @ 1991-11-17 4:48 UTC (permalink / raw)
To: byron, ps3u+, rc
| I don't think that one solution has much merit or utility over the other,
I like rc's behavior much better, and I think it has particular
utility. It enables you to bundle a number of binaries that make up a
software package in a natural way without putting junk in your path,
and without cluttering bin too much. For example, sccs/get,
pbm/pbmtops, ingres/foo.
^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Bug in code which searches for executables
@ 1991-11-17 2:55 Byron Rakitzis
0 siblings, 0 replies; 7+ messages in thread
From: Byron Rakitzis @ 1991-11-17 2:55 UTC (permalink / raw)
To: ps3u+, rc
I'll comment, and say that if you want to execute "bin/foo" when you
really mean "./bin/foo" then you should say what you mean. I don't think
that one solution has much merit or utility over the other, but the fact
is that rc's solution has a simpler rule.
^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~1991-11-18 18:09 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1991-11-16 2:21 Bug in code which searches for executables David J. Fiander
1991-11-17 1:20 ` Paul D. Swasey
1991-11-18 18:09 ` steve
1991-11-17 4:23 ` Chris Siebenmann
1991-11-17 2:55 Byron Rakitzis
1991-11-17 4:48 Scott Schwartz
[not found] <9111170123.AA04583@piggy.ucsb.edu>
1991-11-17 4:54 ` David J. Fiander
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).