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