From: Alexandre F. <ale...@gm...> - 2008-07-02 21:46:14
|
On 7/2/08, Jeff Hobbs <je...@ac...> wrote: > Donald G Porter wrote: > > Jeff Hobbs wrote: > >> TIP #304: A Standalone [chan pipe] Primitive for Advanced Child IPC > >> http://tip.tcl.tk/304 > > > > If this is already answered in the TIP, just point me back there. > > > > Hoping someone can summarize which items on the long list of > > defects in [exec] get addressed by this, and which do not. > > I don't think it hits all the issues, but the "Additional Benefits" > section does discuss some ramifications for [exec], as well as future > work possibilities. I don't think the TIP author should be accountable > for covering things not dealt with (that would be a very, very long > list). ;) Thanks Jeff. Now since I have already thought about this, I may share a few ideas here :) So I changed the subject. In a future TIP I will propose a new, extended [exec] (all options are still open as to the script API: [exec -extended], [exec -list], [exec2], you name it...), with the following main targets: (1) Fix the impossibility to pass > < | etc. as isolated arguments. This will be done by passing whole commands as sublists: exec2 {foo > <} | {bar | |} (2) Get rid of complicated legacy rules regarding the scope and semantics of redirection. These include the csh-style >&, the global-scope 2>, the special case 2>@1, and the recent -ignorestderr. All this to be forgotten in favour of the clean, symmetric syntax of the Bourne shell: [exec foo 2>@1] --> [exec2 foo 2>&1] [exec foo |& bar] --> [exec2 foo 2>&1 | bar] (impossible) --> [exec2 foo 2>& $ch1 | bar 2>& $ch2] [exec foo 2>@ stderr] --> [exec2 foo] [exec -ignorestderr foo] --> [exec2 foo] (notice that I chose >& instead of >@ for two reasons: (1) to mark the Bourne Shell heritage and (2) to avoid too easy copy/paste confusions with old [exec]) (3) Generalize on unix to fds above 2 as in Bourne shell and as shown in the TIP under section "Directions for future work": (impossible) --> [exec2 foo 3>& $ch1 | bar 4<& $ch2] (4) Give a means to get the exit status at the end of an [exec2 ... &]. One possibility is a simple, synchronous [waitpid], assuming that by listening to one of its output descriptors one is able to have a reasonable notification of when a [waitpid] would not block for too long (which would be defeated by a [close stdout] in the child). A more advanced option is to create a pseudo-channel who would fire a fileevent readable on SIGCHLD. A third one would be a Tcl_AsyncMark-based script-level signal handler (for SIGCHLD among others). Thanks for any comments on these ideas. -Alex |