From mboxrd@z Thu Jan 1 00:00:00 1970 From: erik quanstrom Date: Thu, 26 Nov 2009 22:19:55 -0500 To: 9fans@9fans.net Message-ID: <0394d35b1ea8545f5f3c6966f7974bb1@brasstown.quanstro.net> In-Reply-To: <> References: <> MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" Content-Transfer-Encoding: 7bit Subject: Re: [9fans] rc bug? Topicbox-Message-UUID: a37c429c-ead5-11e9-9d60-3106f5b1d025 > % rc -c 'echo hello > /fd/4' <>[4] /dev/cons > hello > % {echo hello > /fd/4} <>[4] /dev/cons > /fd/4: rc: can't open: '/fd/4' inappropriate use of fd > % > > as it happens, the actual file being opened in the second > instance is '#c/cons' (the original rc's stdin). if you'd used a larger fd, you would have gotten this error /fd/9: rc (8.out): can't open: '/fd/9' mounted directory forbids creation this hints at the real problem. redirections are processed in two steps. opening the file is done by X(read|write|append|rdwr). assigning the proper fd is done by execexec. (called when running an external function.) the problem is that your example requires step two to be done when executing step 1. (that's why the rc -c trick worked, you forced rc to create fd 4 before using it in the subshell and it also explains why you got the wrong fd.) also, since the fd assignment is done only by execexec, you'll notice that cd doesnt exist>[2=] still delivers errors to the console. i don't know of an easy solution to this. maybe a few judicious hacks could solve a large portion of the problem. byron's shell tended to solve this problem by forking early. i've included the rc machine that is generated by code similar to yours. - erik ---- broken! <>[9]/dev/cons >/fd/9 echo 1 Xmark(1) 2 Xword(2) /dev/cons 4 Xglob(1) 5 Xrdwr(2) 9 7 Xmark(1) 8 Xword(2) /fd/9 10 Xglob(1) 11 Xwrite(2) 1 13 Xmark(1) 14 Xword(2) echo 16 Xsimple(1) 17 Xpopredir(1) 18 Xpopredir(1) 19 Xreturn(1) Xrdwr /dev/cons -> fd 5 Xwrite /fd/9 -> -1 /fd/9: rc (8.out): can't open: '/fd/9' mounted directory forbids creation popredir 5, 9 broken!