Re: A delicious thought

Re: A delicious thought

[Arnold Robbins]

Everything old is new again.....

I read in an early history of unix paper that on the very early unix
systems (pdp-7 vintage!) everything in fact worked this way. You typed
a command. The shell exec'ed it, and then the code in exit() would re-exec
the shell.

When they added fork to the system, they noticed that 'cd' didn't take them
anywhere.... At that point it became built-in to the shell.

I could almost see doing this with limit. cd is a bit expensive, methinks
(just think about the TWO call through nami. One to find cd, the next to
do the chdir. ugh)

Arnold

Re: A delicious thought

[Alan Watson]

[Hi, Richard, remember me from GROGGS way back?]

Richard Brooksby wrote:
> > You can't do cd et al. properly in the way I suggested, as rc does
> > not keep all of its state in the environment...
>    :
> > Of course, we could have rc realize its entire state in the
> > environment, but I hear the wolves baying over in the es list, so I
> > won't even suggest this.
> 
> What you are suggesting is just that rc should be continuation rather
> than stack based.  I doubt that even the es designers contemplated
> this option, although it would make a very interesting shell.

Like I said, I didn't even suggest this.

> A nicer thing, in my humble opinion, would be to include a foreign
> function interface and allow dynamic linking to libraries.  One could
> then import Clib and make system calls directly.

Not in rc; perhaps in es.  rc is the clean(er) and simple(r) one, remember.

The difference between rc and es is that rc makes the choices for you,
so you don't have the opportunity to get them wrong :-).

Re: A delicious thought

[Richard Brooksby]

Alan Watson <alan@oldp.astro.wisc.edu> wrote:

> You can't do cd et al. properly in the way I suggested, as rc does
> not keep all of its state in the environment...
   :
> Of course, we could have rc realize its entire state in the
> environment, but I hear the wolves baying over in the es list, so I
> won't even suggest this.

What you are suggesting is just that rc should be continuation rather
than stack based.  I doubt that even the es designers contemplated
this option, although it would make a very interesting shell.

However, since the Unix process model is stack based (process
parent/child relationships are just like a stack) it wouldn't mesh
very well.

A nicer thing, in my humble opinion, would be to include a foreign
function interface and allow dynamic linking to libraries.  One could
then import Clib and make system calls directly.
---
Richard Brooksby <richard@harlequin.co.uk>
ML Project / Symbolic Processing Division / Harlequin
+44 223 872522

Re: A delicious thought

[root]

> 	; fn cd { exec not-built-in-cd $* }
> 	; cat `{ whatis not-built-in-cd }
> 	#! /bin/sh
> 	cd ${1+$"$@"}
> 	exec rc
> 	;

This does the Wrong Thing within a script.

Re: A delicious thought

[Alan Watson]

I should never post before lunch: my hunger even affected the title.

You can't do cd et al. properly in the way I suggested, as rc does not keep
all of its state in the environment (specifically, it doesn't keep where it
is an a flow control construct, the input stack, $*, and $status). So, you
couldn't use a not-built-in command in an if () statement, couldn't use
it in a script, and couldn't find out if it worked or not.

I thought that we might at least salvage a non-builtin-in limit, but then
I realized that probably the most common use of limit is to set coredumpsize
to 0 in .rcrc.

Of course, we could have rc realize its entire state in the environment,
but I hear the wolves baying over in the es list, so I won't even
suggest this.

Alan.

Re: A delicious thought

[Byron Rakitzis]

Actually, before I used rc I ran "limit" in the following way:

	:; exec csh
	% limit frob-me 0
	% exec sh
	:;

and I am not completely sure I want to go back. Thanks to Paul Haahr
for this trick, btw.

A delicious thought

[Alan Watson]

rc keeps everything in the environment (other than its flags and at
least until noexport arrives), so there is almost no need for any
built-in commands whatsoever: simply, exec a command which performs the
`built-in' and then have that command exec another rc, e.g.:

	; fn cd { exec not-built-in-cd $* }
	; cat `{ whatis not-built-in-cd }
	#! /bin/sh
	cd ${1+$"$@"}
	exec rc
	;

Flags like `-x' don't get carried over, but otherwise this seems like a
complete functional replacement of cd (and, likewise, limit, wait, and
umask).  Of course, if you really wanted to do this, you'd probably code
up the not-built-ins in C.

All of this is somewhat academic, but if someone DID want to add a new
built-in (or, rather, something which had to function in the same
process as rc), this would be an obvious solution.  To me, this is a
strong argument in favour of placing the flags in the environment (or,
at least, what they can be read into the environment) and against
noexport (or, at least, against a no export which cannot be easily and
temporarily over-ridden).

Once again, rc's clean design and the original philosophy of putting
everything into the environment seems to be paying off dividends.

Alan.

P.S. A free email message to the first person to publicly claim that
they really do want to exec twice just to change directory (limit is a
more obvious candidate to go to a not-built-in implementation --
wouldn't you like to get one more piece of #ifdef-ed code out of the
source?).