Re: rc futures

[Paul Haahr <haahr@jivetech.com>]

Tim Goodwin wrote, replying to me, replying to him:

> > How?  With es, we use combinations of ^A and ^B,
> 
> I've considered a number of ideas, and had settled on using ^A and ^B
> (independently: I didn't know that this was how es solved the problem).
> I will look at es, and ensure that the rc fix is compatible.

Great.

> >                                                  but it's at least as
> > gross a hack as not allowing ^A.
> 
> I disagree here.  I don't see anything gross about using a transparent
> encoding.  The ^A bug makes the world "not simple" for the user: you
> have a perfectly good tool, except that it happens to fall apart for
> certain cases.  It's almost as bad as "sed: line too long".  Do you want
> people to use Perl? :-)

I guess I've been bitten so rarely by the restriction that it doesn't
bother me.  Much more troublesome as a practical matter, IMNHO, is the
restriction about not putting \0 in es strings, but that's much more
problematic to ``fix.''


> Point 8 is that you can say this:
> 
>     fn foo { (x.y) = foo; echo $(x.y) }
> 
> and `foo' works fine in the current shell, but not in descendant shells.
> Again, I think this is a clear case of "not simple" for the user: either
> the parent shell should reject the function definition, or it should
> work in child shells.
> 
> Now, it might turn out that fixing this turns out to be really hard,
> in which case I won't bother.  It's not that big a deal.  But I have a
> sneaking feeling that this is one of my favourite sort of bugs, where
> the bug fix actually makes the code simpler.

I think it's just a bug in footobar.c:Tconv(), where the current code is
a little too pessimistic about when to insert parentheses.  See the case
which handles nCount, nFlat, and nVar.  The test which sets lp and rp
(using an audacious comma expression) should probably also look at the
contents of the string to see if it's got ``interesting'' characters.


> > I think there was a good reason for preferring $PATH:  rc invokes a
> > sh(1) script which sets $path and then invokes and rc script.  Changing
> > this behavior would be a mistake.
> 
> A number of people have made the same point.  I agree.  However, given
> this, I claim that $path and friends should not be exported by rc, nor
> (ever) interpreted by descendant rc processes.

Agreed.  Es avoids exporting $path and $home for that reason.


> > > 11. `.' should search `$path'.  This will be fixed.
> > Why?
> Every other shell does, including (I'm told) the Plan 9 rc.

Interesting.  The docs for Plan 9 rc indicate that that's true, going
back to the version in the printed 10th edition manuals.  As do sh and
its descendents, though not the csh family.  According to Chet Ramey,
Posix mandates path searching for ``.'' in csh.

But Byron's rc never has, and I don't think it should.  Byron put it
better than I could in a note to this list from 1993:

  From: byron@netapp.com (Byron Rakitzis)
  To: davidf@golem.waterloo.on.ca
  Cc: rc@hawkwind.utcs.toronto.edu
  Subject: Re: rc 1.5
  Date: 	Fri, 16 Apr 1993 18:21:39 -0400

  >Will 1.5 be brought into line with the Plan 9 man page?

  That's a good question. I'm hoping to freeze rc. I also don't feel
  the need to bring rc "into line" with anything else. So offhand I
  would say no. The flag command is present in plan9 rc for a very
  specific reason (/lib/rcmain). And I don't want dot to search
  my path. What if I do:

	  ; cat >test <<EOF
	  garbage
	  EOF
	  ; . test

  and "." is at the end of my path? Does this mean I run /bin/test
  as rc input? (THIS IS WHAT /bin/sh ACTUALLY DOES!!)

  No thank you.


> > > 13. Add the `flag' builtin ...
> > Why?
> [...]  The main reason is to make point 14 work, though.
> 
> > > 14. Add a command line flag that means "don't export any variables".
> > [...]
> 
> Well, ever since I've been involved with rc the man page has listed
> it as a bug, and there's been discussion on the list about it before.
> Personally, I have no war stories, and you're right that it would add a
> fair dose of complexity.
> 
> Any other opinions?  Does anyone have a real need for this?

I would strongly suggest you leave this on the back burner (and perhaps
remove the comment from the man page) until it becomes a pressing issue
for real applications.


> > > 15. Fake bidirectional pipes on systems where `pipe()' produces a
> > 
> > Why bother?  How many times do you find programs that can communicate
> > with the previous member of a pipeline by writing to their standard
> > input?
> 
> It's utterly trivial to do, and there are apparently some Plan 9
> scripts that use it.

Except that it adds at least one more #ifdef option, which is a much
higher configuration and complexity increase than the utility of the
feature merits.

(I've come to believe that conditional compilation options are almost
always wrong.)


> >           Adding a ``rc:'' prefix seems a mistake to me.
> 
> Can you learn to live with it?

(Me?  I don't actually use rc anymore.  As much as I use a shell, I use
es, but I probably use complex shell commands once a day at most.  But I
continue to think of rc as one of the most nearly perfect programs I see,
so my advice about it will always be radically conservative.)

> In my job, I reach for strace, truss, or ktrace *every single day*.
> At least 50% of the time it's to find out information about an error
> situation which the application knew, but decided not to bother
> reporting---and yes, sometimes, it's as fundamental as not even
> knowing which application encountered an error.
> 
> Stealing Smarasderagd's example, I know which of these I'd rather see.
> 
>     ; host microsoft.com
>     host not found
> 
>     ; host microsoft.com
>     rc: `host' not found
> 
> Maybe you think those 6 extra characters are ugly.  But they also make
> it blindingly obvious what went wrong.

I guess I work on enough different problems from you that this hasn't
hit me.  The quotes do help in the error message, I think, and are
vastly preferable to the ``:'' sh and es use.  The rc prefix doesn't
add anything, but that's just my opinion.  (I guess I don't want the
shell to be drawing attention to itself.)

Much more useful, I think, as an addition to error messages would be
printing the program which actually died with a signal in a pipeline.
For example, in:

  ; ls | sleep 1000 | wc
        0       0       0
  illegal instruction
  ;

it could have been helpful to know that it was sleep that got killed.

--p