Re: Future [exec] overhaul

On 7/3/08, Joe English <jenglish@...> wrote:
>
> I wrote:
>
> >     <pipeline> ::= <process> ( "|" <process> )*
> >     <process> ::= <os-command> ( <redirection> | <option> <value> )*
> >
> > where <os-command> is interpreted as a list on Unix
> > and used to build the argv array passed to exec*();
> > and as a string on Windows, used as the lpCommandLine
> > argument to CreateProcess().
>
> Forgot to add: we should also provide utility commands
> to construct an appropriate lpCommandLine string from an
> argv list (i.e., make BuildCommandLine() available
> as a Tcl command.)

Hmmm, why bother exposing a lower layer (lpCommandline) if the
overwhelming case is the higher one (list) ? Only very specific cases
would prefer to craft their own quoting and escaping... and these are
already doable with [exec cmd /c].

Moreover this would expose platform differences more at the script
level, while Tcl so far does a great job of hiding irrelevant
details... Should  a syscall API bubble up to the script level ?

> Some more needed -options: "-cwd" and "-environ".
> Right now these are process-global (controlled by [pwd]
> and the magic $::env variable), so it's impossible
> to run a subprocess in a different directory and/or
> a modified environment in a thread-safe way.  And
> even nonthreaded it takes more work than it ought to.

Agreed for -cwd.
For -environ, what's the status ? I remember a discussion on c.l.t
where we considered weakening the coupling between ::env() and the OS.
Basically turn it back into a vanilla array, and take a snapshot a
fork time. This would ease both threaded and nonthreaded (performance)
issues. Any update ?

-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