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

This is a discussion on [9fans] How to move to rc from sh/bash - Plan9 ; 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 25

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

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

    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/plan...ion/index.html

    --
    HZ

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

    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



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

    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, 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

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

    > 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 .

    > 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


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

    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





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

    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 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

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

    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.


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

    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 :
    > 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.
    >
    >


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

    On Feb 9, 2008 5:11 AM, Charles Forsyth 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.

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

    On Feb 9, 2008 11:27 AM, LluÃ*s Batlle 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

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

    > 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.


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

    `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.


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

    On Feb 9, 2008 8:53 AM, Hongzheng Wang 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

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

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

    > On Feb 9, 2008 8:53 AM, Hongzheng Wang 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
    ****s 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


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

    > 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

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

    * 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


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

    > 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


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

    * 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


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

    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
    >



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

    > 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

+ Reply to Thread
Page 1 of 2 1 2 LastLast