[9fans] How to move to rc from sh/bash

[9fans] How to move to rc from sh/bash

[Hongzheng Wang]

Hi all,

Since I was used to sh/bash in Linux, the default shell of Plan9 rc
seems not so convenient for me at first.  After learning some
illustrated differences between these two shell in the document [1]
and also the manpage of rc, I obtained some knowledge of rc and can do
some nontrivial things with it.  But I still feel some necessary,
powerful usages are lacked.  Specifically, I have questions as
follows:
1. Is it possible to do command line edit in rc?
That is, in bash, both emacs and vi like keybindings can be used
(thanks to readline library).  But in rc, I have not noticed that yet.
 As a result, some basic usuages of a shell, such as recalling the
previously executed commands, have to be done by mouse (snarf and
paste).

2. In non-interactive use (script programming), what's the main
advantages of rc over sh/bash?
Just like other utitlies, say sam and acme, provided by Plan9, I
believe rc should also have outstanding features.  Could you please
point them out?

Thank you all in advance.

[1] http://plan9.bell-labs.com/wiki/plan9/Unix_to_Plan_9_command_translation/index.html

--
HZ

Re: [9fans] How to move to rc from sh/bash

[mattmobile]

Groundhog day

I like new users I really do but this is getting silly

try reading the archives from LAST WEEK !!!!!

"what are the main benefits of your system over the ones you don't use"
is harder to answer

Re: [9fans] How to move to rc from sh/bash

[Hongzheng Wang]

Hi,

Because I can almost always find some new and interesting things in
Plan9's equivalent implements, eg the unicode support of Plan9's troff
and Sam's structural regexp, I think there may be such things in rc.
Further, I think every system has its own idioms and habits and users
must know them to make full use of it.  But, frankly, I have not
discovered the outstanding features of rc.  So I post the previous
question and hope to learn them, which perhaps are not well documented
usually.

Well, such a post may disturb you.  I'm sorry for that.

On Feb 9, 2008 4:01 PM,  <mattmobile@proweb.co.uk> wrote:
> Groundhog day
>
> I like new users I really do but this is getting silly
>
> try reading the archives from LAST WEEK !!!!!
>
> "what are the main benefits of your system over the ones you don't use"
> is harder to answer
>
>
>



--
HZ

Re: [9fans] How to move to rc from sh/bash

[mattmobile]

I started to list my favourite features (procedures, splitting, pattern
matching, case) of rc, but I was just replicating the man page.
I like rc because I can use it and understand scripts I haven't written,
it is surprise free.
I've also recently started making more use of signals.

I spawn firefox to grab it's output with inferno via vnc but sometimes
the page never finishes loading so I have to kill it something like this :

fn sigalrm {
    kill_firefox_sleep_and_screengrab
}

sleep 200 && kill -ALRM $pid
firefox $url &
screengrab_when_appropriate &
wait
kill -ALRM $pid

Re: [9fans] How to move to rc from sh/bash

[erik quanstrom]

> 1. Is it possible to do command line edit in rc?
> That is, in bash, both emacs and vi like keybindings can be used
> (thanks to readline library).  But in rc, I have not noticed that yet.
>  As a result, some basic usuages of a shell, such as recalling the
> previously executed commands, have to be done by mouse (snarf and
> paste).

command line editing is provided by acme in the case of win, or
rio(1) directly.  not hold mode entered by typing <esc>.

> 2. In non-interactive use (script programming), what's the main
> advantages of rc over sh/bash?

tom duff's original paper is in /sys/doc/rc.ps.  i don't think i can
make a better argument for rc than that.  personally, i think the
regularized grammer and quoting pay big dividends.  rc is also
small.  it's not hard to understand the virtual machine its built
around.  but you'll need to decide for your self.

- erik

Re: [9fans] How to move to rc from sh/bash

[Hongzheng Wang]

Thank you for your information.  It is quite useful.  I will have a
browse for these documents first.

On Feb 9, 2008 5:00 PM, erik quanstrom <quanstro@quanstro.net> wrote:

> tom duff's original paper is in /sys/doc/rc.ps.  i don't think i can
> make a better argument for rc than that.  personally, i think the
> regularized grammer and quoting pay big dividends.  rc is also
> small.  it's not hard to understand the virtual machine its built
> around.  but you'll need to decide for your self.

--
HZ

Re: [9fans] How to move to rc from sh/bash

[Charles Forsyth]

this subject line reminds me:

i'm fed up on Linux (Ubuntu) with bash  messing up both file name matching
and 9term editing and i'd like to switch to p9p's rc.
(which twit decided that [A-Z] could ever be case-insensitive with a case-sensitive file store?)
is it just a matter of chsh (after changing /etc/shells)?
given my experience with Linux, that seems implausibly straightforward.
i tried googling for some a little while ago but without success.

Re: [9fans] How to move to rc from sh/bash

[Lluís Batlle]

The meaning of [A-Z], on a gnu system, depends on the locale used. The
letters between [A-Z] depend on the sorting order defined in the
locale, and I guess that's defined by language in unicode somehow; but
I don't know how much there is a decision by Unicode on that. For
example, in Catalan we have that [A-Z] array defined as
[aAbBcCdDeE...]. And imagine: [A-Z] doesn't include [a]. :)

Using "LANG=C" before evaluating any [A-Z] expression should give you
the usual C meaning of only capitals.

2008/2/9, Charles Forsyth <forsyth@terzarima.net>:
> this subject line reminds me:
>
> i'm fed up on Linux (Ubuntu) with bash  messing up both file name matching
> and 9term editing and i'd like to switch to p9p's rc.
> (which twit decided that [A-Z] could ever be case-insensitive with a case-sensitive file store?)
> is it just a matter of chsh (after changing /etc/shells)?
> given my experience with Linux, that seems implausibly straightforward.
> i tried googling for some a little while ago but without success.
>
>

Re: [9fans] How to move to rc from sh/bash

[Uriel]

On Feb 9, 2008 11:27 AM, Lluís Batlle <viriketo@gmail.com> wrote:
> The meaning of [A-Z], on a gnu system, depends on the locale used. The
> letters between [A-Z] depend on the sorting order defined in the
> locale, and I guess that's defined by language in unicode somehow; but
> I don't know how much there is a decision by Unicode on that. For
> example, in Catalan we have that [A-Z] array defined as
> [aAbBcCdDeE...]. And imagine: [A-Z] doesn't include [a]. :)

Histerical!

Locales keep getting better and better the more I learn about them...
think of all the jobs that have been created thanks to them, I bet Mr
bs would love to have invented them!

uriel

Re: [9fans] How to move to rc from sh/bash

[Charles Forsyth]

> The meaning of [A-Z], on a gnu system, depends on the locale used. The
> letters between [A-Z] depend on the sorting order defined in the
> locale,  ...

> Using "LANG=C" before evaluating any [A-Z] expression should give you
> the usual C meaning of only capitals.

i know.  i want out.

Re: [9fans] How to move to rc from sh/bash

[geoff]

`LANG=C' cures a number of ills in modern Gnuware, including ls -l
output.  In effect, it requests traditional Unix behaviour rather than
this week's Linux behaviour, so it's a handy general-purpose
prophylactic.

Re: [9fans] How to move to rc from sh/bash

[Anthony Sorace]

On Feb 9, 2008 5:11 AM, Charles Forsyth <forsyth@terzarima.net> wrote:

> is it just a matter of chsh (after changing /etc/shells)?

It is, or at least can be. If you've got the tools installed at any
non-standard location, you have to make sure $PLAN9 is set somewhere
before your shell is started (as opposed to on login). I've considered
creating an rc with a built-in default rcmain to avoid this
requirement on systems I don't control.

Re: [9fans] How to move to rc from sh/bash

[Gorka Guardiola]

On Feb 9, 2008 8:53 AM, Hongzheng Wang <wanghz@gmail.com> wrote:
> Hi all,
>
> 2. In non-interactive use (script programming), what's the main
> advantages of rc over sh/bash?

Things I like of rc:

In both interactive and non-interactive, spaces do not bite you in rc.

in bash

if [ $bla -eq $otherbla ] ; fi endif... ahhh, I can´t remember the
syntax and get the spaces wrong,
never know if I need endif or fi or...

if ( command ) {
}

I don´t need to remember spaces, or contrived grammar.

Also the operator ^ and the fact that it is distributive is really powerful.
Someone else said it, only one quoting simbol
(what does " bla \$e'o" do on bash?, I just invented it, but every time I see
double qoutes I start trembling)

The most important thing is that it is *simple*, it doesn´t have any feature
someone may have thought a shell may need because they didn´t know how
to use sed. It only has a well thought subset of complete features.
-- 
- curiosity sKilled the cat

Re: [9fans] How to move to rc from sh/bash

[Pietro Gagliardi]

On Feb 10, 2008, at 11:59 AM, Gorka Guardiola wrote:

> On Feb 9, 2008 8:53 AM, Hongzheng Wang <wanghz@gmail.com> wrote:
>> Hi all,
>>
>> 2. In non-interactive use (script programming), what's the main
>> advantages of rc over sh/bash?
>
> Things I like of rc:
>
> In both interactive and non-interactive, spaces do not bite you in rc.
>
> in bash
>
> if [ $bla -eq $otherbla ] ; fi endif... ahhh, I can´t remember the
> syntax and get the spaces wrong,

The proper is

if [ $bla -eq $otherbla ]; then
	:
fi

The advantage of rc is that that : is not necessary!

Oh, and let's not forget what happens when bla or otherbla is nil! In  
rc,
	if (~ $bla $otherbla) { }
is all that is needed - no hooks.
>
> Someone else said it, only one quoting simbol
> (what does " bla \$e'o" do on bash?, I just invented it, but every  
> time I see
> double qoutes I start trembling)

It produces the string ' bla$e''o' in rc syntax. The one thing I like  
about two quoting styles  in the Bourne shell is that I can use  
escape sequences. The one thing I dislike about bash is that bash  
fucks up this quote system.
>

And here is my 2 cents:

- List objects are STANDARD (bash/kornshell arrays are not)
	x=(a b c)
- The seq statement is standard
	for (i in `{seq 1 10}) echo $i
- Removable functions
	fn x { echo 4 }
	fn x
	x=4
- >[] piping syntax is much more intuitive
- |[2] to pipe arbitrary file descriptors. One time, to skim through  
errors from gcc to find out if I had mistyped a member of a struct, I  
had to do
	gcc a_file_in_my_os.c 2>&1 | grep member
   In rc:
	8c a_file_in_my_os.c |[2] grep member
- Empty condition bodies! while(){echo y} is the yes command. It's  
much more terse.
- aux/getflags is faster than while getopt (no loop involved)
	My next plan is to rewrite all of /rc/bin to use aux/getflags. Any  
objections?
- The trap statement is gone - goodbye confusing hooks and no way of  
telling signal 1 from a command/function called 1
	Instead, you define functions sigterm and sigkill (I think)

And what I dislike:
- >[2=] is not the same as >[2]/dev/null (some programs crash with  
the former

Re: [9fans] How to move to rc from sh/bash

[erik quanstrom]

> It produces the string ' bla$e''o' in rc syntax. The one thing I like
> about two quoting styles  in the Bourne shell is that I can use

it's not so much the number of quotes (there are three, by the way),
it's the complex rules.  for example:

	; /bin/bash
	$ x=1
	$ echo "$x"
	1
	$ echo '$x'
	$x
	$ echo `echo "\$x"`
	1				<- reparsing rule.
	$ echo "'$x'"
	'1'
	$ echo "'\$x'"
	'$x'
but
	$ echo `echo
> The proper is
>
> if [ $bla -eq $otherbla ]; then
> 	:
> fi
>
> The advantage of rc is that that : is not necessary!
>
> Oh, and let's not forget what happens when bla or otherbla is nil! In
> rc,
> 	if (~ $bla $otherbla) { }
> is all that is needed - no hooks.

that's actually a problem.  while ~ is nice, it only does shell matching.
what if you want regexp matching or test (aka on unix [) operators?
then you have exactly the same problem with missing variables.

> And what I dislike:
> - >[2=] is not the same as >[2]/dev/null (some programs crash with
> the former

this isn't a shell issue.  >[2=] closes fd 2.  it's not clear to me that
arbitrary plan 9 programs are expected to run without one of the
three fds they've been promised by convention.

- erik

Re: [9fans] How to move to rc from sh/bash

[Martin Neubauer]

* Pietro Gagliardi (pietro10@mac.com) wrote:
> - The seq statement is standard
> 	for (i in `{seq 1 10}) echo $i

Nope, seq is an external program (subject to the environment). On the other
hand, as Byron's rc is rather extinct by now, chances are if rc is available,
so is seq.

> - aux/getflags is faster than while getopt (no loop involved)
> 	My next plan is to rewrite all of /rc/bin to use aux/getflags. Any
> objections?

Well, that isn't so much about rc's advantages. Keep in mind though that
this would force getflags to be present whenever you need a shell script.
For most installations this isn't an issue, but for those running Plan 9
embedded it is. And with space constraints providing some of /rc/bin might
be reasonable, providing aux/getflags might not. Besides, if a script
doesn't use more than two or three different options getflags doesn't reduce
much complexity (if you aren't writing a new script). And concerning speed,
if command line parsing dominates the execution time I honestly wouldn't
bother.

> And what I dislike:
> - >[2=] is not the same as >[2]/dev/null (some programs crash with
> the former

I don't think it should be the same. Both are special cases for two
different operations.

But what's really great about rc:
% man bash | wc -l
    4898
% man rc | wc -l
     398
If I'd want to check the bash man page for some specific information,
chances are that I'm sound asleep before anything interesting comes up.

	Martin

Re: [9fans] How to move to rc from sh/bash

[erik quanstrom]

> Well, that isn't so much about rc's advantages. Keep in mind though that
> this would force getflags to be present whenever you need a shell script.
> For most installations this isn't an issue, but for those running Plan 9
> embedded it is. And with space constraints providing some of /rc/bin might
> be reasonable, providing aux/getflags might not.

i don't buy this argument.  if you're running plan 9 with rc & scripts, you
have many MB of ram and mmu and several MB of persistant storage.
it's hard to get small flash parts these days.  i can't see 64k mattering.

> Besides, if a script
> doesn't use more than two or three different options getflags doesn't reduce
> much complexity (if you aren't writing a new script). And concerning speed,
> if command line parsing dominates the execution time I honestly wouldn't
> bother.

i would think that the reason to do this would be for consistency.  i
don't know that that's a compelling argument.  but i can see the
attraction of all or nothing; it would be nice if either none of the
scripts used getflags or all of them did.

- erik

Re: [9fans] How to move to rc from sh/bash

[Martin Neubauer]

* erik quanstrom (quanstro@quanstro.net) wrote:
> i would think that the reason to do this would be for consistency.  i
> don't know that that's a compelling argument.  but i can see the
> attraction of all or nothing; it would be nice if either none of the
> scripts used getflags or all of them did.
>
> - erik

That's actually quite compelling to me. I'd be just in favour of some kind
of `lazy evaluation' (if some script needs to be changed, put in getflags;
ditto for new ones.) And I admit that if one is really tght pressed on space
(which might still happen nowadays, if not nearly as often than a couple of
years ago) it won't really matter havin to put in some effort to customise
what's in /bin/rc. I'm still amused by the argument that getflags is faster,
though.

	Martin

Re: [9fans] How to move to rc from sh/bash

[Pietro Gagliardi]

The only advantage to getflags is that we can say

	rcsrcipt -xy

instead of

	rcscript -x -y

which is why I use it in my 12 script.

On Feb 11, 2008, at 6:03 PM, Martin Neubauer wrote:

> * erik quanstrom (quanstro@quanstro.net) wrote:
>> i would think that the reason to do this would be for consistency.  i
>> don't know that that's a compelling argument.  but i can see the
>> attraction of all or nothing; it would be nice if either none of the
>> scripts used getflags or all of them did.
>>
>> - erik
>
> That's actually quite compelling to me. I'd be just in favour of
> some kind
> of `lazy evaluation' (if some script needs to be changed, put in
> getflags;
> ditto for new ones.) And I admit that if one is really tght pressed
> on space
> (which might still happen nowadays, if not nearly as often than a
> couple of
> years ago) it won't really matter havin to put in some effort to
> customise
> what's in /bin/rc. I'm still amused by the argument that getflags
> is faster,
> though.
>
> 	Martin
>

Re: [9fans] How to move to rc from sh/bash

[maht]

I call that a disadvantage, to me it looks like y is an argument to -x

If that's what getflags does, then I hope someone runs rm on it


"This is not LINUX! This is Plan 9. There are rules."


> The only advantage to getflags is that we can say
>
>     rcsrcipt -xy
>
> instead of
>
>     rcscript -x -y
>
> which is why I use it in my 12 script.

Re: [9fans] How to move to rc from sh/bash

[Federico G. Benavento]

you can't have multiple vars with the same verb, like the pull script
needs
% pull -c file0 -c file1
with getflags you loose file0

On Feb 20, 2008 12:04 PM, maht <mattmobile@proweb.co.uk> wrote:
> I call that a disadvantage, to me it looks like y is an argument to -x
>
> If that's what getflags does, then I hope someone runs rm on it
>
>
> "This is not LINUX! This is Plan 9. There are rules."
>



--
Federico G. Benavento

Re: [9fans] How to move to rc from sh/bash

[erik quanstrom]

getflags brings rc scripts in line with the argument parsing rules
from the standard plan 9 c maros ARGBEGIN{}ARGEND.

- erik

> I call that a disadvantage, to me it looks like y is an argument to -x
>
> If that's what getflags does, then I hope someone runs rm on it
>
>
> "This is not LINUX! This is Plan 9. There are rules."
>
>
> > The only advantage to getflags is that we can say
> >
> >     rcsrcipt -xy
> >
> > instead of
> >
> >     rcscript -x -y

Re: [9fans] How to move to rc from sh/bash

[maht]

well shoot me in the foot :>

I got frustrated with those in Limbo too


> getflags brings rc scripts in line with the argument parsing rules
> from the standard plan 9 c maros ARGBEGIN{}ARGEND.
>
> - erik
>
>
>> I call that a disadvantage, to me it looks like y is an argument to -x
>>
>> If that's what getflags does, then I hope someone runs rm on it
>>
>>
>> "This is not LINUX! This is Plan 9. There are rules."
>>
>>
>>
>>> The only advantage to getflags is that we can say
>>>
>>>     rcsrcipt -xy
>>>
>>> instead of
>>>
>>>     rcscript -x -y
>>>
>
>

Re: [9fans] How to move to rc from sh/bash

[Uriel]

> But what's really great about rc:
> % man bash | wc -l
>     4898
> % man rc | wc -l
>      398
> If I'd want to check the bash man page for some specific information,
> chances are that I'm sound asleep before anything interesting comes up.

It is more likely that the information you want is not even in the man
page, gnu man pages are severely crippled, and if you want the real
documentation you have to travel to info hell which is likely to
contain ten times as much (mis)information and be ten times harder to
browse.

And there you have the greatest innovation GNU has ever brought to
unix, in gnu systems I rarely even bother checking the docs, because
even random trial and error usually takes much less effort than
navigating the fetid info swamp.

uriel

Re: [9fans] How to move to rc from sh/bash

[Martin Neubauer]

* Uriel (uriel99@gmail.com) wrote:
> It is more likely that the information you want is not even in the man
> page, gnu man pages are severely crippled, and if you want the real
> documentation you have to travel to info hell which is likely to
> contain ten times as much (mis)information and be ten times harder to
> browse.
>
> And there you have the greatest innovation GNU has ever brought to
> unix, in gnu systems I rarely even bother checking the docs, because
> even random trial and error usually takes much less effort than
> navigating the fetid info swamp.
>
> uriel

Damn, I was just going to ignore that mess.