Re: Future [exec] overhaul

Alexandre Ferrieux wrote:

> In a future TIP I will propose a new, extended [exec] [...],
> 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:
  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I like.

>      exec2 {foo > <} | {bar | |}
>  (2) Get rid of complicated legacy rules regarding the scope and
> semantics of redirection.

I like.

> These include the csh-style >&, the
> global-scope 2>, the special case 2>@1, and the recent -ignorestderr.

Yes yes.  These fill a much-needed gap.

> All this to be forgotten in favour of the clean, symmetric syntax of
> the Bourne shell: [...]

Yes yes yes.

>  (3) Generalize on unix to fds above 2 as in Bourne shell and as shown
> in the TIP under section "Directions for future work":
> [...]

Oh yeah.

>  (4) Give a means to get the exit status at the end of an [exec2 > &].

This is needed too; but here's where the design gets murky IMO.

> 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).

My preferred solution would be a callback: [exec2]
would take a -command option (after each process) that
specifies a script prefix (or better: a command prefix)
that will be evaluated when the process in question exits,
appending (or lappending) the exit code (and maybe the PID
or whatever else is useful) before evaluation (or invocation).

This can be implemented in a number of ways -- SIGCHLD handler +
Tcl_AsyncMark, periodic nonblocking waitpid()s called from
an EventSource, a patch to Tcl_ReapDetachedProcs, etc., --
not sure which would work best -- but I definitely think
a callback -- "tell me when the process has exited and why" --
is the best way to go.

I have some design notes on this topic lying around somewhere.
Will dig them up and try to describe in a more comprehensible manner 
what I had in mind.  But for now: +1 on all four points above.  

--JE

-------------------------------------------------------------------------
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