On 3/13/07, Anthony Sorace <[EMAIL PROTECTED]> wrote:
On 3/13/07, C H Forsyth <[EMAIL PROTECTED]> wrote:
> anyway, as to the archaic nature of shells.
> >i also find it bizarre that you can call rc "old cruft"...
>
> i supposed that was a reference to the fact that the style of these shel
On 3/13/07, C H Forsyth <[EMAIL PROTECTED]> wrote:
anyway, as to the archaic nature of shells.
>i also find it bizarre that you can call rc "old cruft"...
i supposed that was a reference to the fact that the style of these shells
hasn't
changed all that much since 1977.
interestingly,
On 3/13/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
somebody (anothy?) made a comment ages ago about how it was "suprisingly slow".
that was me. don't misunderstand: i quite like the shell, and that
wasn't intended to imply that it's not suitable for a great number of
things (including, of
>> If the Inferno people had decided to 'update' mash instead of writing sh(1)
>for the record, i believe that i wrote the inferno shell before mash was
>written
nothing to do with 9fans, but since the matter has surfaced here:
the only real trouble with mash for Vita Nuova at the time was that t
strictly speaking, <> could be implemented with no help
from rc (and more generally) as in
boxredir fdin fdout cmd
okay, that's a bit silly, but the point between essential and
non-essential is in the eye of the beholder.
odd digression:
in the late 60s the fad was to rewrite bigger ins
> If the Inferno people had decided to 'update' mash instead of writing sh(1)
for the record, i believe that i wrote the inferno shell before mash was written
(in fact, it was one of the first limbo programs i wrote, before i came to VN).
certain of its features were only made possible by later in
On Mon, Mar 12, 2007 at 01:05:24PM -0400, Dan Cross wrote:
Was that a Haiku?
Yes. At any rate, I'm tired of trolling. I'll stop until I start
seeing things in /n/sources/patch.
--
Kris Maglione
Whatever it is, somebody will have had it for lunch.
pgpfd8DX8jiDH.pgp
Description: PGP signature
Was that a Haiku?
On 3/12/07, Russ Cox <[EMAIL PROTECTED]> wrote:
Everyone has said their piece,
and opinions have stopped changing.
Let's move on.
Russ
Everyone has said their piece,
and opinions have stopped changing.
Let's move on.
Russ
On 3/11/07, Kris Maglione <[EMAIL PROTECTED]> wrote:
[...]
And if rc is to have such a massive revamping, there's no good reason to
keep calling it rc.
I think the point you keep missing is that this isn't such a massive
revamping. It's a simple change that doesn't break any existing
scripts;
what's being proposed here for addition to rc is totally different
from the mash/inferno-sh case.
in the inferno case, we had two different authors with some
substantial differences in ideas for constructing shells, in terms of
syntax, semantics, and features. you're correct that trying to add
ro
On Mon Mar 12 03:51:10 EST 2007, [EMAIL PROTECTED] wrote:
> On Mon, Mar 12, 2007 at 12:14:08AM +0100, Martin Neubauer wrote:
> This is entirely beside the point. Breaking old scripts is the least of
> the issues. The point is that there's little value in altering rc,
> compared to writing a new
On Mon, Mar 12, 2007 at 12:14:08AM +0100, Martin Neubauer wrote:
Specifically, there are two arguments supporting the change. First, it isn't
really a new feature -- it just makes one already present more general (with
a striking resemblance to the for loop.) Second, it doesn't break scripts in a
* erik quanstrom ([EMAIL PROTECTED]) wrote:
> and more to the point, there have been no ideas yet that would
> break older rc scripts nor change the grammer or lexemes. even list
> assignment would be a matter of handling a case that currently gives
> an error. the grammer supports it.
Specifica
On Sun Mar 11 15:28:11 EST 2007, [EMAIL PROTECTED] wrote:
> I never said that rc(1) was perfect. I'm all for rewriting it, and
> fixing bugs. I'm not for breaking its syntax, though. It makes far more
> sense to leave rc as rc(1) and to write a new shell which deals with the
> shortcomings of rc
On Sun, Mar 11, 2007 at 12:12:57PM +, matt wrote:
> You miss the point entirely.
This might be petty but, no Kris, you missed the point.
If you want further proof, see rc(1) BUGS
I never said that rc(1) was perfect. I'm all for rewriting it, and
fixing bugs. I'm not for breaking its synt
> You miss the point entirely.
This might be petty but, no Kris, you missed the point.
If you want further proof, see rc(1) BUGS
Your broken rc will not interpret scripts intended for the One True rc
When you've got ghosts in /bin, who you gonna call ?
On 3/10/07, Kris Maglione <[EMAIL PROTECTED]> wrote:
On Sat, Mar 10, 2007 at 04:20:22PM -0500, Dan Cross wrote:
>Nonsense. You think rc has never changed before? There have been
>plenty of non-backwards compatible changes in Plan 9.
You miss the point entirely. I agree that things shouldn't st
On Sat, Mar 10, 2007 at 04:20:22PM -0500, Dan Cross wrote:
Nonsense. You think rc has never changed before? There have been
plenty of non-backwards compatible changes in Plan 9.
You miss the point entirely. I agree that things shouldn't stay the same
simply for the sake of compatibility. Pla
On 3/10/07, Kris Maglione <[EMAIL PROTECTED]> wrote:
The difference here is that there has always been one rc (ignoring the
UNIX version, which is gratuitously incompatible), unlike the bourne
shells. One of the great things about it has always been that you could
write rc scripts and know that t
On Sat, Mar 10, 2007 at 07:32:30AM -0500, erik quanstrom wrote:
The problem is that then new scrips wouldn't be portable.
ya. right. is this this the same reason i should check my c code
with the johnson c compiler (being very careful to not use function
prototypes) to make sure it works everwh
On Sat Mar 10 00:17:12 EST 2007, [EMAIL PROTECTED] wrote:
> On Fri, Mar 09, 2007 at 11:46:46PM -0500, erik quanstrom wrote:
> >why wouldn't it be backwardly compatable?
> >"(a b) = $*" is currently an error in rc. and i don't
> >believe i've ever seen an rc script that depends on
> >this error.
>
On Fri, Mar 09, 2007 at 11:46:46PM -0500, erik quanstrom wrote:
why wouldn't it be backwardly compatable?
"(a b) = $*" is currently an error in rc. and i don't
believe i've ever seen an rc script that depends on
this error.
The problem is that then new scrips wouldn't be portable. It would be
why wouldn't it be backwardly compatable?
"(a b) = $*" is currently an error in rc. and i don't
believe i've ever seen an rc script that depends on
this error.
- erik
On Fri Mar 9 13:30:57 EST 2007, [EMAIL PROTECTED] wrote:
> i doubt this would be too much trouble to implement in rc.
> (but who
On Fri, Mar 09, 2007 at 06:23:39PM +, [EMAIL PROTECTED] wrote:
i doubt this would be too much trouble to implement in rc.
(but who wants backwardly incompatible shell scripts?!)
Indeed, adding such stuff to rc is fairly useless (though that doesn't
seem to stop quanstro, et. al.). It's bet
in the inferno shell, i added multi-variable assignment,
which seems to address the issue that shift is most often used for.
for instance:
% a = (a b c d)
% (x y a) = $a
% echo $x
a
% echo $y
b
% echo $a
c d
%
to throw away a few dummy values from the start of the
list, just use throwaway varia
the emailers union local 101 blames mgmt. for the
mixup.
- erik
On Fri Mar 9 06:18:31 EST 2007, [EMAIL PROTECTED] wrote:
> > broken! fn myshift{echo $*; '*' = $*(2-) ; echo $*}
> > broken! myshift 1 2 3 4 5
> > 1 2 3 4 5
> >
> > less than 20 lines of code. (attached so you can aver
i thought this may have been a difference in your
version of rc and the one i was using. now i don't think
so.
; 9fs sources
; exec /n/sources/plan9/386/bin/rc
; a=(1 '2 3' 4 5)
; s a
; whatis a
a=('2 3' 4 5)
; s a
; whatis a
interesting. it works for me™.
- erik
On Fri, Mar 09, 2007 at 08:55:44AM -0500, erik quanstrom wrote:
that's a good solution. i appoligize for being a topper but
here's the same function without eval:
Indeed, you're not a topper. I tried a similar version, but added the
eval because it gave me error, as does yours. Namely: variab
that's a good solution. i appoligize for being a topper but
here's the same function without eval:
fn s {
v = $1
* = $$1
shift
$v = $*
}
it does use a local, but it avoids a "null list in concatenation"
error if a=()
> broken! fn myshift{echo $*; '*' = $*(2-) ; echo $*}
> broken! myshift 1 2 3 4 5
> 1 2 3 4 5
>
> less than 20 lines of code. (attached so you can avert your eyes.)
I'd say submit it as a patch. But please explain what I'm missing in
the last few lines, should it not say?
1 2
On Fri, Mar 09, 2007 at 12:31:59AM -0500, erik quanstrom wrote:
that's a very elegant solution. but alas,
It has its flaws, but it's useful in many circimstances nonetheless.
I've used, named tl, instead, a few times when I new the first argument
to a fn would be a word, and I needed to shif
that's a very elegant solution. but alas,
cpu% a=(a 'b c')
cpu% a=`{myshift $a}
cpu% whatis a
a=(b c)
- erik
my way:
fn myshift {
shift
echo $*
}
lotte% a=(1 2 3 4 5)
lotte% a=`{myshift $a}
lotte% echo $a
2 3 4 5
Federico G. Benavento
---
/bin/fortune:
I don't think so, therefore I'm probably not. --Alan Smithee
d'oh... there's a missing line there ...
broken! myshift 1 2 3 4 5
1 2 3 4 5
2 3 4 5
- erik
On Thu Mar 8 23:43:06 EST 2007, [EMAIL PROTECTED] wrote:
> broken! fn myshift{echo $*; '*' = $*(2-) ; echo $*}
> broken! myshift 1 2 3 4 5
> 1 2 3 4 5
>
> les
... or the deleterious effects of insomnia.
i decided to see how hard this is. after considering "shift var",
and hd and tl, i added ranges to rc, as in
cpu% 8.out
broken! a=(1 2 3 4)
broken! echo $a(1 4)
1 4
broken! echo $a(2-3)
2 3
broke
shift in rc only shifts the command line argument ($*).
How can I shift other variable in rc?
I would like to do something like this:
a=(a b c)
shift a 2
echo $a
and the echo should yield "b c".
It's clumsy but it works:
a=(a b c);
*=$a { shift; shift; a=($*) }
Russ
shift in rc only shifts the command line argument ($*).
How can I shift other variable in rc?
I would like to do something like this:
a=(a b c)
shift a 2
echo $a
and the echo should yield "b c".
TIA,
--
39 matches
Mail list logo
