From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: Date: Sat, 30 Jan 2016 17:31:27 +0100 From: cinap_lenrek@felloff.net To: 9fans@9fans.net MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] rc exec error behaviour Topicbox-Message-UUID: 8067b92c-ead9-11e9-9d60-3106f5b1d025 in the rc shell, when one has exec statement and the exec fails, rc tries to continue interpreting statements after the exec which fails with a strange EOF error because in the process of preparing filedescriptors for exec, the very fd thats used to read the script was closed. burnzez provided an example of this like: term% rc -c 'exec doesnotexist; echo test' doesnotexist: './doesnotexist' directory entry not found test rc: /rc/lib/rcmain:29: token EOF: syntax error the manpage does not explicitely specify what should happen when exec fails. i did try to have rc open the . script as OCEXEC and that fixed the problem, but it wont work for any other redirections and will have side effects as the close-on-exec flag is a propery of the channel and not of the file descriptor slot. so imagine stuff like . /fd/0... i think it would me most resonable to just have rc exit with error status on failure. are there any objections to this? -- cinap From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Sun, 31 Jan 2016 12:16:20 +1100 Message-ID: From: Prof Brucee To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a11c3029e19ff54052a970432 Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 807fdbce-ead9-11e9-9d60-3106f5b1d025 --001a11c3029e19ff54052a970432 Content-Type: text/plain; charset=UTF-8 Any objections to me rewriting rc in go without all known bugs? On 31/01/2016 3:36 AM, wrote: > in the rc shell, when one has exec statement and the exec fails, rc tries > to > continue interpreting statements after the exec which fails with a strange > EOF error because in the process of preparing filedescriptors for exec, > the very fd thats used to read the script was closed. > > burnzez provided an example of this like: > > term% rc -c 'exec doesnotexist; echo test' > doesnotexist: './doesnotexist' directory entry not found > test > rc: /rc/lib/rcmain:29: token EOF: syntax error > > the manpage does not explicitely specify what should happen when exec > fails. > > i did try to have rc open the . script as OCEXEC and that fixed the > problem, but it wont work for any other redirections and will have side > effects > as the close-on-exec flag is a propery of the channel and not of the file > descriptor slot. so imagine stuff like . /fd/0... > > i think it would me most resonable to just have rc exit with error status > on > failure. are there any objections to this? > > -- > cinap > > --001a11c3029e19ff54052a970432 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Any objections to me rewriting rc in go without all known bu= gs?

On 31/01/2016 3:36 AM, <cinap_lenrek@felloff.net> wrote:
in the rc shell, when one has e= xec statement and the exec fails, rc tries to
continue interpreting statements after the exec which fails with a strange<= br> EOF error because in the process of preparing filedescriptors for exec,
the very fd thats used to read the script was closed.

burnzez provided an example of this like:

term% rc -c 'exec doesnotexist; echo test'
doesnotexist: './doesnotexist' directory entry not found
test
rc: /rc/lib/rcmain:29: token EOF: syntax error

the manpage does not explicitely specify what should happen when exec fails= .

i did try to have rc open the . script as OCEXEC and that fixed the
problem, but it wont work for any other redirections and will have side eff= ects
as the close-on-exec flag is a propery of the channel and not of the file descriptor slot. so imagine stuff like . /fd/0...

i think it would me most resonable to just have rc exit with error status o= n
failure. are there any objections to this?

--
cinap

--001a11c3029e19ff54052a970432-- From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <5891c27675372287927bbb4c4c4c6a9d@proxima.alt.za> To: 9fans@9fans.net Date: Sun, 31 Jan 2016 06:20:18 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 8088e098-ead9-11e9-9d60-3106f5b1d025 > Any objections to me rewriting rc in go without all known bugs? None from me, although you may want to rename it. And benchmark it, for what that is worth. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Sun, 31 Jan 2016 06:58:45 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1145886e359507052a9bcd17 Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 808f9cc6-ead9-11e9-9d60-3106f5b1d025 --001a1145886e359507052a9bcd17 Content-Type: text/plain; charset=UTF-8 Sign me up for testing. On Sat, Jan 30, 2016, 5:16 PM Prof Brucee wrote: > Any objections to me rewriting rc in go without all known bugs? > On 31/01/2016 3:36 AM, wrote: > >> in the rc shell, when one has exec statement and the exec fails, rc tries >> to >> continue interpreting statements after the exec which fails with a strange >> EOF error because in the process of preparing filedescriptors for exec, >> the very fd thats used to read the script was closed. >> >> burnzez provided an example of this like: >> >> term% rc -c 'exec doesnotexist; echo test' >> doesnotexist: './doesnotexist' directory entry not found >> test >> rc: /rc/lib/rcmain:29: token EOF: syntax error >> >> the manpage does not explicitely specify what should happen when exec >> fails. >> >> i did try to have rc open the . script as OCEXEC and that fixed the >> problem, but it wont work for any other redirections and will have side >> effects >> as the close-on-exec flag is a propery of the channel and not of the file >> descriptor slot. so imagine stuff like . /fd/0... >> >> i think it would me most resonable to just have rc exit with error status >> on >> failure. are there any objections to this? >> >> -- >> cinap >> >> --001a1145886e359507052a9bcd17 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Sign me up for testing.

= On Sat, Jan 30, 2016, 5:16 PM=C2=A0Prof Brucee <prof.brucee@gmail.com> wrote:

Any objections to me rewriting rc in go w= ithout all known bugs?

On 31/01/2016 3:36 AM, <cinap_lenrek@felloff.net> = wrote:
in the rc she= ll, when one has exec statement and the exec fails, rc tries to
continue interpreting statements after the exec which fails with a strange<= br> EOF error because in the process of preparing filedescriptors for exec,
the very fd thats used to read the script was closed.

burnzez provided an example of this like:

term% rc -c 'exec doesnotexist; echo test'
doesnotexist: './doesnotexist' directory entry not found
test
rc: /rc/lib/rcmain:29: token EOF: syntax error

the manpage does not explicitely specify what should happen when exec fails= .

i did try to have rc open the . script as OCEXEC and that fixed the
problem, but it wont work for any other redirections and will have side eff= ects
as the close-on-exec flag is a propery of the channel and not of the file descriptor slot. so imagine stuff like . /fd/0...

i think it would me most resonable to just have rc exit with error status o= n
failure. are there any objections to this?

--
cinap

--001a1145886e359507052a9bcd17-- From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: From: Sean Hinchee Message-ID: <56AEAC38.4040701@gmail.com> Date: Sun, 31 Jan 2016 18:52:08 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/alternative; boundary="------------090709030909070008000907" Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 80966cb8-ead9-11e9-9d60-3106f5b1d025 This is a multi-part message in MIME format. --------------090709030909070008000907 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Will this project (rc-go?) be hosted at a particular bitbucket/hg repository for pull requests, etc? On 01/31/2016 12:58 AM, Skip Tavakkolian wrote: > Sign me up for testing. > > On Sat, Jan 30, 2016, 5:16 PM Prof Brucee > wrote: > > Any objections to me rewriting rc in go without all known bugs? > > On 31/01/2016 3:36 AM, > wrote: > > in the rc shell, when one has exec statement and the exec > fails, rc tries to > continue interpreting statements after the exec which fails > with a strange > EOF error because in the process of preparing filedescriptors > for exec, > the very fd thats used to read the script was closed. > > burnzez provided an example of this like: > > term% rc -c 'exec doesnotexist; echo test' > doesnotexist: './doesnotexist' directory entry not found > test > rc: /rc/lib/rcmain:29: token EOF: syntax error > > the manpage does not explicitely specify what should happen > when exec fails. > > i did try to have rc open the . script as OCEXEC and that > fixed the > problem, but it wont work for any other redirections and will > have side effects > as the close-on-exec flag is a propery of the channel and not > of the file > descriptor slot. so imagine stuff like . /fd/0... > > i think it would me most resonable to just have rc exit with > error status on > failure. are there any objections to this? > > -- > cinap > --------------090709030909070008000907 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable Will this project (rc-go?) be hosted at a particular bitbucket/hg repository for pull requests, etc?

On 01/31/2016 12:58 AM, Skip Tavakkolian wrote:
Sign me up for testing.

On Sat, Jan 30, 2016, 5:16 PM=C2=A0Prof Brucee &= lt;prof.brucee@gmail.com> wrote:

Any objections to me rewriting rc in go without all known bugs?

On 31/01/2016 3:36 AM, <= cinap_lenrek@felloff.net> wrote:
in the rc shell, when one has exec statement and the exec fails, rc tries to
continue interpreting statements after the exec which fails with a strange
EOF error because in the process of preparing filedescriptors for exec,
the very fd thats used to read the script was closed.

burnzez provided an example of this like:

term% rc -c 'exec doesnotexist; echo test'
doesnotexist: './doesnotexist' directory entry not found test
rc: /rc/lib/rcmain:29: token EOF: syntax error

the manpage does not explicitely specify what should happen when exec fails.

i did try to have rc open the . script as OCEXEC and that fixed the
problem, but it wont work for any other redirections and will have side effects
as the close-on-exec flag is a propery of the channel and not of the file
descriptor slot. so imagine stuff like . /fd/0...

i think it would me most resonable to just have rc exit with error status on
failure. are there any objections to this?

--
cinap


--------------090709030909070008000907-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 31 Jan 2016 20:06:48 -0800 To: 9fans@9fans.net Message-ID: <12b64b844d268b34a00a972c545d19f1@mule> In-Reply-To: <56AEAC38.4040701@gmail.com> References: <56AEAC38.4040701@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 80c516f8-ead9-11e9-9d60-3106f5b1d025 On Sun Jan 31 16:56:19 PST 2016, henesy.dev@gmail.com wrote: > Will this project (rc-go?) be hosted at a particular bitbucket/hg > repository for pull requests, etc? > > On 01/31/2016 12:58 AM, Skip Tavakkolian wrote: > > Sign me up for testing. > > > > On Sat, Jan 30, 2016, 5:16 PM Prof Brucee > > wrote: > > > > Any objections to me rewriting rc in go without all known bugs? i don't believe the offer was made with a straight face. - erik From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Mon, 1 Feb 2016 06:29:20 +0200 From: lucio@proxima.alt.za In-Reply-To: <12b64b844d268b34a00a972c545d19f1@mule> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 80c95218-ead9-11e9-9d60-3106f5b1d025 > i don't believe the offer was made with a straight face. Hard to tell, with Prof Brucee. Do you have evidence of the professor being a go-skeptic? Like, no syscall-53 in his kernel? :-) Lucio. PS: I know cinap had his qualms about Go, but I have no recent evidence there, either. PPS: and for those who care, Richard Miller is contributing a lot of great stuff to Go for plan9/arm. And Cherry's linux/mips needs only a nudge for plan9/mips. Yoh! I sound like a Go televangelist! From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <13e6d9a8361b785329ae11b7cbd44b0e@hamnavoe.com> To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Mon, 1 Feb 2016 17:01:01 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 80cd831a-ead9-11e9-9d60-3106f5b1d025 > Richard Miller is contributing a lot of great stuff to Go for plan9/arm. Thank you, but mostly I've just updated and titivated the previous work from Lucio and Gorka, to the state where it should pass the codereview and does pass all the go1.6 tests (with *ncpu=1). For multicore I am still chasing down some bugs in Plan 9 (and not only on arm) which seem to be flushed out by the particularly brutal go test suite. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <4453d20545662e83e07ae0a3ce2caf21@proxima.alt.za> To: 9fans@9fans.net Date: Mon, 1 Feb 2016 20:35:04 +0200 From: lucio@proxima.alt.za In-Reply-To: <13e6d9a8361b785329ae11b7cbd44b0e@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 80e1433c-ead9-11e9-9d60-3106f5b1d025 > Thank you, but mostly I've just updated and titivated the previous > work from Lucio and Gorka, to the state where it should pass the > codereview and does pass all the go1.6 tests (with *ncpu=1). I need to point out that I really added nothing other than a minute amount of coordination at the time and in retrospect even that had a very limited effect. Gorka did the great work and I'm very pleased that Richard picked it up and turned it into something I believe (hope? wish?) will be with us for a while. I wish I could share some of the glory, but I really do not deserve it :-) Here's a toast to all those who make my daily Plan 9 experiences a pleasure. Thank you all! Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Mon, 1 Feb 2016 12:33:13 -0800 From: Skip Tavakkolian <9nut@9netics.com> In-Reply-To: <13e6d9a8361b785329ae11b7cbd44b0e@hamnavoe.com> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: [9fans] plan9/arm in Go 1.7? (was: rc exec error behaviour) Topicbox-Message-UUID: 80d1d488-ead9-11e9-9d60-3106f5b1d025 Russ has started the planning for Go 1.7 on #godev. Would it be too optimistic to expect plan9/arm in that release? >> Richard Miller is contributing a lot of great stuff to Go for plan9/arm. > > Thank you, but mostly I've just updated and titivated the previous > work from Lucio and Gorka, to the state where it should pass the > codereview and does pass all the go1.6 tests (with *ncpu=1). > > For multicore I am still chasing down some bugs in Plan 9 (and not > only on arm) which seem to be flushed out by the particularly brutal > go test suite. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: <13e6d9a8361b785329ae11b7cbd44b0e@hamnavoe.com> Date: Mon, 1 Feb 2016 21:45:17 +0100 Message-ID: From: David du Colombier <0intro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] plan9/arm in Go 1.7? (was: rc exec error behaviour) Topicbox-Message-UUID: 80db5134-ead9-11e9-9d60-3106f5b1d025 > Russ has started the planning for Go 1.7 on #godev. Would it be too > optimistic to expect plan9/arm in that release? Yes. Richard has already submitted his CLs for review. -- David du Colombier From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <4453d20545662e83e07ae0a3ce2caf21@proxima.alt.za> References: <13e6d9a8361b785329ae11b7cbd44b0e@hamnavoe.com> <4453d20545662e83e07ae0a3ce2caf21@proxima.alt.za> Date: Tue, 2 Feb 2016 12:29:39 +1100 Message-ID: From: Prof Brucee To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a113cca146972d8052abf6f6a Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81739b42-ead9-11e9-9d60-3106f5b1d025 --001a113cca146972d8052abf6f6a Content-Type: text/plain; charset=UTF-8 Cinap assured me that go works on 9front. Please send a wish list. Here docs in functions are on it. Exec was the ball buster. On 02/02/2016 8:53 AM, wrote: > > Thank you, but mostly I've just updated and titivated the previous > > work from Lucio and Gorka, to the state where it should pass the > > codereview and does pass all the go1.6 tests (with *ncpu=1). > > I need to point out that I really added nothing other than a minute > amount of coordination at the time and in retrospect even that had a > very limited effect. Gorka did the great work and I'm very pleased > that Richard picked it up and turned it into something I believe > (hope? wish?) will be with us for a while. > > I wish I could share some of the glory, but I really do not deserve it > :-) > > Here's a toast to all those who make my daily Plan 9 experiences a > pleasure. Thank you all! > > Lucio. > > > --001a113cca146972d8052abf6f6a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Cinap assured me that go works on 9front. Please send a wish= list. Here docs in functions are on it. Exec was the ball buster.

On 02/02/2016 8:53 AM, <lucio@proxima.alt.za> wrote:
> Thank you, but mostly I've jus= t updated and titivated the previous
> work from Lucio and Gorka, to the state where it should pass the
> codereview and does pass all the go1.6 tests (with *ncpu=3D1).

I need to point out that I really added nothing other than a minute
amount of coordination at the time and in retrospect even that had a
very limited effect.=C2=A0 Gorka did the great work and I'm very please= d
that Richard picked it up and turned it into something I believe
(hope? wish?) will be with us for a while.

I wish I could share some of the glory, but I really do not deserve it
:-)

Here's a toast to all those who make my daily Plan 9 experiences a
pleasure.=C2=A0 Thank you all!

Lucio.


--001a113cca146972d8052abf6f6a-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Lyndon Nerenberg In-Reply-To: <12b64b844d268b34a00a972c545d19f1@mule> Date: Mon, 1 Feb 2016 20:16:02 -0800 Content-Transfer-Encoding: 7bit Message-Id: <15DF64AF-37B0-4B66-B184-65F4ACAB784E@orthanc.ca> References: <56AEAC38.4040701@gmail.com> <12b64b844d268b34a00a972c545d19f1@mule> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 817c7a28-ead9-11e9-9d60-3106f5b1d025 > On Jan 31, 2016, at 8:06 PM, erik quanstrom wrote: > > i don't believe the offer was made with a straight face. But perhaps with a bent compiler. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <15DF64AF-37B0-4B66-B184-65F4ACAB784E@orthanc.ca> References: <56AEAC38.4040701@gmail.com> <12b64b844d268b34a00a972c545d19f1@mule> <15DF64AF-37B0-4B66-B184-65F4ACAB784E@orthanc.ca> Date: Tue, 2 Feb 2016 15:21:29 +1100 Message-ID: From: Prof Brucee To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=089e01538286f2ceb7052ac1d5ce Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 8180b354-ead9-11e9-9d60-3106f5b1d025 --089e01538286f2ceb7052ac1d5ce Content-Type: text/plain; charset=UTF-8 Every time I bend something it breaks. On 02/02/2016 3:18 PM, "Lyndon Nerenberg" wrote: > > > On Jan 31, 2016, at 8:06 PM, erik quanstrom > wrote: > > > > i don't believe the offer was made with a straight face. > > But perhaps with a bent compiler. > > --089e01538286f2ceb7052ac1d5ce Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable

Every time I bend something it breaks.

On 02/02/2016 3:18 PM, "Lyndon Nerenberg&qu= ot; <lyndon@orthanc.ca> wrot= e:

> On Jan 31, 2016, at 8:06 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>
> i don't believe the offer was made with a straight face.

But perhaps with a bent compiler.

--089e01538286f2ceb7052ac1d5ce-- From mboxrd@z Thu Jan 1 00:00:00 1970 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 9.2 \(3112\)) From: Lyndon Nerenberg In-Reply-To: Date: Mon, 1 Feb 2016 20:24:00 -0800 Content-Transfer-Encoding: quoted-printable Message-Id: References: <56AEAC38.4040701@gmail.com> <12b64b844d268b34a00a972c545d19f1@mule> <15DF64AF-37B0-4B66-B184-65F4ACAB784E@orthanc.ca> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81879174-ead9-11e9-9d60-3106f5b1d025 > On Feb 1, 2016, at 8:21 PM, Prof Brucee wrote: >=20 > Every time I bend something it breaks. I remember the "where's Bruce" from the ... whereever the hell it was = Plan9 workshop video.= From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net From: Richard Miller <9fans@hamnavoe.com> Date: Tue, 2 Feb 2016 10:53:09 +0000 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 8193c5ac-ead9-11e9-9d60-3106f5b1d025 > Cinap assured me that go works on 9front. For some value of "works". From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: From: =?UTF-8?B?QXJhbSBIxIN2xINybmVhbnU=?= Date: Tue, 2 Feb 2016 13:36:08 +0100 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81a09b56-ead9-11e9-9d60-3106f5b1d025 For 386, Go barely works. For amd64, current Go doesn't currently work on 9front (but works on Charles' kernel), probably due to a kernel bug. Either way, Go on Plan 9 is held together with duck tape, especially networking bits. Btw, Go broke on 9front about a year ago (or was it more than that?). Only one single person noticed, and that was months later after the fact. That serves as a useful test to gauge interest (and quality) in Go on Plan 9. --=20 Aram H=C4=83v=C4=83rneanu From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 2 Feb 2016 13:53:04 +0100 Message-ID: From: hiro <23hiro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81a9746a-ead9-11e9-9d60-3106f5b1d025 > That serves as a useful test to gauge interest (and quality) in Go on Plan 9. No, only in Go on 9front. It might be that other people are using their own version of Plan 9 with Go at the same time. Also, what about people who just don't think it's worth upgrading cause stuff still works for them? I don't get the point about quality. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 2 Feb 2016 14:23:50 +0100 Message-ID: From: David du Colombier <0intro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81add5dc-ead9-11e9-9d60-3106f5b1d025 > For 386, Go barely works. For amd64, current Go doesn't currently work > on 9front (but works on Charles' kernel), probably due to a kernel > bug. You got confused. It works (but there are still issues) on both 9front's and Charles' amd64 kernel, but not on 9front's 386 kernel (since November 2014). > Btw, Go broke on 9front about a year ago (or was it more than that?). > Only one single person noticed, and that was months later after the > fact. That serves as a useful test to gauge interest (and quality) in > Go on Plan 9. Another reason could be that most of 9front users use the amd64 kernel and not the 386 kernel. -- David du Colombier From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: To: 9fans@9fans.net Date: Tue, 2 Feb 2016 17:46:48 +0200 From: lucio@proxima.alt.za In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81b2a8fa-ead9-11e9-9d60-3106f5b1d025 > You got confused. It works (but there are still issues) on both 9front's > and Charles' amd64 kernel, but not on 9front's 386 kernel (since November 2014). Are you all saying that Go does not work on Plan 9 legacy and that all my code is just faking it? I know Go is broken in my 9vx installation, but that could be really hard to fix. Took a while last time and would have taken much, much longer without help from Anthony Martin. Lucio. From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: References: Date: Tue, 2 Feb 2016 17:02:40 +0100 Message-ID: From: David du Colombier <0intro@gmail.com> To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81b6af54-ead9-11e9-9d60-3106f5b1d025 >> You got confused. It works (but there are still issues) on both 9front's >> and Charles' amd64 kernel, but not on 9front's 386 kernel (since November 2014). > > Are you all saying that Go does not work on Plan 9 legacy and that all > my code is just faking it? No, Go works fine on Bell Labs' 386 kernel. BTW, I wrote a small Go FAQ a while ago: http://9legacy.org/9legacy/doc/go/faq.html -- David du Colombier From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Tue, 2 Feb 2016 16:46:27 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a1145886eafce19052acc3e0e Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81c9ed08-ead9-11e9-9d60-3106f5b1d025 --001a1145886eafce19052acc3e0e Content-Type: text/plain; charset=UTF-8 Same here. The namespace manager for 9pcould.net is written in Go and most definitely runs on a (slightly modified) Labs Plan 9, 386. On Tue, Feb 2, 2016 at 7:47 AM wrote: > > You got confused. It works (but there are still issues) on both 9front's > > and Charles' amd64 kernel, but not on 9front's 386 kernel (since > November 2014). > > Are you all saying that Go does not work on Plan 9 legacy and that all > my code is just faking it? > > I know Go is broken in my 9vx installation, but that could be really > hard to fix. Took a while last time and would have taken much, much > longer without help from Anthony Martin. > > Lucio. > > > --001a1145886eafce19052acc3e0e Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Same here. The namespace manager for 9pcould.net is written in Go and most defi= nitely runs on a (slightly modified) Labs Plan 9, 386.

On Tue, Feb 2, 2016 at 7:47 AM <lucio@proxima.alt.za> wrote:
> You got confused. It works (but the= re are still issues) on both 9front's
> and Charles' amd64 kernel, but not on 9front's 386 kernel (sin= ce November 2014).

Are you all saying that Go does not work on Plan 9 legacy and that all
my code is just faking it?

I know Go is broken in my 9vx installation, but that could be really
hard to fix.=C2=A0 Took a while last time and would have taken much, much longer without help from Anthony Martin.

Lucio.


--001a1145886eafce19052acc3e0e-- From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 References: In-Reply-To: From: Skip Tavakkolian Date: Tue, 2 Feb 2016 16:52:32 +0000 Message-ID: To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: multipart/alternative; boundary=001a114786c26cb505052acc54e5 Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81ce0c94-ead9-11e9-9d60-3106f5b1d025 --001a114786c26cb505052acc54e5 Content-Type: text/plain; charset=UTF-8 Autocorrect fail! And yet Apple is winning big. Sigh... I mean 9pcloud.net On Tue, Feb 2, 2016 at 8:46 AM Skip Tavakkolian wrote: > Same here. The namespace manager for 9pcould.net is written in Go and > most definitely runs on a (slightly modified) Labs Plan 9, 386. > > On Tue, Feb 2, 2016 at 7:47 AM wrote: > >> > You got confused. It works (but there are still issues) on both 9front's >> > and Charles' amd64 kernel, but not on 9front's 386 kernel (since >> November 2014). >> >> Are you all saying that Go does not work on Plan 9 legacy and that all >> my code is just faking it? >> >> I know Go is broken in my 9vx installation, but that could be really >> hard to fix. Took a while last time and would have taken much, much >> longer without help from Anthony Martin. >> >> Lucio. >> >> >> --001a114786c26cb505052acc54e5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Autocorrect fail! And yet Apple is winning big. Sigh...

I mean 9pcloud.net

On Tue, Feb 2, 2016 at 8:46 AM Skip Tavakkolian <skip.tavakkolian@gmail.com>= ; wrote:
Same here. The namespace manager for 9pcould.net is written in Go and most definitely r= uns on a (slightly modified) Labs Plan 9, 386.

On Tue, Feb 2, 2016 at 7:47 AM <lucio@proxima.alt.za> wro= te:
> You got confused. It works= (but there are still issues) on both 9front's
> and Charles' amd64 kernel, but not on 9front's 386 kernel (sin= ce November 2014).

Are you all saying that Go does not work on Plan 9 legacy and that all
my code is just faking it?

I know Go is broken in my 9vx installation, but that could be really
hard to fix.=C2=A0 Took a while last time and would have taken much, much longer without help from Anthony Martin.

Lucio.


--001a114786c26cb505052acc54e5-- From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 2 Feb 2016 12:11:54 -0500 From: sl@9front.org To: 9fans@9fans.net Message-ID: <1b157c8bb44aec67c1446c45563889e9@ghost.attlocal.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81e95eb8-ead9-11e9-9d60-3106f5b1d025 I think when people say "works" they mean that tip builds. The outstanding bugs with the language on Plan 9 are still outstanding (see the open issues), regardless of which Plan 9 you are running. I think it's great if someone's programs work. I use a few go programs (built with go 1.4.2 for both 386 and amd64) daily on 9front without problems. That said, go 1.5.x (the language) fails to build on 9front/amd64, but seems to build and work as well as 1.4.2 on 9front/386. The crucial aspect here is what works and what doesn't work *after* go builds. I think some people keep making cracks because some funfamental things remain broken in all versions (see the open issues). People who didn't notice tip no longer builds on some systems may (like me) have been content running their existing working binaries. Not everyone chases updates unless there is an immediate reason to update. sl From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 2 Feb 2016 12:24:25 -0500 From: sl@9front.org To: 9fans@9fans.net Message-ID: <9d8c06676fa2b54737e36524949cde2a@ghost.attlocal.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81d73c10-ead9-11e9-9d60-3106f5b1d025 I think when people say "works" they mean that tip builds. The outstanding bugs with the language on Plan 9 are still outstanding (see the open issues), regardless of which Plan 9 you are running. I think it's great if someone's programs work. I use a few go programs (built with go 1.4.2 for both 386 and amd64) daily on 9front without problems. That said, go 1.5.x (the language) fails to build on 9front/amd64, but seems to build and work as well as 1.4.2 on 9front/386. The crucial aspect here is what works and what doesn't work *after* go builds. I think some people keep making cracks because some funfamental things remain broken in all versions (see the open issues). People who didn't notice tip no longer builds on some systems may (like me) have been content running their existing working binaries. Not everyone chases updates unless there is an immediate reason to update. sl From mboxrd@z Thu Jan 1 00:00:00 1970 To: 9fans@9fans.net References: From: Wes Kussmaul Message-ID: <56B0E861.9090801@ReliableID.com> Date: Tue, 2 Feb 2016 12:33:21 -0500 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81db6f60-ead9-11e9-9d60-3106f5b1d025 Now's your chance! No match for domain "9COULD.NET". >>> Last update of whois database:=20 Tue, 02 Feb 2016 17:22:15 GMT <<< On 02/02/2016 11:52 AM, Skip Tavakkolian wrote: > Autocorrect fail! And yet Apple is winning big. Sigh... > > I mean 9pcloud.net > > On Tue, Feb 2, 2016 at 8:46 AM Skip Tavakkolian=20 > > wrote: > > Same here. The namespace manager for 9pcould.net > is written in Go and most definitely runs on > a (slightly modified) Labs Plan 9, 386. > > On Tue, Feb 2, 2016 at 7:47 AM > wrote: > > > You got confused. It works (but there are still issues) on > both 9front's > > and Charles' amd64 kernel, but not on 9front's 386 kernel > (since November 2014). > > Are you all saying that Go does not work on Plan 9 legacy and > that all > my code is just faking it? > > I know Go is broken in my 9vx installation, but that could be > really > hard to fix. Took a while last time and would have taken > much, much > longer without help from Anthony Martin. > > Lucio. > > --=20 Wes Kussmaul The Authenticity Institute 738 Main Street Waltham, MA 02451 office +1 781 790 1674 mobile +1 781 330 1881 THIS COMMUNICATION IS INTENDED ONLY FOR THE USE OF THE PERSON TO WHOM IT = IS ADDRESSED. If it was addressed incorrectly there's not much I can do b= ut ask you politely to pretend you didn't see it. Any disclaimer suggesti= ng that the sender has some kind of recourse is just wishful thinking. If I had a message from you that was digitally signed using your Sigillum= =E2=84=A2 identity credential from the Osmio Vital Records Department (ht= tp://osmio.ch), we could easily and at no cost exchange encrypted message= s and files with each other. From mboxrd@z Thu Jan 1 00:00:00 1970 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <1b157c8bb44aec67c1446c45563889e9@ghost.attlocal.net> From: Sean Hinchee Message-ID: <56B14BE0.2040000@gmail.com> Date: Tue, 2 Feb 2016 18:37:52 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: <1b157c8bb44aec67c1446c45563889e9@ghost.attlocal.net> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 81facdc4-ead9-11e9-9d60-3106f5b1d025 Go 1.5.1 built and is running on 9Front/amd64 I thought, but doesn't on 9Front/386? On 02/02/2016 11:11 AM, sl@9front.org wrote: > I think when people say "works" they mean that tip builds. The > outstanding bugs with the language on Plan 9 are still outstanding > (see the open issues), regardless of which Plan 9 you are running. > > I think it's great if someone's programs work. I use a few go programs > (built with go 1.4.2 for both 386 and amd64) daily on 9front without > problems. That said, go 1.5.x (the language) fails to build on 9front/amd64, > but seems to build and work as well as 1.4.2 on 9front/386. The crucial > aspect here is what works and what doesn't work *after* go builds. I think > some people keep making cracks because some funfamental things remain > broken in all versions (see the open issues). > > People who didn't notice tip no longer builds on some systems may > (like me) have been content running their existing working binaries. > Not everyone chases updates unless there is an immediate reason to > update. > > sl > From mboxrd@z Thu Jan 1 00:00:00 1970 Date: Tue, 2 Feb 2016 19:48:13 -0500 From: Kurt H Maier To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Message-ID: <20160203004813.GA69402@wopr.sciops.net> References: <1b157c8bb44aec67c1446c45563889e9@ghost.attlocal.net> <56B14BE0.2040000@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <56B14BE0.2040000@gmail.com> Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 8205885e-ead9-11e9-9d60-3106f5b1d025 On Tue, Feb 02, 2016 at 06:37:52PM -0600, Sean Hinchee wrote: > Go 1.5.1 built and is running on 9Front/amd64 I thought, but doesn't on > 9Front/386? That's correct, but the actual point is that it's still full of weird bugs and is not 100% functional, even after it builds. Doesn't stop some good software from working, but it's not like Go on Plan 9 is reliable. khm From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Sun, 21 Feb 2016 16:19:43 -0800 To: 9fans@9fans.net Message-ID: <82486434a757e7c658914037a4ce106a@lilly.quanstro.net> In-Reply-To: References: MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] rc exec error behaviour Topicbox-Message-UUID: 8702ce16-ead9-11e9-9d60-3106f5b1d025 On Sat Jan 30 08:33:54 PST 2016, cinap_lenrek@felloff.net wrote: > in the rc shell, when one has exec statement and the exec fails, rc tri= es to > continue interpreting statements after the exec which fails with a stra= nge > EOF error because in the process of preparing filedescriptors for exec, > the very fd thats used to read the script was closed. >=20 > burnzez provided an example of this like: >=20 > term% rc -c 'exec doesnotexist; echo test' > doesnotexist: './doesnotexist' directory entry not found > test > rc: /rc/lib/rcmain:29: token EOF: syntax error >=20 > the manpage does not explicitely specify what should happen when exec f= ails. >=20 > i did try to have rc open the . script as OCEXEC and that fixed the > problem, but it wont work for any other redirections and will have side= effects > as the close-on-exec flag is a propery of the channel and not of the fi= le > descriptor slot. so imagine stuff like . /fd/0... >=20 > i think it would me most resonable to just have rc exit with error stat= us on > failure. are there any objections to this? i don't think that's the right thing to do. i think the specification is= reasonable, and what i'd like the shell to do on exec failure. i have a little hack = that shows it's feasable to recover, although i think the approach i'm taking really= sucks. :-) ; 6.out broken! exec x undoableredir: close 3 /rc/lib/rcmain 512 undoableredir: close 4 /dev/cons 1076 x: '/bin/x' directory entry not found exec fails undoredir: open /rc/lib/rcmain =E2=86=92 3 undoredir: seek 512 /rc/lib/rcmain undoredir: open /dev/cons =E2=86=92 4 undoredir: seek 1076 /dev/cons unfortunately, this depends on fd2path which doesn't know the open mode of the file in question. (so wierd, why doesn't it?) but /proc/$pi= d/fd knows all about it. :-) - erik