On Sat Jan 30 08:33:54 PST 2016, cinap_len...@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
