* [9fans] Strange rc bug for the 9fans bug-squashing squad
@ 2009-03-16 23:26 Uriel
2009-03-17 1:31 ` Martin Neubauer
0 siblings, 1 reply; 23+ messages in thread
From: Uriel @ 2009-03-16 23:26 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
At first I thought very big rc variables seem to become strangely corrupted.
% for(i in `{seq 1000}) { echo 0123456789 >> f }
% ifs='' {x=`{cat f}}
% echo -n $x > f2
% diff f f2
745c745
< 0123456789
---
> 01234567 9
But the bug seems to be in `{ } because replacing the use of the x var
with simply:
% ifs='' { echo -n `{cat f} > f2}
Produces the same results.
Longer strings get more random(?) characters 'blanked'.
The results are identical in p9p and native plan9.
I looked a bit around the rc source that seemed relevant, but didn't
see any obvious errors, but I don't fully understand the code.
Peace
uriel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-16 23:26 [9fans] Strange rc bug for the 9fans bug-squashing squad Uriel
@ 2009-03-17 1:31 ` Martin Neubauer
2009-03-17 2:01 ` Martin Neubauer
0 siblings, 1 reply; 23+ messages in thread
From: Martin Neubauer @ 2009-03-17 1:31 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Hi,
I think the following gives a clue:
% cmp f f2
f f2 differ: char 8193
The following snippet from the Xbackq code seems to be the culprit:
char wd[8193];
int c;
char *s, *ewd=&wd[8192], *stop;
...
while((c = rchr(f))!=EOF){
if(strchr(stop, c) || s==ewd){
if(s!=wd){
*s='\0';
v = newword(wd, v);
s = wd;
}
}
else *s++=c;
}
Keeping the loop from dropping characters is trivial. Getting rid of
the inserted space probably requires a dynamic buffer. I might give
it a shot.
Regards,
Martin
* Uriel (uriel99@gmail.com) wrote:
> At first I thought very big rc variables seem to become strangely corrupted.
>
> % for(i in `{seq 1000}) { echo 0123456789 >> f }
> % ifs='' {x=`{cat f}}
> % echo -n $x > f2
> % diff f f2
> 745c745
> < 0123456789
> ---
> > 01234567 9
>
> But the bug seems to be in `{ } because replacing the use of the x var
> with simply:
>
> % ifs='' { echo -n `{cat f} > f2}
>
> Produces the same results.
>
> Longer strings get more random(?) characters 'blanked'.
>
> The results are identical in p9p and native plan9.
>
> I looked a bit around the rc source that seemed relevant, but didn't
> see any obvious errors, but I don't fully understand the code.
>
> Peace
>
> uriel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 1:31 ` Martin Neubauer
@ 2009-03-17 2:01 ` Martin Neubauer
2009-03-17 22:27 ` Uriel
0 siblings, 1 reply; 23+ messages in thread
From: Martin Neubauer @ 2009-03-17 2:01 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On second thought (and in the light of Geoffs reply) I probably won't.
If you do care, the following change to the loop in question will at
least preserve all input:
while((c = rchr(f))!=EOF){
if(strchr(stop, c)){
if(s!=wd){
*s='\0';
v = newword(wd, v);
s = wd;
}
}
else if(s==ewd){
*s='\0';
v = newword(wd, v);
s = wd;
*s++=c;
}
else *s++=c;
}
With a dynamic buffer the tokenisation could be prevented, but in your
example the lexical scanner would quite likely bail afterwards. (I
remember a discussion some time ago about this.)
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 2:01 ` Martin Neubauer
@ 2009-03-17 22:27 ` Uriel
2009-03-17 22:43 ` erik quanstrom
0 siblings, 1 reply; 23+ messages in thread
From: Uriel @ 2009-03-17 22:27 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Thanks martin for your analysis, this makes some sense to me, but as I
pointed out, even setting ifs to () doesn't solve the issue, so it
would be nice to find a solution to this.
Right now having the output of `{} corrupted can be quite inconvenient...
Thanks
uriel
On Tue, Mar 17, 2009 at 3:01 AM, Martin Neubauer <m.ne@gmx.net> wrote:
> On second thought (and in the light of Geoffs reply) I probably won't.
> If you do care, the following change to the loop in question will at
> least preserve all input:
>
> while((c = rchr(f))!=EOF){
> if(strchr(stop, c)){
> if(s!=wd){
> *s='\0';
> v = newword(wd, v);
> s = wd;
> }
> }
> else if(s==ewd){
> *s='\0';
> v = newword(wd, v);
> s = wd;
> *s++=c;
> }
> else *s++=c;
> }
>
> With a dynamic buffer the tokenisation could be prevented, but in your
> example the lexical scanner would quite likely bail afterwards. (I
> remember a discussion some time ago about this.)
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 22:27 ` Uriel
@ 2009-03-17 22:43 ` erik quanstrom
2009-03-17 23:23 ` Uriel
2009-03-18 10:53 ` roger peppe
0 siblings, 2 replies; 23+ messages in thread
From: erik quanstrom @ 2009-03-17 22:43 UTC (permalink / raw)
To: 9fans
On Tue Mar 17 18:29:14 EDT 2009, uriel99@gmail.com wrote:
> Thanks martin for your analysis, this makes some sense to me, but as I
> pointed out, even setting ifs to () doesn't solve the issue, so it
> would be nice to find a solution to this.
>
> Right now having the output of `{} corrupted can be quite inconvenient...
it is unreasonable to expect to be able to generate tokens
that are bigger than 8k. however, the '8' should not
be dropped. i would think this small change would be worth
consideration.
; diffy -c havefork.c
/n/dump/2009/0317/sys/src/cmd/rc/havefork.c:74,80 - havefork.c:74,80
Xbackq(void)
{
char wd[8193];
- int c;
+ int c, trunc;
char *s, *ewd=&wd[8192], *stop;
struct io *f;
var *ifs = vlook("ifs");
/n/dump/2009/0317/sys/src/cmd/rc/havefork.c:105,113 - havefork.c:105,116
while((c = rchr(f))!=EOF){
if(strchr(stop, c) || s==ewd){
if(s!=wd){
+ trunc = s == ewd;
*s='\0';
v = newword(wd, v);
s = wd;
+ if(trunc)
+ *s++ = c;
}
}
else *s++=c;
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 22:43 ` erik quanstrom
@ 2009-03-17 23:23 ` Uriel
2009-03-17 23:26 ` erik quanstrom
2009-03-18 10:53 ` roger peppe
1 sibling, 1 reply; 23+ messages in thread
From: Uriel @ 2009-03-17 23:23 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Tue, Mar 17, 2009 at 11:43 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Tue Mar 17 18:29:14 EDT 2009, uriel99@gmail.com wrote:
>> Thanks martin for your analysis, this makes some sense to me, but as I
>> pointed out, even setting ifs to () doesn't solve the issue, so it
>> would be nice to find a solution to this.
>>
>> Right now having the output of `{} corrupted can be quite inconvenient...
>
> it is unreasonable to expect to be able to generate tokens
> that are bigger than 8k.
Well, I would prefer if such limit didn't exist ;) But it doesn't seem
like a totally unreasonable limit either.
> however, the '8' should not be dropped.
Yes, this is the critical issue, at least if the tokens are just
split, one can join them up by hand if needed, but as things are now
the data gets corrupted in ways that at least at first are mystifying,
and which are hard to work around.
> i would think this small change would be worth
> consideration.
I will give it a try when I get a chance, but if it fixes the lost
chars, I'll be happy.
Thanks!
uriel
> ; diffy -c havefork.c
> /n/dump/2009/0317/sys/src/cmd/rc/havefork.c:74,80 - havefork.c:74,80
> Xbackq(void)
> {
> char wd[8193];
> - int c;
> + int c, trunc;
> char *s, *ewd=&wd[8192], *stop;
> struct io *f;
> var *ifs = vlook("ifs");
> /n/dump/2009/0317/sys/src/cmd/rc/havefork.c:105,113 - havefork.c:105,116
> while((c = rchr(f))!=EOF){
> if(strchr(stop, c) || s==ewd){
> if(s!=wd){
> + trunc = s == ewd;
> *s='\0';
> v = newword(wd, v);
> s = wd;
> + if(trunc)
> + *s++ = c;
> }
> }
> else *s++=c;
>
> - erik
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 23:23 ` Uriel
@ 2009-03-17 23:26 ` erik quanstrom
2009-03-18 0:26 ` Uriel
0 siblings, 1 reply; 23+ messages in thread
From: erik quanstrom @ 2009-03-17 23:26 UTC (permalink / raw)
To: 9fans
> >> Right now having the output of `{} corrupted can be quite inconvenient...
> >
> > it is unreasonable to expect to be able to generate tokens
> > that are bigger than 8k.
>
> Well, I would prefer if such limit didn't exist ;) But it doesn't seem
> like a totally unreasonable limit either.
why can't you just let ifs = $newline (formatted to fit your screen) ?
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 23:26 ` erik quanstrom
@ 2009-03-18 0:26 ` Uriel
2009-03-18 1:23 ` Russ Cox
2009-03-18 1:25 ` erik quanstrom
0 siblings, 2 replies; 23+ messages in thread
From: Uriel @ 2009-03-18 0:26 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> why can't you just let ifs = $newline (formatted to fit your screen) ?
Unfortunately that doesn't work in this case, my input is HTTP post
data, which is a single line of URL-encoded text which I have to
decode into multiple parameters of arbitrary length.
Still, if no characters were getting lost, I probably can figure some
way to work around the issue and stitch things together after they get
split.
uriel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 0:26 ` Uriel
@ 2009-03-18 1:23 ` Russ Cox
2009-03-18 7:31 ` Gabriel Díaz López de la Llave
2009-03-18 10:31 ` maht
2009-03-18 1:25 ` erik quanstrom
1 sibling, 2 replies; 23+ messages in thread
From: Russ Cox @ 2009-03-18 1:23 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
On Tue, Mar 17, 2009 at 5:26 PM, Uriel <uriel99@gmail.com> wrote:
> Unfortunately that doesn't work in this case, my input is HTTP post
> data, which is a single line of URL-encoded text which I have to
> decode into multiple parameters of arbitrary length.
writing a shell script doesn't mean you have to
write everything in the shell. why not write a
simple c program that reads stdin, decodes the
key=value arguments, and writes each "value" to
/env/form_key?
russ
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 0:26 ` Uriel
2009-03-18 1:23 ` Russ Cox
@ 2009-03-18 1:25 ` erik quanstrom
2009-03-18 11:30 ` Uriel
1 sibling, 1 reply; 23+ messages in thread
From: erik quanstrom @ 2009-03-18 1:25 UTC (permalink / raw)
To: 9fans
On Tue Mar 17 20:29:50 EDT 2009, uriel99@gmail.com wrote:
> > why can't you just let ifs = $newline (formatted to fit your screen) ?
>
> Unfortunately that doesn't work in this case, my input is HTTP post
> data, which is a single line of URL-encoded text which I have to
> decode into multiple parameters of arbitrary length.
why not write a small program to crack the post data.
might take ½ an hour, tops.
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 1:23 ` Russ Cox
@ 2009-03-18 7:31 ` Gabriel Díaz López de la Llave
2009-03-18 10:31 ` maht
1 sibling, 0 replies; 23+ messages in thread
From: Gabriel Díaz López de la Llave @ 2009-03-18 7:31 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Hello
http://plan9.aichi-u.ac.jp/pegasus/cgitools/formparse.html
It works well for me, seems than Kenji Arisawa thought about this when
developing his http tools pegasus and rit.
Take a look a it, may be it helps you.
Slds.
Gabi
On 18/03/09 2:23, "Russ Cox" <rsc@swtch.com> wrote:
> On Tue, Mar 17, 2009 at 5:26 PM, Uriel <uriel99@gmail.com> wrote:
>> Unfortunately that doesn't work in this case, my input is HTTP post
>> data, which is a single line of URL-encoded text which I have to
>> decode into multiple parameters of arbitrary length.
>
> writing a shell script doesn't mean you have to
> write everything in the shell. why not write a
> simple c program that reads stdin, decodes the
> key=value arguments, and writes each "value" to
> /env/form_key?
>
> russ
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 1:23 ` Russ Cox
2009-03-18 7:31 ` Gabriel Díaz López de la Llave
@ 2009-03-18 10:31 ` maht
2009-03-18 15:27 ` erik quanstrom
1 sibling, 1 reply; 23+ messages in thread
From: maht @ 2009-03-18 10:31 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
not every environment is Plan 9 so /env is not an option.
Arbitrary limits seem a bit, well, arbitrary ! (not that I'm complaining).
With a flat memory address space and Gbs of memory chucking a realloc in
there is not totally out of technical bounds.
Using rc in werc neutralizes OS differences to a certain degree,
obviously some things catch one out, such as this one. (and just wait
until a \0 comes along!)
In this case it might make sense to inspect Content-Length and
Content-Type and awk it with FS="&" to individual files and then inspect
their size
And then someone will want to upload Mime !
> On Tue, Mar 17, 2009 at 5:26 PM, Uriel <uriel99@gmail.com> wrote:
>
>> Unfortunately that doesn't work in this case, my input is HTTP post
>> data, which is a single line of URL-encoded text which I have to
>> decode into multiple parameters of arbitrary length.
>>
>
> writing a shell script doesn't mean you have to
> write everything in the shell. why not write a
> simple c program that reads stdin, decodes the
> key=value arguments, and writes each "value" to
> /env/form_key?
>
> russ
>
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 22:43 ` erik quanstrom
2009-03-17 23:23 ` Uriel
@ 2009-03-18 10:53 ` roger peppe
2009-03-18 13:18 ` erik quanstrom
1 sibling, 1 reply; 23+ messages in thread
From: roger peppe @ 2009-03-18 10:53 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
2009/3/17 erik quanstrom <quanstro@quanstro.net>:
> it is unreasonable to expect to be able to generate tokens
> that are bigger than 8k.
i'm not sure i agree. they're not just tokens, they're strings,
and there are lots of reasons why one might wish to
have a string longer than 8k read from a file. i've certainly done so
in inferno's sh, which doesn't have this restriction.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 1:25 ` erik quanstrom
@ 2009-03-18 11:30 ` Uriel
0 siblings, 0 replies; 23+ messages in thread
From: Uriel @ 2009-03-18 11:30 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
But parsing is not the big issue (thanks Charles for sending me a
small program that does just that), the issue here is sticking the
results in a variable (or variables), Russ' suggestion would work, but
only in native Plan 9 and not in p9p.
Still, I might be able to hack something up if characters don't get
deleted, which seems like a real bug to me.
But while I don't like arbitrary limits (specially when I hit them
;)), I can understand that for the sake of simplicity it makes sense
to have them and not fall into the 'lets handle every possibility
under the sun' dogma.
Which makes me wonder, would it be excessive to double the current
limit? While 8k is quite ample, 16k would be even more so :)
Thanks everyone for all the ideas and suggestions
uriel
On Wed, Mar 18, 2009 at 2:25 AM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Tue Mar 17 20:29:50 EDT 2009, uriel99@gmail.com wrote:
>> > why can't you just let ifs = $newline (formatted to fit your screen) ?
>>
>> Unfortunately that doesn't work in this case, my input is HTTP post
>> data, which is a single line of URL-encoded text which I have to
>> decode into multiple parameters of arbitrary length.
>
> why not write a small program to crack the post data.
> might take ½ an hour, tops.
>
> - erik
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 10:53 ` roger peppe
@ 2009-03-18 13:18 ` erik quanstrom
2009-03-18 13:52 ` roger peppe
0 siblings, 1 reply; 23+ messages in thread
From: erik quanstrom @ 2009-03-18 13:18 UTC (permalink / raw)
To: 9fans
> 2009/3/17 erik quanstrom <quanstro@quanstro.net>:
> > it is unreasonable to expect to be able to generate tokens
> > that are bigger than 8k.
>
> i'm not sure i agree. they're not just tokens, they're strings,
> and there are lots of reasons why one might wish to
> have a string longer than 8k read from a file. i've certainly done so
> in inferno's sh, which doesn't have this restriction.
you win.
couple of notes -
* same changes to haven't fork, omitted for clarity
* erealloc should be in subr.c and declared in rc.h
and should be supported by Realloc in (plan9
unix win32)^.c
* there are two other calls to realloc that should
be addressed, too.
* the if guarding efree prevents a "free 0" whine.
havefork.c:67,81 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:67,72
}
}
- char*
- erealloc(char *p, long n)
- {
- p = realloc(p, n); /* botch, should be Realloc */
- if(p==0)
- panic("Can't realloc %d bytes\n", n);
- return p;
- }
-
/*
* Who should wait for the exit from the fork?
*/
havefork.c:82,89 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:73,81
void
Xbackq(void)
{
- int c, l;
- char *s, *wd, *ewd, *stop;
+ char wd[8193];
+ int c;
+ char *s, *ewd=&wd[8192], *stop;
struct io *f;
var *ifs = vlook("ifs");
word *v, *nextv;
havefork.c:108,127 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:100,115
default:
close(pfd[PWR]);
f = openfd(pfd[PRD]);
- s = wd = ewd = 0;
+ s = wd;
v = 0;
while((c = rchr(f))!=EOF){
- if(s==ewd){
- l = s-wd;
- wd = erealloc(wd, l+100);
- ewd = wd+l+100-1;
- s = wd+l;
+ if(strchr(stop, c) || s==ewd){
+ if(s!=wd){
+ *s='\0';
+ v = newword(wd, v);
+ s = wd;
+ }
}
- if(strchr(stop, c) && s!=wd){
- *s='\0';
- v = newword(wd, v);
- s = wd;
- }
else *s++=c;
}
if(s!=wd){
havefork.c:128,135 - /n/dump/2009/0316/sys/src/cmd/rc/havefork.c:116,121
*s='\0';
v = newword(wd, v);
}
- if(wd)
- efree(wd);
closeio(f);
Waitfor(pid, 0);
/* v points to reversed arglist -- reverse it onto argv */
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 13:18 ` erik quanstrom
@ 2009-03-18 13:52 ` roger peppe
2009-03-18 14:16 ` erik quanstrom
0 siblings, 1 reply; 23+ messages in thread
From: roger peppe @ 2009-03-18 13:52 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
2009/3/18 erik quanstrom <quanstro@quanstro.net>:
> - ewd = wd+l+100-1;
one small comment, based on a totally superficial scan of that diff:
might it not be better to grow the buffer by some multiplicative
factor, to avoid linear behaviour when reading large files?
i often (for no particularly good reason) use 50% as a growth
factor - it doesn't seem as radical as *2, but will still work ok
in the long run.
i've probably misread the code though...
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 13:52 ` roger peppe
@ 2009-03-18 14:16 ` erik quanstrom
2009-03-18 14:36 ` roger peppe
0 siblings, 1 reply; 23+ messages in thread
From: erik quanstrom @ 2009-03-18 14:16 UTC (permalink / raw)
To: 9fans
On Wed Mar 18 09:54:54 EDT 2009, rogpeppe@gmail.com wrote:
> 2009/3/18 erik quanstrom <quanstro@quanstro.net>:
> > - ewd = wd+l+100-1;
>
> one small comment, based on a totally superficial scan of that diff:
> might it not be better to grow the buffer by some multiplicative
> factor, to avoid linear behaviour when reading large files?
> i often (for no particularly good reason) use 50% as a growth
> factor - it doesn't seem as radical as *2, but will still work ok
> in the long run.
i have two arguments against doing expontential growth:
- other dynamicly allocated buffers in rc are allocated
in increments of 100 bytes.
- the linear behavior would only be for long *tokens*.
the length of the input is irrelavant. only in the case
of tokens >= 100 chars would there be a second call
to realloc.
the total cost is O(maximum token length) for the
whole input. how could this be a problem?
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 14:16 ` erik quanstrom
@ 2009-03-18 14:36 ` roger peppe
0 siblings, 0 replies; 23+ messages in thread
From: roger peppe @ 2009-03-18 14:36 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
2009/3/18 erik quanstrom <quanstro@coraid.com>:
> the total cost is O(maximum token length) for the
> whole input. how could this be a problem?
well, if there's only one token (e.g. when ifs=''), it's actually
O(n^2), assuming
that realloc copies every time.
but your first argument is sufficient. i acquiesce.
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-18 10:31 ` maht
@ 2009-03-18 15:27 ` erik quanstrom
0 siblings, 0 replies; 23+ messages in thread
From: erik quanstrom @ 2009-03-18 15:27 UTC (permalink / raw)
To: 9fans
On Wed Mar 18 06:33:49 EDT 2009, mattmobile@proweb.co.uk wrote:
> Using rc in werc neutralizes OS differences to a certain degree,
> obviously some things catch one out, such as this one. (and just wait
> until a \0 comes along!)
this is an easy problem to solve:
tr '\0' '☺'
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 22:24 ` erik quanstrom
@ 2009-03-17 23:14 ` Uriel
0 siblings, 0 replies; 23+ messages in thread
From: Uriel @ 2009-03-17 23:14 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
> in your test, try this
>
> echo $#x
I tried that too, I'm getting the same result for an ifs of '' or ().
% ifs=() {x=`{cat f}; echo $#x}
2
% ifs='' {x=`{cat f}; echo $#x}
2
I'm doing something else wrong?
uriel
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 22:16 ` Uriel
@ 2009-03-17 22:24 ` erik quanstrom
2009-03-17 23:14 ` Uriel
0 siblings, 1 reply; 23+ messages in thread
From: erik quanstrom @ 2009-03-17 22:24 UTC (permalink / raw)
To: 9fans
On Tue Mar 17 18:17:53 EDT 2009, uriel99@gmail.com wrote:
> Thanks Geoff for the prompt explanation, but I'm getting the same
> results with ifs=() Not sure why, but I'm not sure I understand the
> difference between setting ifs to '' and ().
in your test, try this
echo $#x
- erik
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
2009-03-17 0:40 geoff
@ 2009-03-17 22:16 ` Uriel
2009-03-17 22:24 ` erik quanstrom
0 siblings, 1 reply; 23+ messages in thread
From: Uriel @ 2009-03-17 22:16 UTC (permalink / raw)
To: Fans of the OS Plan 9 from Bell Labs
Thanks Geoff for the prompt explanation, but I'm getting the same
results with ifs=() Not sure why, but I'm not sure I understand the
difference between setting ifs to '' and ().
Thanks again
uriel
On Tue, Mar 17, 2009 at 1:40 AM, <geoff@plan9.bell-labs.com> wrote:
> Setting ifs='' defeats rc's tokenisation, so the result
> of `{} will be a series of rc `words', each limited to
> Wordmax (8192) bytes and with the next byte of the input
> stream after each word set to NUL.
>
> Did you perhaps intend to write ifs=(), which has different
> meaning?
>
>
^ permalink raw reply [flat|nested] 23+ messages in thread
* Re: [9fans] Strange rc bug for the 9fans bug-squashing squad
@ 2009-03-17 0:40 geoff
2009-03-17 22:16 ` Uriel
0 siblings, 1 reply; 23+ messages in thread
From: geoff @ 2009-03-17 0:40 UTC (permalink / raw)
To: 9fans
Setting ifs='' defeats rc's tokenisation, so the result
of `{} will be a series of rc `words', each limited to
Wordmax (8192) bytes and with the next byte of the input
stream after each word set to NUL.
Did you perhaps intend to write ifs=(), which has different
meaning?
^ permalink raw reply [flat|nested] 23+ messages in thread
end of thread, other threads:[~2009-03-18 15:27 UTC | newest]
Thread overview: 23+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-16 23:26 [9fans] Strange rc bug for the 9fans bug-squashing squad Uriel
2009-03-17 1:31 ` Martin Neubauer
2009-03-17 2:01 ` Martin Neubauer
2009-03-17 22:27 ` Uriel
2009-03-17 22:43 ` erik quanstrom
2009-03-17 23:23 ` Uriel
2009-03-17 23:26 ` erik quanstrom
2009-03-18 0:26 ` Uriel
2009-03-18 1:23 ` Russ Cox
2009-03-18 7:31 ` Gabriel Díaz López de la Llave
2009-03-18 10:31 ` maht
2009-03-18 15:27 ` erik quanstrom
2009-03-18 1:25 ` erik quanstrom
2009-03-18 11:30 ` Uriel
2009-03-18 10:53 ` roger peppe
2009-03-18 13:18 ` erik quanstrom
2009-03-18 13:52 ` roger peppe
2009-03-18 14:16 ` erik quanstrom
2009-03-18 14:36 ` roger peppe
2009-03-17 0:40 geoff
2009-03-17 22:16 ` Uriel
2009-03-17 22:24 ` erik quanstrom
2009-03-17 23:14 ` Uriel
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).