Re: [9fans] v8 shell

Re: [9fans] v8 shell

[Richard C Bilson]

> $ ls() {
> 	builtin ls "$@" | cat
> }
> $ ls
> -bash: builtin: ls: not a shell builtin
> $

Try using "command" instead of "builtin".

Re: [9fans] v8 shell

[rog]

> Try using "command" instead of "builtin".

oh, i see.

i guess that would be necessary in a shell with 64 builtin commands,
many of which have actual command equivalents.

rc has, what, 10?

Re: [9fans] v8 shell

[boyd, rounin]

> > $ ls() {
> > builtin ls "$@" | cat
> > }
> > $ ls
> > -bash: builtin: ls: not a shell builtin
> > $
>
> Try using "command" instead of "builtin".

that is not how builtin works.  builtin works like this:

    cd()
    {
        builtin cd $1 && PS1="`pwd` % "
    }

now 'command' that is an impressive piece of logic.

Re: [9fans] v8 shell

[boyd, rounin]

> The biggest two things that V8 shell has that the v7 shell doesn't
> is shell functions and appending command lines to a history file.
> I'm sure there were other changes, but these are the one I miss.

you forget 'builtin' and 'whatis'.  as rob said 'programming the inputs'.

so the 8th Ed shell had functions:

     func()
     {

          ....

     }

$0 was the name of the script.  $* was the rest of the args to the function.
it return 0 or non zero iirc, but my 9th Ed manual is in .au

whatis & builtin were _essential_, so you could write a function like cd, so
it could use 'builtin' so you could have a function called 'cd' and it would do
what you wanted.

that sysVile 'type' thing was an abortion.

as Yes said:

    as one with the knowledge and power of the source

i was bored and had the source to sVr2 so i coded it up.

these links maybe interesting:

    http://www.std.org/~shand/jjm/mail/compact.html
    http://www.std.org/~shand/jjm/mail/flint.html

# 248 622

-- Susan

Re: [9fans] v8 shell

[Taj Khattra]

On Thu, Nov 13, 2003 at 04:08:27PM +0200, Anastasopoulos S wrote:
> There was a discussion recently about the v8 shell, however there isn't
> any documentation about the features it had or ...

see the link http://www.in-ulm.de/~mascheck/bourne/ which was posted
here a few days ago

-taj

Re: [9fans] v8 shell

[rob pike, esq.]

i fought fairly hard to get the key features of the v8 shell adopted
into posix.  these included exportable functions and output from
commands like whatis that could be read as input.  but i didn't fight
hard enough because i didn't fight at every single committee meeting.
as soon as i stopped going, the changes were reverted ("thank god he's
gone").  the experience soured me for life on contributing to
standards committees.

for example, the 'builtin' trick in modern shells comes out of the v8
shell but the other half is missing.

korn shell or bash:

	$ type cd
	cd is a shell builtin
	$

v8 shell:

	$ whatis cd
	builtin cd
	$

see the difference? the latter is executable code.  why was it important
to `fix' this in the committee?  bitterness rules.

maybe that's why rc happened.  probably was a factor.  i know i asked
td to design rc, but i also did the work in creating the v8 shell. i
don't really remember.

-rob

Re: [9fans] v8 shell

[George Michaelson]

>
> for example, the 'builtin' trick in modern shells comes out of the v8
> shell but the other half is missing.
>
> korn shell or bash:
>
> 	$ type cd
> 	cd is a shell builtin
> 	$
>
> v8 shell:
>
> 	$ whatis cd
> 	builtin cd
> 	$
>
> see the difference? the latter is executable code.  why was it important
> to `fix' this in the committee?  bitterness rules.

I found I had to set the PS1 and PS2 to be known shell comment markers to get
things work work sanely when I played with this in shell a while back, and even
then it wasn't very good. Its unfortunate that the $ is also a leadin to
variable expansion, if it was functionally more like ; or :; it would have made
it easier to snarf entire sequences of commands from screens.

>
> maybe that's why rc happened.  probably was a factor.  i know i asked
> td to design rc, but i also did the work in creating the v8 shell. i
> don't really remember.
>
> -rob

like many people, I haven't been able to face the terminal moraine of rc, to get
to the mountain tops behind it. If only there was a budget for clue, and a
market for selling it in this area.

-George


--
George Michaelson       |  APNIC
Email: ggm@apnic.net    |  PO Box 2131 Milton QLD 4064
Phone: +61 7 3367 0490  |  Australia
  Fax: +61 7 3367 0482  |  http://www.apnic.net

Re: [9fans] v8 shell

[rog]

> like many people, I haven't been able to face the terminal moraine of rc, to get
> to the mountain tops behind it. If only there was a budget for clue, and a
> market for selling it in this area.

erm, rc is dead easy...  much easier, in fact than the bourne shell
(let alone all those unix abortions).

the only (and crucial) thing that's really different is the fact that
variables are (single level) lists.  this means you're no longer at
the mercy of space-based tokenisation every time you use a $var
expansion.  more-or-less everything else boils down to sugary
syntactic differences.

rc makes for a much more reliable scripting language.

i can't really see why anyone would want to go back to the bourne
shell when it's so fundamentally error-prone.

Re: [9fans] v8 shell

[boyd, rounin]

> erm, rc is dead easy...  much easier, in fact than the bourne shell
> (let alone all those unix abortions).

from the luser point of view.

big feature of rc is that it has a yacc grammar.

bourne's shell and it's derivitives had no such thing.

Re: [9fans] v8 shell

[Douglas A. Gwyn]

boyd, rounin wrote:
> big feature of rc is that it has a yacc grammar.
> bourne's shell and it's derivitives had no such thing.

It wasn't implemented using YACC, but it certainly had
a grammar.

Re: [9fans] v8 shell

[Charles Forsyth]

[-- Attachment #1: Type: text/plain, Size: 891 bytes --]

perhaps but it's not clear cut.
the bourne shell was quite tidy, but as with many hand-written
recursive descent implementations, it did cheat a few times.
i did do a yacc grammar for its language for a clone, based originally
on the BSTJ paper without sight of the code, but that grammar had to
be weakened in several places, with help from the scanner as i recall,
in order to handle `real' bourne shell scripts when i finally
had access to the bourne implementation and enough real shell scripts.
i'd be more precise but it must be a good 25 years or so
later, and i can't remember the details; not least because
i've moved on and i've got plenty of non-70's things to remember.
(that isn't to suggest that earlier things weren't much better
than some current `inventions', but that's perhaps not so
much a commendation of the old as
a condemnation of the self-styled `new'.

[-- Attachment #2: Type: message/rfc822, Size: 2406 bytes --]

From: "Douglas A. Gwyn" <DAGwyn@null.net>
To: 9fans@cse.psu.edu
Subject: Re: [9fans] v8 shell
Date: Mon, 17 Nov 2003 10:26:06 GMT
Message-ID: <qOudnaPaG6Ox4yiiRVn-hg@comcast.com>

boyd, rounin wrote:
> big feature of rc is that it has a yacc grammar.
> bourne's shell and it's derivitives had no such thing.

It wasn't implemented using YACC, but it certainly had
a grammar.

Re: [9fans] v8 shell

[Douglas A. Gwyn]

Charles Forsyth wrote:
> (that isn't to suggest that earlier things weren't much better
> than some current `inventions', but that's perhaps not so
> much a commendation of the old as
> a condemnation of the self-styled `new'.

What seems to happen a lot is that inventors of the "new"
are insufficiently familiar with the "old" to properly
evaluate what wins and what loses.  So they make the same
old mistakes in a new context.

Re: [9fans] v8 shell

[John Murdie]

On Fri, 2003-11-14 at 00:43, rog@vitanuova.com wrote:
> > like many people, I haven't been able to face the terminal moraine of rc, to get
> > to the mountain tops behind it. If only there was a budget for clue, and a
> > market for selling it in this area.
>
> erm, rc is dead easy...  much easier, in fact than the bourne shell
> (let alone all those unix abortions).
>
> the only (and crucial) thing that's really different is the fact that
> variables are (single level) lists.  this means you're no longer at
> the mercy of space-based tokenisation every time you use a $var
> expansion.  more-or-less everything else boils down to sugary
> syntactic differences.
>
> rc makes for a much more reliable scripting language.
>
> i can't really see why anyone would want to go back to the bourne
> shell when it's so fundamentally error-prone.

I agree with your conclusions, but I also like rc's use of \ for hiding
a new-line only, and rc's much simpler quoting rule - just one type of
quote ('), and double it for a literal quote. (The number of times I've
felt obliged to write a script with Bourne shell for portability to the
Linux world, only to get bogged down in quoted-quoted strings.) Ugh.

I always write rc shell scripts for my own use, these days - Plan 9 or
Unix. I find the minor differences between TD's original and Byron's
flattery are annoying, however. Will they ever be reconciled?

John A. Murdie
Department of Computer Science
University of York

Re: [9fans] v8 shell

[rog]

> I agree with your conclusions, but I also like rc's use of \ for hiding
> a new-line only, and rc's much simpler quoting rule - just one type of
> quote ('), and double it for a literal quote.

oh, i agree entirely - rc's syntax *is* much nicer, and features like:

	grep something /mnt/term/mail/fs/mbox/^(1 2 3 4)^/body

not to mention:

	tar c . | tee >{wc -c} | @{cd somewhere; tar x}

are a constant joy.

but really, i think they pale into insignificance behind the lists vs.
strings distinction.

i reckon you could build a shell with a syntax almost identical to the
bourne shell's, but that did rc-like lists, and it would still be a
great improvement.

Re: [9fans] v8 shell

[boyd, rounin]

> not to mention:
>
> tar c . | tee >{wc -c} | @{cd somewhere; tar x}
>
> are a constant joy.

yes, but you needed /dev/fd (at the time) and very few
systems did.

norman wilson worked out that you could get at the newly
allocated descriptor from some leftover in the u-area [index
into u.u_ofile iirc] and from knowing that you could write
/dev/fd as a driver, which meant no mods to the kernel.

i wrote one for SCO lunix and then stuck it into ultrix and
used it with byron's rc.  of course, the ultrix development
group wanted nothing to do with it, but it got released as a
'paper', back in '91 or so.

the driver was a page of code, most of that taken up
by a large copy-thing comment and a swath of #include's

Re: [9fans] v8 shell

[rog]

> yes, but you needed /dev/fd (at the time) and very few
> systems did.

actually, you can get away with named pipes, at moderate cost.
byron's rc could do this.

Re: [9fans] v8 shell

[boyd, rounin]

> actually, you can get away with named pipes, at moderate cost.
> byron's rc could do this.

yeah, that sounds right.

now that reminds me of some benchmark run against named
pipes and message queues.  it got dumped on my desk and
i was asked to comment.

now pipes had an almost 1:1 real to cpu time correlation and
were a bit slower.  message queues were another story; they
used less cpu time but the real time was _more_.  this had me
puzzled.

seems someone at USG had forgotten about sleep and wakeup
and had a timeout to kick the queues into action, greatly reducing
the cpu time but greatly _increasing_ the real time.

Re: [9fans] v8 shell

[Roman Shaposhnick]

On Fri, Nov 14, 2003 at 06:01:30PM +0000, rog@vitanuova.com wrote:
> > I agree with your conclusions, but I also like rc's use of \ for hiding
> > a new-line only, and rc's much simpler quoting rule - just one type of
> > quote ('), and double it for a literal quote.
>
> oh, i agree entirely - rc's syntax *is* much nicer, and features like:
>
> 	grep something /mnt/term/mail/fs/mbox/^(1 2 3 4)^/body
>
> not to mention:
>
> 	tar c . | tee >{wc -c} | @{cd somewhere; tar x}

  I myself praise rc as much as the next guy, but as far as
  "tee >{wc -c}" part goes you can do the same with bash
  nowadays:

        tee >(wc -c)

  that is.

Thanks,
Roman.

Re: [9fans] v8 shell

[Richard Miller]

> 	tar c . | tee >{wc -c} | @{cd somewhere; tar x}

Wow - I use <{cmd} a lot but I had never realised that >{cmd} works too.

What I do miss in rc (does any other shell do it?) is the ability to
open a read-write connection to a file.  For example you could test
webcookies(4) by doing something like:

<>[4]/mnt/webcookies/http { echo http://www.foo.baz >[1=4]; cat <[0=4] }

Because the webcookies protocol requires that you write the url and read back
the cookies on the same file descriptor, I can't see any way to do this in
the existing shell.

-- Richard

Re: [9fans] v8 shell

[Geoff Collyer]

Some versions of sh have <>, but it's not always documented.
The v7 and v9 shells parse <> and set a flag (IORDW), but
the flag is never honoured.

I suppose one could write a simple prefix command, taking a file name,
descriptor number, and command to run:

	rdwr /mnt/webcookies/http 4 'echo http://www.foo.baz >[1=4]; cat <[0=4]'

Re: [9fans] v8 shell

[Richard Miller]

> I suppose one could write a simple prefix command, taking a file name,
> descriptor number, and command to run:
>
> 	rdwr /mnt/webcookies/http 4 'echo http://www.foo.baz >[1=4]; cat <[0=4]'

Or generalise by adding a '-c command' option to syscall(1):

	syscall -c 'echo http://www.foo.baz >[1=3]; cat <[0=3]' open /mnt/webcookies/http 2

Then you could use it for other things, eg to execute a command as user none:

	syscall -c command write 3 none 4 >[3]/dev/user

Re: [9fans] v8 shell

[rog]

> 	syscall -c 'echo http://www.foo.baz >[1=3]; cat <[0=3]' open /mnt/webcookies/http 2

it's this kind of scenario that was one of the reasons
i put braced-blocks-as-values into the inferno shell.

then you can write the above as:

	syscall -c {
		echo http://www.foo.baz >[1=3]; cat <[0=3]
	} open /mnt/webcookies/http 2

and the shell still does your syntax checking for you.
it's not a difficult thing to do.

Re: [9fans] v8 shell

[Russ Cox]

> > 	tar c . | tee >{wc -c} | @{cd somewhere; tar x}
>
> Wow - I use <{cmd} a lot but I had never realised that >{cmd} works too.
>
> What I do miss in rc (does any other shell do it?) is the ability to
> open a read-write connection to a file.  For example you could test
> webcookies(4) by doing something like:
>
> <>[4]/mnt/webcookies/http { echo http://www.foo.baz >[1=4]; cat <[0=4] }
>
> Because the webcookies protocol requires that you write the url and read back
> the cookies on the same file descriptor, I can't see any way to do this in
> the existing shell.

i put this in byron's rc once but didn't bother
trying to convince anyone it was actually
useful on unix (especially since some more
magic was required to open unix domain
sockets transparently).

for lockstep protocols (one write, one read, ...)
you can use aux/rdwr.

	echo plan9.bell-labs.com mx | aux/rdwr /net/dns

there should be an option to silence the "> " prompts.

Re: [9fans] v8 shell

[Richard Miller]

> for lockstep protocols (one write, one read, ...)
> you can use aux/rdwr.

But not for webcookies.

One could use Mike Haertel's <[0=1] trick (which works for pipes)
if '>' opened with ORDWR instead of OWRITE.  But that change would
cause trouble in the (vanishingly rare?) case of files with
write-only access.

Re: [9fans] v8 shell

[a]

// I find the minor differences between TD's original and Byron's
// flattery are annoying, however. Will they ever be reconciled?

i can't speak to that, but what i'd really like to see instead is
just plan 9's compiled using rsc's port of the libs. there's a few
levels of tools dependancies, though, if i'm remembering right
from looking at that about two weeks ago.
ア

Re: [9fans] v8 shell

[boyd, rounin]

> The biggest two things that V8 shell has that the v7 shell doesn't
> is shell functions and appending command lines to a history file.
> I'm sure there were other changes, but these are the one I miss.

you forget 'builtin' and 'whatis'.  as rob said 'programming the inputs'.

so the 8th Ed shell had functions:

     func()
     {

          ....

     }

$0 was the name of the script.  $* was the rest of the args to the function.
it return 0 or non zero iirc, but my 9th Ed manual is in .au

whatis & builtin were _essential_, so you could write a function like cd, so
it could use 'builtin' so you could have a function called 'cd' and it would do
what you wanted.

that sysVile 'type' thing was an abortion.

as Yes said:

    as one with the knowledge and power of the source

i was bored and had the source to sVr2 so i coded it up.

these links maybe interesting:

    http://www.std.org/~shand/jjm/mail/compact.html
    http://www.std.org/~shand/jjm/mail/flint.html

# 248 622

-- Susan

Re: [9fans] v8 shell

[rog]

> whatis & builtin were _essential_, so you could write a function like cd, so
> it could use 'builtin' so you could have a function called 'cd' and it would do
> what you wanted.

there's a builtin command built in to bash, i discovered recently,
but it gets it so wrong... i wanted to write a shell function
to replace ls:

$ ls() {
	builtin ls "$@" | cat
}
$ ls
-bash: builtin: ls: not a shell builtin
$

they don't seem to have a clue.

Re: [9fans] v8 shell

[boyd, rounin]

> $ ls() {
> builtin ls "$@" | cat
> }
> $ ls
> -bash: builtin: ls: not a shell builtin
> $
>
> they don't seem to have a clue.

does it?  well, i shouldn't really be suprised.

hang on, i just re-read that and that would indicated the ls(1) is actually
coded into bash.  even for bash, that's a bit of a stretch [diabolical
liberty].

builtin is trivial.  using it with cd was the usual hack, rather than all
those dreadful PS1 string printf style formatting things.

builtin is a mix of quoting / eval / shift; you find builtin and then throw
it away and the parse/execution tree is the stuff that follows.

Re: [9fans] v8 shell

[Douglas A. Gwyn]

rog@vitanuova.com wrote:
> -bash: builtin: ls: not a shell builtin
> they don't seem to have a clue.

But in fact "ls" is *not* normally a shell builtin.

Re: [9fans] v8 shell

[boyd, rounin]

> The biggest two things that V8 shell has that the v7 shell doesn't
> is shell functions and appending command lines to a history file.
> I'm sure there were other changes, but these are the one I miss.

you forget 'builtin' and 'whatis'.  as rob said 'programming the inputs'.

so the 8th Ed shell had functions:

     func()
     {

          ....

     }

$0 was the name of the script.  $* was the rest of the args to the function.
it return 0 or non zero iirc, but my 9th Ed manual is in .au

whatis & builtin were _essential_, so you could write a function like cd, so
it could use 'builtin' so you could have a function called 'cd' and it would do
what you wanted.

that sysVile 'type' thing was an abortion.

as Yes said:

    as one with the knowledge and power of the source

i was bored and had the source to sVr2 so i coded it up.

these links maybe interesting:

    http://www.std.org/~shand/jjm/mail/compact.html
    http://www.std.org/~shand/jjm/mail/flint.html

# 248 622

-- Susan