Re: Bug in code which searches for executables

Re: Bug in code which searches for executables

[Scott Schwartz]

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

Re: Bug in code which searches for executables

[steve]

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

Re: Bug in code which searches for executables

[David J. Fiander]

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

Re: Bug in code which searches for executables

[Chris Siebenmann]

 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

Re: Bug in code which searches for executables

[Byron Rakitzis]

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.

Re: Bug in code which searches for executables

[Paul D. Swasey]

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

Bug in code which searches for executables

[David J. Fiander]

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.