Interesting things from the Plan 9 rc manpage

Interesting things from the Plan 9 rc manpage

[Chris Siebenmann]

 $" is the Plan 9 rc syntax for Byron's $^ string flattening operator.
 'if not' is still there.
 The Plan 9 rc has a number of interesting options:
	-s:	Print out exit status after any command where the
		status is non-null (false).
	-I:	Do not run interactively, regardless of whether or
		not standard input is attached to a terminal.
 -p is listed as a no-op; presumably no one has bothered implementing
it.
 There's a 'flag' builtin that lets you test, set, and clear the
status of command-line flags.

 The manual page doesn't have a FILES section, so I don't know if the
Plan 9 rc has abandoned the 'source a file on startup' approach (the
copy of Duff's rc I have sources a file, but it's moderately old).

 Interestingly, one of the entries in the BUGS section is
	It's too slow and too big.
(as well as
	There should be a way to match patterns against whole lists
	rather than just single strings.
which I think some people here have wanted in the past.)

	- cks

Re: Interesting things from the Plan 9 rc manpage

[Scott Schwartz]

|  The manual page doesn't have a FILES section, so I don't know if the
| Plan 9 rc has abandoned the 'source a file on startup' approach (the
| copy of Duff's rc I have sources a file, but it's moderately old).

Other manpages mention rcmain, so that's probably still in use.

|  Interestingly, one of the entries in the BUGS section is
| 	It's too slow and too big.

You've used both: how does it compare to Byron's?

Re: Interesting things from the Plan 9 rc manpage

[Paul Haahr]

> I
> suspect that the claim that Plan 9 rc prompts only when reading
> from a terminal is inaccurate, and that if given no arguments
> it always prompts (unless given -I)

this makes sense, since the plan9 version of isatty() is likely
not to be correct, according to the documentation.

Re: Interesting things from the Plan 9 rc manpage

[James Matthew Farrow]

>   Date:	Tue, 27 Oct 1992 20:17:47 -0500
>   From:	byron@netapp.com (Byron Rakitzis)
>   Message-Id: <9210280117.AA25914@netapp.netapp.com>
>   To:	cks@hawkwind.utcs.toronto.edu, rc@hawkwind.utcs.toronto.edu
>   Subject: Re:  Interesting things from the Plan 9 rc manpage
>   
>           -s:     Print out exit status after any command where the
>                   status is non-null (false).
>   
>   This can be done with an appropriate fn prompt in my rc.

Surely this won't work for non-interactive files.  On Plan 9's, rc
does print the status when invoked non-interactively, I just checked. 

					Matty.
--
James Matthew Farrow                    | "For in that moment I beheld the ruin
matty@cs.su.OZ.AU                       | of my existence.  My world fell dark
Basser Department of Computer Science   | and my life became a shallow dream.
Sydney University - FAX: +61 2 692 3838 | `Odi et amo. Excrucior.'" - Tlindah

Re: Interesting things from the Plan 9 rc manpage

[Chris Siebenmann]

 Scott Schwartz asks about a performance comparison between
Duff's rc and Byron's. Unfortunately, I can't really give one;
I've only looked at Duff's rc for comparison purposes, never
for actual use (especially as it lacks a number of amenities
I use heavily, such as a prompt function). Duff's rc compiles
to a somewhat bigger binary on this machine, and seems to start
up new shells a bit slower. Contributions of benchmarks will
produce more extensive measurements for the curious; I can't
think of any good ones.

 The -I option is mentioned in the mk manpage, which says that
it runs recipies by supplying them as standard input to
'rc -e -I' (-e is omitted if errors are being ignored). I
suspect that the claim that Plan 9 rc prompts only when reading
from a terminal is inaccurate, and that if given no arguments
it always prompts (unless given -I); that would explain the
need for it and the mention in mk's manpage. Anyone know Tom Duff
well enough to send him email asking about it?

	- cks

Re: Interesting things from the Plan 9 rc manpage

[Chris Siebenmann]

 The Plan 9 rc appears to keep plain environment variables in
the environment, and not parse them out; however, it does scan
the environment on startup to detect and parse function defenitions.

	- cks

Re: Interesting things from the Plan 9 rc manpage

[Jeremy Fitzhardinge]

Paul Haahr bubbles:
> > A new process would share the namespace of its parent, including /env,
> > so there's no work that needs to be done by any party.
> 
> yes, but a shell typically reads its entire environment on startup, and
> all those readdir(), open(), read(), and close() operations can't be free.
> on the other hand, if they don't cache the environment in the shell,
> every reference to an environment variable has to do 3 system calls
> (open, read, close), which is painful in my mind, but maybe rob's right
> when he says you shouldn't worry about system call overhead.
> 
> thinking about it, they probably have to use the latter approach, because
> otherwise you can't take advantage of the sharing of environments between
> processes that plan 9 offers.

Despite Pike's well known resistance to memory mapped files, this looks
like at least one pretty good application for them.  Really, that's
what segattach() is, but it has its own special name-space (the class),
rather than going through the filesystem namespace.  True, that's not the
intent, but it loses generality to be otherwise.  Are we off topic yet?

> anyway, this is all idle speculation.

Fun, isn't it?  Need something to fill a mailbox while people stop arguing about
job control in es.

	J

-- 
jeremy@sw.oz.au ph:+61 2 698 2322-x122 fax:+61 2 699 9174
While the earth dies dreaming, I lie screaming.

Re: Interesting things from the Plan 9 rc manpage

[Paul Haahr]

> A new process would share the
> namespace of its parent, including /env, so there's no work that needs
> to be done by any party.

yes, but a shell typically reads its entire environment on startup, and
all those readdir(), open(), read(), and close() operations can't be free.
on the other hand, if they don't cache the environment in the shell,
every reference to an environment variable has to do 3 system calls
(open, read, close), which is painful in my mind, but maybe rob's right
when he says you shouldn't worry about system call overhead.

thinking about it, they probably have to use the latter approach, because
otherwise you can't take advantage of the sharing of environments between
processes that plan 9 offers.

anyway, this is all idle speculation.

Re: Interesting things from the Plan 9 rc manpage

[Jeremy Fitzhardinge]

Chris Siebenmann bubbles:
>  Since Plan 9 implements the environment as a filesystem (a single
> directory) it wouldn't surprise me if it takes a while to fire up an
> rc if you have lots of functions or environment variables.

I can't see why that would be a problem.  A new process would share the
namespace of its parent, including /env, so there's no work that needs
to be done by any party.  If a new environment needs to be set up, then
perhaps there is more work.  I suppose an 'rc' would tend to be started with
rfork(RFENVG) (meaning "use a copy of the parent's env, but don't share
changes), so that may take more time.

> When I saw Pike demonstrating 8 1/2 (and when I saw it running on a
> 386 portable), I don't think window creation took that long, although
> 8 1/2 can hide shell startup delay if it wants to be clever.

Pike's claim has always been that a window started in 8 1/2 perceptually
instantaneously.  I always assumed that means that your shell puts a
prompt up pretty quickly after that.  Type-ahead helps if your shell is
slowish to start up.
 
>  The Labs style seems to tend towards a certain sparseness of
> environment, so it may have been considered OK by most people.

Sparse, but quick.

	J

Re: Interesting things from the Plan 9 rc manpage

[Chris Siebenmann]

 Since Plan 9 implements the environment as a filesystem (a single
directory) it wouldn't surprise me if it takes a while to fire up
an rc if you have lots of functions or environment variables. When
I saw Pike demonstrating 8 1/2 (and when I saw it running on a
386 portable), I don't think window creation took that long, although
8 1/2 can hide shell startup delay if it wants to be clever.

 The Labs style seems to tend towards a certain sparseness of
environment, so it may have been considered OK by most people.

	- cks

Re: Interesting things from the Plan 9 rc manpage

[Paul Haahr]

> It's too slow and too big.

testimony i've heard from a friend at the labs is that the startup time is
painful.  we speculated at the time that it was due to the way the environment
is treated on plan9 combined with the use of rcmain.  as i remember, on the
gnots, startup time was >1sec, reliably.  (this is all hearsay, folks, so
take it with a grain of salt.)

Re: Interesting things from the Plan 9 rc manpage

[noel]

    From:	byron@netapp.com (Byron Rakitzis)

            It's too slow and too big.

    I think that's just a Bell Labs pissing contest. Over there your macho-
    ness as a programmer is measured in inverse proportion to the number
    of lines of code you produce for a given task. My money says Duff's rc
    is smaller and faster than any than ksh, bash, etc. :-)

i am glad that you, Byron, adhere to these lofty ideals.

Re: Interesting things from the Plan 9 rc manpage

[noel]

    From:	byron@netapp.com (Byron Rakitzis)

            It's too slow and too big.

    I think that's just a Bell Labs pissing contest. Over there your macho-
    ness as a programmer is measured in inverse proportion to the number
    of lines of code you produce for a given task. My money says Duff's rc
    is smaller and faster than any than ksh, bash, etc. :-)

and what a FINE measure of a programmer's competence!

Re: Interesting things from the Plan 9 rc manpage

[Byron Rakitzis]

        -s:     Print out exit status after any command where the
                status is non-null (false).

This can be done with an appropriate fn prompt in my rc.

        -I:     Do not run interactively, regardless of whether or
                not standard input is attached to a terminal.

This can be done with "rc /dev/tty". What do they use this option
for anyway?

        It's too slow and too big.

I think that's just a Bell Labs pissing contest. Over there your macho-
ness as a programmer is measured in inverse proportion to the number
of lines of code you produce for a given task. My money says Duff's rc
is smaller and faster than any than ksh, bash, etc. :-)

(Though I would not be surprised if an implementation of rc that did
not lazily parse functions from the environment were perceived as being
slow on startup. This was a key optimization in my implementation.)