Future [exec] overhaul

On 7/2/08, Jeff Hobbs <jeffh@...> 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

-------------------------------------------------------------------------
Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
Studies have shown that voting for your favorite open source project,
along with a healthy diet, reduces your potential for chronic lameness
and boredom. Vote Now at http://www.sourceforge.net/community/cca08