[9fans] rc exec error behaviour

[9fans] rc exec error behaviour

[cinap_lenrek]

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

Re: [9fans] rc exec error behaviour

[Prof Brucee]

[-- Attachment #1: Type: text/plain, Size: 1165 bytes --]

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
>
>

[-- Attachment #2: Type: text/html, Size: 1460 bytes --]

Re: [9fans] rc exec error behaviour

[lucio]

> 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.

Re: [9fans] rc exec error behaviour

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 1303 bytes --]

Sign me up for testing.

On Sat, Jan 30, 2016, 5:16 PM Prof Brucee <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
>>
>>

[-- Attachment #2: Type: text/html, Size: 1802 bytes --]

Re: [9fans] rc exec error behaviour

[Sean Hinchee]

[-- Attachment #1: Type: text/plain, Size: 1738 bytes --]

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 <prof.brucee@gmail.com
> <mailto: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
>     <mailto: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
>


[-- Attachment #2: Type: text/html, Size: 3223 bytes --]

Re: [9fans] rc exec error behaviour

[erik quanstrom]

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 <prof.brucee@gmail.com
> > <mailto:prof.brucee@gmail.com>> 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

Re: [9fans] rc exec error behaviour

[lucio]

> 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!

Re: [9fans] rc exec error behaviour

[Richard Miller]

> 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.

Re: [9fans] rc exec error behaviour

[lucio]

> 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.

Re: [9fans] rc exec error behaviour

[Prof Brucee]

[-- Attachment #1: Type: text/plain, Size: 932 bytes --]

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 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1228 bytes --]

Re: [9fans] rc exec error behaviour

[Richard Miller]

> Cinap assured me that go works on 9front.

For some value of "works".

Re: [9fans] rc exec error behaviour

[Aram Hăvărneanu]

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.

-- 
Aram Hăvărneanu

Re: [9fans] rc exec error behaviour

[hiro]

> 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.

Re: [9fans] rc exec error behaviour

[David du Colombier]

> 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

Re: [9fans] rc exec error behaviour

[lucio]

> 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.

Re: [9fans] rc exec error behaviour

[David du Colombier]

>> 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

Re: [9fans] rc exec error behaviour

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 689 bytes --]

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 <lucio@proxima.alt.za> 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.
>
>
>

[-- Attachment #2: Type: text/html, Size: 1022 bytes --]

Re: [9fans] rc exec error behaviour

[Skip Tavakkolian]

[-- Attachment #1: Type: text/plain, Size: 881 bytes --]

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 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 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.
>>
>>
>>

[-- Attachment #2: Type: text/html, Size: 1485 bytes --]

Re: [9fans] rc exec error behaviour

[sl]

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

Re: [9fans] rc exec error behaviour

[Sean Hinchee]

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
>

Re: [9fans] rc exec error behaviour

[Kurt H Maier]

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

Re: [9fans] rc exec error behaviour

[sl]

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

Re: [9fans] rc exec error behaviour

[Wes Kussmaul]

Now's your chance!

No match for domain "9COULD.NET". >>> Last update of whois database: 
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 <http://9pcloud.net>
>
> On Tue, Feb 2, 2016 at 8:46 AM Skip Tavakkolian 
> <skip.tavakkolian@gmail.com <mailto:skip.tavakkolian@gmail.com>> wrote:
>
>     Same here. The namespace manager for 9pcould.net
>     <http://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 <lucio@proxima.alt.za
>     <mailto:lucio@proxima.alt.za>> 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.
>
>

-- 

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 but ask you politely to pretend you didn't see it. Any disclaimer suggesting 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™ identity credential from the Osmio Vital Records Department (http://osmio.ch), we could easily and at no cost exchange encrypted messages and files with each other.

[9fans] plan9/arm in Go 1.7? (was: rc exec error behaviour)

[Skip Tavakkolian]

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.

Re: [9fans] plan9/arm in Go 1.7? (was: rc exec error behaviour)

[David du Colombier]

> 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

Re: [9fans] rc exec error behaviour

[Lyndon Nerenberg]

> 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.

Re: [9fans] rc exec error behaviour

[Prof Brucee]

[-- Attachment #1: Type: text/plain, Size: 311 bytes --]

Every time I bend something it breaks.
On 02/02/2016 3:18 PM, "Lyndon Nerenberg" <lyndon@orthanc.ca> wrote:

>
> > 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.
>
>

[-- Attachment #2: Type: text/html, Size: 623 bytes --]

Re: [9fans] rc exec error behaviour

[Lyndon Nerenberg]

> On Feb 1, 2016, at 8:21 PM, Prof Brucee <prof.brucee@gmail.com> wrote:
> 
> Every time I bend something it breaks.

I remember the "where's Bruce" from the ... whereever the hell it was Plan9 workshop video.

Re: [9fans] rc exec error behaviour

[erik quanstrom]

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 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?

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 → 3
undoredir: seek 512 /rc/lib/rcmain
undoredir: open /dev/cons → 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/$pid/fd
knows all about it.  :-)

- erik