Re: [9fans] How to move to rc from sh/bash
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
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
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 <[EMAIL PROTECTED]> 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
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
* Uriel ([EMAIL PROTECTED]) 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.
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
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 ([EMAIL PROTECTED]) 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
* erik quanstrom ([EMAIL PROTECTED]) 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
> 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
* Pietro Gagliardi ([EMAIL PROTECTED]) 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
> 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
On Feb 10, 2008, at 11:59 AM, Gorka Guardiola wrote: On Feb 9, 2008 8:53 AM, Hongzheng Wang <[EMAIL PROTECTED]> 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
On Feb 9, 2008 8:53 AM, Hongzheng Wang <[EMAIL PROTECTED]> 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
`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
> 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
On Feb 9, 2008 11:27 AM, Lluís Batlle <[EMAIL PROTECTED]> 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
On Feb 9, 2008 5:11 AM, Charles Forsyth <[EMAIL PROTECTED]> 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
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 <[EMAIL PROTECTED]>: > 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
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
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 <[EMAIL PROTECTED]> 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
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
> 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
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, <[EMAIL PROTECTED]> 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
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
[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/plan9/Unix_to_Plan_9_command_translation/index.html -- HZ