modification to rc 1.1 gamma

modification to rc 1.1 gamma

[David Hogan]

Some of us were very much taken with the way rc used to work, in that
if you typed a command and it wasn't found it would say "not found".
We thought this was a good idea.

We (John and David) are very much opposed to the change Byron has
made in 1.1 gamma to do a perror-type message under these conditions.
If you are also, here's a change you can apply to the sources to get
the old behaviour back.  If you decide you don't want it, you can
just fail to define NOVERBOSE in config.h.

Byron -- any chance of having this adopted in the main sources so that
we don't have to apply it to each new version?

*** KEEP/config.h	Sat Aug 10 21:07:33 1991
--- ./config.h	Sat Aug 10 21:13:04 1991
***************
*** 39,41 ****
--- 39,43 ----
  /* with special characters in them, rc can put out ugly variable names using [_0-9a-zA-Z] */
  /* that encode the real name; define PROTECT_ENV for this hack */
  #define	PROTECT_ENV
+ 
+ #define	NOVERBOSE
*** KEEP/exec.c	Sat Aug 10 21:07:33 1991
--- ./exec.c	Sat Aug 10 21:07:45 1991
***************
*** 53,58 ****
--- 53,61 ----
  	if (b == NULL) {
  		path = which(*av, TRUE);
  		if (path == NULL && *av != NULL) { /* perform null commands for redirections */
+ #ifdef	NOVERBOSE
+ 			fprint(2,"%s not found\n",*av);
+ #endif
  			set(FALSE);
  			redirq = NULL;
  			empty_fifoq();
*** KEEP/which.c	Sat Aug 10 21:07:39 1991
--- ./which.c	Sat Aug 10 21:16:08 1991
***************
*** 16,21 ****
--- 16,22 ----
  #include <sys/param.h>
  #include <errno.h>
  extern int errno;
+ #include "config.h"
  #include "builtins.h"
  
  #define M_USR 0700
***************
*** 75,80 ****
--- 76,85 ----
  	int mask;
  	int ret;
  
+ #ifdef NOVERBOSE
+ 	verbose = 0;
+ #endif
+ 
  	if (stat(path, &st) != 0) {
  		if (verbose)
  			uerror(path);
***************
*** 114,119 ****
--- 119,128 ----
  	List *path;
  	int len;
  	int err = ENOENT;
+ 
+ #ifdef NOVERBOSE
+ 	verbose = 0;
+ #endif
  
  	if (name == NULL)	/* no filename? can happen with "> foo" as a command */
  		return NULL;

Re: modification to rc 1.1 gamma

[Mark-Jason Dominus]

> Some of us were very much taken with the way rc used to work, in that
> if you typed a command and it wasn't found it would say "not found".
> We thought this was a good idea.

Why?

Re: modification to rc 1.1 gamma

[Boyd Roberts]

    From: Mark-Jason Dominus <mjd@saul.cis.upenn.edu>

    > Some of us were very much taken with the way rc used to work, in that
    > if you typed a command and it wasn't found it would say "not found".
    > We thought this was a good idea.

    Why?

I think the answer will be `nostalgia':

nostalgia
(no stalj <schwa> , -je  <schwa> , n <schwa> -), n.
a desire to return in thought or in fact to a former time in one's life,
   to one's home, or to one's family and friends.
[ <  NL  <  Gk nost(os) a return home + -algia -ALGIA]--nostalgic,
   adj.--nostalgically, adv.

Re: modification to rc 1.1 gamma

[John Mackin]

Mark-Jason wanted to know why we were of the opinion that "not found" was
the best message to print when a path search failed.  Boyd offered the
thought that nostalgia accounted for it.  I would be lying if I didn't
admit that was a factor, but that's not all, by a long way: I'd say that
mv view, at least, derives perhaps 20% from longing for the old days,
and 80% from general considerations of shell design and the experiences
I had with exactly this feature in the Pike shell.

So, nostalgia and esthetic considerations placed aside (and I do agree
that the perror-style messages are ugly), let's examine the purely
objective case.

The point is that, in my view, it is important not to mislead the user,
and that's exactly what you're looking at doing if you print anything
beyond "not found".  Let's look at this in some detail.

Clearly, if any exec anywhere along the path succeeds, you don't want to
print any error messages at all.  I trust we are all agreed on that
point; it is, after all, a well-established principle of how shells
work, and people do take advantage of this: changing one binary
to mode zero, for example, so that another one somewhere else
in the path will be found instead.  Of course, there could be
a counter-argument made here to the effect that there are only
two values of errno that are `expected' on an attempted exec of
a command during a shell path search, viz. EACCES and ENOENT, and
that if you get any other value, you should abandon the search and
print a perror-style message.  (Except, of course, for ENOEXEC, and
if you get that the search is over anyway.)  I don't feel strongly about
that issue; I wouldn't mind if a shell did that, but I don't think it's
massively important.  The opinion I do hold comes down slightly on
the side of doing that rather than not; it is, after all, `extra'
code, but on the other hand, it's precisely when things get weird that
you want to know what's happening.  I'm not prepared, though, to
argue for the proposition that rc should do this.

So, we have the current position: traverse the path, try all the exec's,
go all the way along, and report failure only at the end.  The issue is
how that failure ought to be reported.  The proposal that was made was
that a sys_errlist message should be printed.  OK, let's see -- we
know, already, that _all_ the execs failed.  So we're trying to tell
the user why they failed.  If I understand correctly what rc1.1gamma
does (just intuitively, without reading the code), it is this:

did any of the execs fail with EACCES?
yes: print "command: Permission denied".
no: print "command: No such file or directory".

This is just totally, 100% _bogus_.  These messages mean _nothing_.
They don't help anybody, since they don't really contain any
information.  Say the shell (any shell) does print "command: Permission
denied".  Wow.  One (or more!) of the execs, somewhere along the
path, gave EACCES.  So what?  _WHICH ONE/S????_  That's what matters.

Now, I'm all for sys_errlist messages.  There's nothing I hate worse
than a program that just prints "cannot open".  But in this instance,
the shell isn't telling me a damn thing.

Let's see how it might tell me something.  Suppose there's a "frogmouth"
in /bin and it's mode zero.  Just printing

frogmouth: Permission denied

is heavily stupid, as we have seen.  So, how about this?

/bin/frogmouth: Permission denied

Now that's a little better (but only a little, as we shall see).  I could
almost get behind a message like that.  But wait!  What about the logical
extension?  Suppose there's _also_ a mode zero frogmouth in /usr/local/bin?
We can't just print _one_ error: again, we're being heavily stupid and
misleading the user if we do that.

/bin/frogmouth: Permission denied
/usr/local/bin/frogmouth: Permission denied

From there, it's only a short step to seeing that what we really want is
not a simple error message, but an "execution attempt failure explanation":

/bin/frogmouth: Permission denied
/usr/bin/frogmouth: Resource lost
/etc/frogmouth: Stale NFS file handle
/usr/etc/frogmouth: No route to host
/usr/local/bin/frogmouth: Object is remote

And after that, why leave out the "No such file or directory"s?  Put
them in there as well!

Some might claim this is a silly argument -- but it's not.  It's really
the way it works once you make the wrong design decision.  Hey, you
couldn't find the command?  Just say "not found".  And if the user
thinks it should have been, well, how hard is it to type

for (p in $path) ls -l $p/cmd

The prosecution rests.  (Mark-Jason, after your wonderful mail about
the perils of random local builtins, I'm a bit surprised at you.)

OK,
John.

Re: modification to rc 1.1 gamma

[Mark-Jason Dominus]

In my own defense, I'd like to point out that it wasn't my idea to put
in perror-errors on failed path search.  I agree with everything John
Mackin said, and I still think that `not found' is wrong in certain
circumstances.  I want to reproduce my original mail message on the
subject, because I find myself being identified as a supporter of rc's
current behavior, and I'm not; I never was.


Mail from mjd@saul.cis.upenn.edu of Tue, 2 Jul 1991:
> It seems that if I try to execute a command `foo' for which I don't have
> execute permission, rc gives me `foo not found', which is justifiable if
> rc had to do a path search to find `foo', but not justifiable if `foo'
> specified a path.  That is:
> 
>         ; echo $path
>         /usr/etc
>         ; ls -l /usr/etc/shutdown
>         -rws------  1 root        24576 Mar  6  1990 /usr/etc/shutdown
>         ; shutdown
>         shutdown not found
> 
> makes sense (although you could argue against it), but
> 
>         ; /usr/etc/shutdown
>         /usr/etc/shutdown not found
> 
> is incorrect.

    I say: `not found' is fine for when a path search was performed, for
all the reasons John Mackin said, but `not found', when I've specified
an absolute path to a file that does exist, is wrong.

    I suggested in email to Byron that perhaps the `foo not found' error
be changed to `couldn't run foo' instead; that's more generic and
possibly less confusing.  Someone might argue that `not found' is
innaccurate, but nobody could argue with `couldn't run'---that's exactly
what happened.  If there's only one error message, then the informatihon
content is the same.

`Couldn't run' also makes sense whether or not the path was searched:

	; shutdown
	Couldn't run shutdown
	; /usr/etc/shutdown
	Couldn't run /usr/etc/shutdown

   Nihil tam absurde dici potest, quod non dicatur ab aliquo philosophorum.
Mark-Jason Dominus 	  			    mjd@central.cis.upenn.edu 

Re: modification to rc 1.1 gamma

[John Mackin]

Mark-Jason writes:

    [...] I find myself being identified as a supporter of rc's
    current behavior, and I'm not; I never was.

Oops, we were at cross-purposes.  I didn't pay sufficient attention to
Mark-Jason's mail of 2 July, and then he in his turn failed to divine the
intent of my NOVERBOSE modification, and when he asked `Why?' I thought
he was disagreeing with me... sigh.

What we see here is that Mark-Jason, David and I are all in complete
agreement with Byron's current position on reporting pathname search
failure.  On that point, there is no problem at all.  (That is, the
position he has stated he is going to go back to -- not the position
implemented in 1.1gamma.)

However, and thanks to Mark-Jason for pointing this out, there is
actually quite a bad _bug_ in rc at the moment:

; /etc
/etc not found

This is just _wrong_.  No possible argument can be made in favour of
this behaviour.  I trust everyone can see the difference between
reporting the failure of a _path search_ and giving the correct
message from sys_errlist when there was no path search involved at
all.  I mean, after all, when rc tries to open a file for a redirection
and it fails, it gives the 100%-correct, no-one-could-possibly-argue
message "file: sys_errlist message", and not some bogus "cannot open"
or "cannot create".  _Exactly the same principle must be applied here_;
if the exact pathname of the file to execute was specified, then the
precise description of errno _must_ be printed.  I never realised rc
did this, or I would have made this point earlier.

As to changing "foo not found" into "couldn't run foo", I'm against it.
Count this as one vote firmly on the side of "not found".  (And call me
nostalgic if you like.)

OK,
John.