>>> here's the solution. not rc's fault. recompile lib9 and listen1:
>> Great. It solves the problem. Since this is specific to plan9 unix
>> port, is it necessary to post this on plan9port-dev group so it can
>> be inserted in the oficial code?
> go for it.
Just to let you know, I opened an
> > i take it back. i'd forgotten how quirky unix is these days.
> > here's the solution. not rc's fault. recompile lib9 and listen1:
> >
> > diff -r 5caa04977471 src/lib9/rfork.c
> > (...)
>
>
> back in 13/05/2009 00:57 i've submitted a different patch for that
> (mail with subject ``[p9p] B
Hi,
On Monday 25 of April 2011 05:36:17 erik quanstrom wrote:
> ; hg diff rfork.c
>
> > hmm. is that right? it's wait3/wait4 that's failing. it shouldn't
> > be necesary to catch SIGCHLD for wait to work. but maybe
> > it is
>
> i take it back. i'd forgotten how quirky unix is these days.
On Mon Apr 25 16:15:26 EDT 2011, smi...@zenzebra.mv.com wrote:
> Skip Tavakkolian writes:
>
> > where's the "Like" button on this thing?
>
> I think there's an fs for that. ;)
there's no reason upas/fs and its clients couldn't
support a like button, but it would be hard to make
work with every
I think there's an fs for that. ;)
"There's a file system for that."
-- new plan9 marketing slogan ;-)
Skip Tavakkolian writes:
> where's the "Like" button on this thing?
I think there's an fs for that. ;)
--
+---+
|E-Mail: smi...@zenzebra.mv.com PGP key ID: BC549F8B|
|Fingerprint: 9329 DB4A 30F5 6EDA D2BA 3489 DAB7 555A
Yeah, I agree... too much FB makes me want a "like" button on my mail
client!
On Mon, Apr 25, 2011 at 12:17 PM, Skip Tavakkolian <
skip.tavakkol...@gmail.com> wrote:
> where's the "Like" button on this thing?
>
> On Mon, Apr 25, 2011 at 7:56 AM, Bakul Shah wrote:
> >
> >
> >
> > this ancient uni
where's the "Like" button on this thing?
On Mon, Apr 25, 2011 at 7:56 AM, Bakul Shah wrote:
>
>
>
> this ancient unix
> time to kill it dead and good
> linux is it. Yuck!
>
> Happy?
>
> this ancient unix
> time to kill it dead and good
> linux is it. Yuck!
>
> Happy?
+1 rofl.
- erik
On Apr 24, 2011, at 11:59 PM, Robert Ransom wrote:
> On Sun, 24 Apr 2011 22:53:19 -0700
> Bakul Shah wrote:
>
>>
>> On Apr 24, 2011, at 9:39 PM, erik quanstrom wrote:
>>
>>> On Sun Apr 24 23:59:37 EDT 2011, ba...@bitblocks.com wrote:
> i take it back. i'd forgotten how quirky unix is the
> Actually, no. At least *BSD has evolved from Unix(TM) over time. Not a from
> scratch implementation.
bsd is like george washington's axe. i bet you can find more
lines of code in common between us and a slime mould than
you can between any modern bsd and v7. :-)
- erik
On Mon Apr 25 09:54:36 EDT 2011, mauricio.antu...@gmail.com wrote:
> > here's the solution. not rc's fault. recompile lib9 and listen1:
> >
>
> Great. It solves the problem.
>
> Since this is specific to plan9 unix port, is it necessary to post this
> on plan9port-dev group so it can be inserte
> here's the solution. not rc's fault. recompile lib9 and listen1:
>
Great. It solves the problem.
Since this is specific to plan9 unix port, is it necessary to post this
on plan9port-dev group so it can be inserted in the oficial code?
Also, your path should remove the funny comment just wher
On Sun, 24 Apr 2011 22:53:19 -0700
Bakul Shah wrote:
>
> On Apr 24, 2011, at 9:39 PM, erik quanstrom wrote:
>
> > On Sun Apr 24 23:59:37 EDT 2011, ba...@bitblocks.com wrote:
> >>> i take it back. i'd forgotten how quirky unix is these days. >
> >> here's the solution. not rc's fault. recomp
On Apr 24, 2011, at 9:39 PM, erik quanstrom wrote:
> On Sun Apr 24 23:59:37 EDT 2011, ba...@bitblocks.com wrote:
>>> i take it back. i'd forgotten how quirky unix is these days. >
>> here's the solution. not rc's fault. recompile lib9 and listen1:
>>
>> *Linux*, not unix.
>
> this meme is a
this meme is ancient
time to give it die today
linux is unix
Not while the BSD line lives.
On Sun Apr 24 23:59:37 EDT 2011, ba...@bitblocks.com wrote:
> > i take it back. i'd forgotten how quirky unix is these days. >
> here's the solution. not rc's fault. recompile lib9 and listen1:
>
> *Linux*, not unix.
this meme is ancient
time to give it die today
linux is unix
- erik
> i take it back. i'd forgotten how quirky unix is these days.
> here's the solution. not rc's fault. recompile lib9 and listen1:
*Linux*, not unix.
; hg diff rfork.c
> hmm. is that right? it's wait3/wait4 that's failing. it shouldn't
> be necesary to catch SIGCHLD for wait to work. but maybe
> it is
i take it back. i'd forgotten how quirky unix is these days.
here's the solution. not rc's fault. recompile lib9 and listen1:
diff -r 5ca
On Sun Apr 24 22:01:41 EDT 2011, al...@pbrane.org wrote:
> > This is really weird. I don't even know what could I check. 'listen1'
> > source code is pretty clean, and it calls command and args with a simple
> > 'exec' call. The only thing that was also unusual is that the 'net'
> > variable, which
> It fails on my Linux machine also. It's because an rfork with RFNOWAIT
> sets up a child proc that will ignore SIGCHLD. If the program that
> is executed (in this case rc) calls fork or exec all SIGCHLD signals
> will be ignored, see signal(7).
>
> Ultimately, this causes rc to set status='' fo
same for me on linux too (previous tests were on osx). i'm sure
anthony's analysis is the correct one.
On Sun, Apr 24, 2011 at 11:03 PM, andrey mirtchovski
wrote:
>> #!/usr/local/plan9/bin/9 rc
>> echo first at path: $path(1)
>> for (i in `{seq 1 5}){
>> if (test $i -eq 3) {
>> echo $i equals 3
>> }
>> if not echo $i is different from 3
>> }
>
> NB: in general, y
> #!/usr/local/plan9/bin/9 rc
> echo first at path: $path(1)
> for (i in `{seq 1 5}){
> if (test $i -eq 3) {
> echo $i equals 3
> }
> if not echo $i is different from 3
> }
NB: in general, you don't need 'test'. use "if (~ $i 3) {}".
that said, now I'm convince
> This is really weird. I don't even know what could I check. 'listen1'
> source code is pretty clean, and it calls command and args with a simple
> 'exec' call. The only thing that was also unusual is that the 'net'
> variable, which is supposed to be set to a directory, is always blank,
> but the
> Doesn't fail here.
>
> Make sure you are running $PLAN9/bin/rc. If so, rebuild all (to start
> from a clean slate) and rerun your test
Uninstalled distribution package for plan9 and got .tgz at:
http://swtch.com/plan9port/plan9port.tgz
MD5 checksum matched. Unpacked to /usr/local, executed
On Sun, 24 Apr 2011 17:05:43 - =?UTF-8?Q?Maur=C3=ADcio?= CA
wrote:
> >> How can running a script throw 'listen1' can get 'rc' to fail an
> >> 'if' test?!?!
>
> > This looks like you're using p9p. Have you checked your PATH?
> > It might not be finding an executable, or finding the wrong ve
>> How can running a script throw 'listen1' can get 'rc' to fail an
>> 'if' test?!?!
> This looks like you're using p9p. Have you checked your PATH?
> It might not be finding an executable, or finding the wrong version
> of an executable.
Sure. Take, for instance, this script uniquely named 'tes
Maurício CA writes:
> However, using (where 'listen_test.rc' is the name I gave this
> script):
>
> listen1 'tcp!localhost!8080' ./listen_test.rc
>
> and
>
> echo Hi | dial -e 'tcp!localhost!8080'
>
> what I get is:
>
> I am insane.
>
> How can running a script throw 'listen1' can get
> I am unable to reproduce your result on OSX (p9p at tip):
>
> $ echo Hi | dial -e 'tcp!localhost!8080'
> I am not insane.
> $
>
> are you sure your listen1 isn't running an older version of the script?
>
Yes, I am. It's easy to check that by, say, changing a few letters in
the printed messages
I am unable to reproduce your result on OSX (p9p at tip):
$ echo Hi | dial -e 'tcp!localhost!8080'
I am not insane.
$
are you sure your listen1 isn't running an older version of the script?
Hi, all,
This seems like black magic to me. I've wrote this small example to
try to understand a problem with a bigger script.
#!/usr/bin/env rc
if (test 1 -ne 1) {
echo I am insane.
}
if not {
echo I am not insane.
}
Obviously, when I run it, I get:
I a
32 matches
Mail list logo
