[9fans] rc shell UNIX port repository
Ciprian Dorin, Craciun
I'm a new (1 week) user of the rc shell (I want to migrate from
the Sh/Bash and their offsprings to rc after a lot of pain and misery
with them). :) And so far I like the rc look-and-feel (by look I mean
syntax and by feel I mean semantics.) as their quite minimal and with
just the right functionality. :)
So back to the point: I'm using rc-1.7.1 UNIX port of the rc
shell, downloaded from:
http://www.libra-aries-books.co.uk/software/download/rc/rc-1.7.1.tar.gz
and during my initial trials, I've found quite a few bugs related
with the `-e` (exit shell on non-0 exit code), which I've tried (and
think I've managed) to solve.
Now I'm trying to contribute back to the community, and I've sent
an email to Tig Goodwin (at t...@star.le.ac.uk), which the mail server
rejected (it seems that the email is not valid any more). Then I've
sent an email to Byron Rakitzis (at by...@netapp.com), which worked
but no reply yet (maybe I'm on the to-do list. :) )
So my questions are:
* who is maintaining the UNIX port of rc shell? (is it still
Tig?) (if so what's the email address?)
* is there a development repository for the source code?
* is there a mailing list dedicated to the rc shell? (either
native or UNIX ported one?)
* are there any unit-tests available for the rc shell? (because I
want to test my patches of not breaking something;)
Thanks,
Ciprian.
P.S.: In my migration from Sh/Bash I've ended up deciding between
two candidates: scsh (Scheme Shell) (which is quite powerfull, being a
full R5RS Scheme implementation, with process management support, but
I've found a few rough edges (mainly related with error handling), and
it's quite heavy weight implementation with a large (in file number)
footprint), and rc (quite lightweight (only one executable statically
linked)).
So are there any other worthy alternatives?
Charles Forsyth
>Tig?) (if so what's the email address?)
if it's Byron Rakitzis' rc, it's not a `port' to UNIX of Plan 9's rc,
but an independent implementation, with differences in the language,
although it's quite usable and both versions are lightweight compared to
the current sh implementations.
Ciprian Dorin, Craciun
Yes, it's Byron's reimplementation. (I've misused the `port` word.)
But then rc's port to UNIX is the one from `plan9port` project?
(http://swtch.com/plan9port)
(And if so, can I build and use it independent of the rest of the tools?)
Thanks,
Ciprian.
Charles Forsyth
building it standalone will be hard, although you can reduce the surrounding source
considerably, since it uses mainly or only lib9 (plan 9 libc).
a little experiment suggests that once built,
you might get by with only rc's executable and its rcmain.
you'll need to change rcmain not to refer to
$PLAN9/bin/9, but that needs only a little text editing.
Frederik Caulier
install 9base [0] which is part of the Suckless project.
[0] http://tools.suckless.org/9base
erik quanstrom
> Tig?) (if so what's the email address?)
> want to test my patches of not breaking something;)
i believe byron's rc comes with a "make tripping", but of course
that tests byron's varient of the language.
i've been using byron's rc since before 1990 on unix. it's handy
to have around if p9p rc gets broken. it is acceptable for my
occasional interactive use. i use linux seldom these days.
i'd be interested in your patches, though.
- erik
Axel Belinfante
for quite some years on unix, although effectively I did not use
most of its more advanced features.
"Es is an extensible shell. The language was derived from the Plan 9
shell, rc, and was influenced by functional programming languages,
such as Scheme, and the Tcl embeddable programming language. This
implementation is derived from Byron Rakitzis's public domain
implementation of rc.
[...]
"
quote above comes from
http://code.google.com/p/es-shell/source/browse/trunk/README
http://hawkwind.cs.toronto.edu:8001/mlists/es.html
http://code.google.com/p/es-shell
Axel.
On Dec 6, 2009, at 8:52 , Ciprian Dorin, Craciun wrote:
> P.S.: In my migration from Sh/Bash I've ended up deciding between
> two candidates: scsh [...] and rc [...]
weakish
wrote:
> Â Â Now I'm trying to contribute back to the community, and I've sent
> an email to Tig Goodwin (at t...@star.le.ac.uk), which the mail server
> rejected (it seems that the email is not valid any more).
Have you tried this email to contact Tim Goodwin: info@libra-aries-
books.co.uk
Currently I'm not aware of any mail-list/code-repository dedicated to
rc shell.
Ciprian Dorin, Craciun
Thanks, I'll try to contact him at that address...
Unfortunately after playing a little bit more with rc, and trying
it's syntax and semantics to the limit, I've also found other nasty
bugs (some of which I've fixed, other I was not able to do so)...
So for the moment I'm back to Bash... (But I'm planning on
implementing an ASM like language and associated virtual machine, that
would allow UNIX "glue" programs to be written.)
Ciprian.
~~~~
By the way, what is the expected outcome of the following snippet
of code when the `-e` (exit on non-0 exit code) is on:
{ echo 1 ; false ; echo 2 } || echo 3
Case a) it should print `1` and exit because the false in the
middle of the block just failed;
Case b) it should print `1`, and then `2`, because `false` is
inside a block that is part of a `||` command;
Case c) it should print `1`, and then `3`, because `false` has
stopped the evaluation of the block, and made the entire block exit
code be `1`.
I would prefer case 1, (treat any non-zero exit command like an
abnormal exception in the script), but with the addition of a "block
return" construct that would allow me to exit only from the current
block, like (I'm calling the "block return" keyword "block_return"
{
mkdir ./downoads || block_return 1
pushd ./downloads # exception could happen, but only in race conditions
wget http://somesite.com/somefiles.tar || block_return 2
tar -x ./somefiles.tar || block_return 3
rm ./somefiles.tar # again it should normally just work
} || echo "there was some error"^$status
erik quanstrom
> it's syntax and semantics to the limit, I've also found other nasty
> bugs (some of which I've fixed, other I was not able to do so)...
what nasty bugs? could you give some specifics.
> By the way, what is the expected outcome of the following snippet
> of code when the `-e` (exit on non-0 exit code) is on:
>
> { echo 1 ; false ; echo 2 } || echo 3
>
> Case a) it should print `1` and exit because the false in the
> middle of the block just failed;
> Case b) it should print `1`, and then `2`, because `false` is
> inside a block that is part of a `||` command;
> Case c) it should print `1`, and then `3`, because `false` has
> stopped the evaluation of the block, and made the entire block exit
> code be `1`.
that's not a bug. -e is only evaluated at the end of a full rc
production. in yiour case, there is only one production and
it $status is '' (true) at the end of it. since echo 3 sets status
to true.
- erik
erik quanstrom
> production. in yiour case, there is only one production and
> it $status is '' (true) at the end of it. since echo 3 sets status
> to true.
sorry. i ment /echo 2/ sets status to true.
- erik
Ciprian Dorin, Craciun
>> Unfortunately after playing a little bit more with rc, and trying
>> it's syntax and semantics to the limit, I've also found other nasty
>> bugs (some of which I've fixed, other I was not able to do so)...
>
> what nasty bugs? could you give some specifics.
One for example (I think it is a bug, but maybe in the semantics
you've described it's not):
* again if we're using `-e`, and inside a function we write `fn
dosomething { echo 1 ; false ; echo 2 ; return 0 ; }`
* if we run `dosomething` it shall output only `1`, as the false
breaks the execution;
* but if we run `dosomething || echo 3`, we see `1 2` outputed,
because the false is not exiting the shell as the invocation of the
function is part of a `||` statement;
But undoubtedly, the following is a bug (I have an array and want
to display all the elements on a single line, wrapped inside quotes,
and everything with a prefix and a suffix):
~~~~
application__erl_files__short=(
a.erl
b.erl
c.erl
)
application__erl_files__long=(
/home/ciprian/workbench/vel/a.erl
/home/ciprian/workbench/vel/b.erl
/home/ciprian/workbench/vel/c.erl
)
ifs='\n' echo ' erl files = ('^`{ echo -n
'`'^$application__erl_files__short^'`' }^')'
ifs='\n' echo ' erl files = ('^`{ echo -n
'`'^$application__erl_files__long^'`' }^')'
~~~~
it displays:
~~~~
erl files = (`a.erl` `b.erl` `c.erl`)
erl files = (`/home/cipria) erl files = (/workbe) erl files =
(ch/vel/a.erl` `/home/cipria) erl files = (/workbe) erl files =
(ch/vel/b.erl` `/home/cipria) erl files = (/workbe) erl files =
(ch/vel/c.erl`)
~~~~
See the second line of the output. It's wrong. I think there is a
buffer overrun problem...
>> By the way, what is the expected outcome of the following snippet
>> of code when the `-e` (exit on non-0 exit code) is on:
>>
>> { echo 1 ; false ; echo 2 } || echo 3
>>
>> Case a) it should print `1` and exit because the false in the
>> middle of the block just failed;
>> Case b) it should print `1`, and then `2`, because `false` is
>> inside a block that is part of a `||` command;
>> Case c) it should print `1`, and then `3`, because `false` has
>> stopped the evaluation of the block, and made the entire block exit
>> code be `1`.
>
> that's not a bug. -e is only evaluated at the end of a full rc
> production. in yiour case, there is only one production and
> it $status is '' (true) at the end of it. since echo 3 sets status
> to true.
>
> - erik
Even though I understand your reasoning, I see `-e` more as a
"accept no errors from commands, and treat any non-0-exit code as an
unhandled exception, except :) if its part of an if, &&, or ||
construct". (I see it as an equivalent for try-throw-except...)
Ciprian.
erik quanstrom
> you've described it's not):
> * again if we're using `-e`, and inside a function we write `fn
> dosomething { echo 1 ; false ; echo 2 ; return 0 ; }`
> * if we run `dosomething` it shall output only `1`, as the false
> breaks the execution;
> * but if we run `dosomething || echo 3`, we see `1 2` outputed,
> because the false is not exiting the shell as the invocation of the
> function is part of a `||` statement;
not a bug. x || y is "line" in the rc grammar. "x;" is als o a line.
-e is only evaluated at the end of lines.
> But undoubtedly, the following is a bug (I have an array and want
> to display all the elements on a single line, wrapped inside quotes,
> and everything with a prefix and a suffix):
[...]
> ifs='\n' echo ' erl files = ('^`{ echo -n
> '`'^$application__erl_files__short^'`' }^')'
> ifs='\n' echo ' erl files = ('^`{ echo -n
> '`'^$application__erl_files__long^'`' }^')'
> ~~~~
> it displays:
> ~~~~
> erl files = (`a.erl` `b.erl` `c.erl`)
> erl files = (`/home/cipria) erl files = (/workbe) erl files =
> (ch/vel/a.erl` `/home/cipria) erl files = (/workbe) erl files =
> (ch/vel/b.erl` `/home/cipria) erl files = (/workbe) erl files =
> (ch/vel/c.erl`)
> ~~~~
not a bug. you set the ifs to '\' and 'n'. since the first
list doesn't have any ns in it, it doesn't get split.
to get a newline in rc you need
ifs='
' cmd
- erik
Ciprian Dorin, Craciun
>> One for example (I think it is a bug, but maybe in the semantics
>> you've described it's not):
>> * again if we're using `-e`, and inside a function we write `fn
>> dosomething { echo 1 ; false ; echo 2 ; return 0 ; }`
>> * if we run `dosomething` it shall output only `1`, as the false
>> breaks the execution;
>> * but if we run `dosomething || echo 3`, we see `1 2` outputed,
>> because the false is not exiting the shell as the invocation of the
>> function is part of a `||` statement;
>
> not a bug. x || y is "line" in the rc grammar. "x;" is als o a line.
> -e is only evaluated at the end of lines.
I see... (But I keep my opinion about the overly-complex `-e` semantics...)
>> But undoubtedly, the following is a bug (I have an array and want
>> to display all the elements on a single line, wrapped inside quotes,
>> and everything with a prefix and a suffix):
> [...]
>
>> ifs='\n' echo ' erl files = ('^`{ echo -n
>> '`'^$application__erl_files__short^'`' }^')'
>> ifs='\n' echo ' erl files = ('^`{ echo -n
>> '`'^$application__erl_files__long^'`' }^')'
>> ~~~~
>> it displays:
>> ~~~~
>> erl files = (`a.erl` `b.erl` `c.erl`)
>> erl files = (`/home/cipria) erl files = (/workbe) erl files =
>> (ch/vel/a.erl` `/home/cipria) erl files = (/workbe) erl files =
>> (ch/vel/b.erl` `/home/cipria) erl files = (/workbe) erl files =
>> (ch/vel/c.erl`)
>> ~~~~
>
> not a bug. you set the ifs to '\' and 'n'. since the first
> list doesn't have any ns in it, it doesn't get split.
> to get a newline in rc you need
> ifs='
> ' cmd
>
> - erik
???? So then how can I say on the same line
ifs=<<new-line-character>> ???? (I know about the actual newline
between the quotes, but I think it's a very ugly syntax, especially
when it involves indentation...)
erik quanstrom
> ifs=<<new-line-character>> ???? (I know about the actual newline
> between the quotes, but I think it's a very ugly syntax, especially
> when it involves indentation...)
nl='
'
ifs=$nl cmd
- erik