gmane.comp.lang.tcl.core

Alexandre Ferrieux | 2 Jul 23:45

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

(Continue reading)

Larry McVoy | 2 Jul 23:51

Re: Future [exec] overhaul

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

(Continue reading)

Alexandre Ferrieux | 2 Jul 23:55

Re: Future [exec] overhaul

On 7/2/08, Larry McVoy <lm@...> wrote:
>
> Great start!
>
> Is there any reason to keep the exec name?  You have no idea how many times
> I've heard "tcl, the only language where exec doesn't".

That one is funny, if unfair :)

>  What would be
> wrong with calling it system, like system(3).  We've written a system
> clone that doesn't use sh but supports much of the shell syntax you
> describe above.

I'm open to any name of course. I have a slight bias against [system]
because, by analogy with libc's system(), its most intuitive
interpretation would be to use /bin/sh, not emulate it... Anyway,
let's not paint the bikeshed that early in the design process 

-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

Larry McVoy | 2 Jul 23:58

Re: Future [exec] overhaul

On Wed, Jul 02, 2008 at 11:55:51PM +0200, Alexandre Ferrieux wrote:
> On 7/2/08, Larry McVoy <lm@...> wrote:
> >
> > Great start!
> >
> > Is there any reason to keep the exec name?  You have no idea how many times
> > I've heard "tcl, the only language where exec doesn't".
> 
> That one is funny, if unfair :)

I thought it was funny the first time.  It gets old quickly.  But those
folks have a point, why pick a name that is well understood to do one
thing and have it do another thing?  Kind of in line with your intuitive
comment below.

> >  What would be
> > wrong with calling it system, like system(3).  We've written a system
> > clone that doesn't use sh but supports much of the shell syntax you
> > describe above.
> 
> I'm open to any name of course. I have a slight bias against [system]
> because, by analogy with libc's system(), its most intuitive
> interpretation would be to use /bin/sh, not emulate it... 

We've been pretty happy with ours even though it doesn't fork /bin/sh.
And the nice thing is it works when there is no /bin/sh (winblows).
--

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

(Continue reading)

Alexandre Ferrieux | 3 Jul 00:04

Re: Future [exec] overhaul

On 7/2/08, Larry McVoy <lm@...> wrote:
>
> why pick a name that is well understood to do one
> thing and have it do another thing?  Kind of in line with your intuitive
> comment below.

Indeed.

> We've been pretty happy with ours even though it doesn't fork /bin/sh.
> And the nice thing is it works when there is no /bin/sh (winblows).

Hmm, a "portable" [system] could spawn /bin/sh -c in unix and cmd /c
in winblows... But I admit this is so trivial to do in script that it
is off-topic for this discussion.

So, I'll accept any name you want for this. Now to the semantics. Any
other ideas, or criticism of the ones I proposed ?

-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

Larry McVoy | 3 Jul 00:12

Re: Future [exec] overhaul

On Thu, Jul 03, 2008 at 12:04:02AM +0200, Alexandre Ferrieux wrote:
> Hmm, a "portable" [system] could spawn /bin/sh -c in unix and cmd /c
> in winblows... But I admit this is so trivial to do in script that it
> is off-topic for this discussion.

You really don't want to do cmd /c, the two shells are way too different.
What we did is make a fair amount of the shell parsing be internal so
that we could spawn pipelines, redirect files, etc.  We were also 
careful to spot and barf on shell constructs we didn't support.
For our needs, it's been great.  And better perf than going through sh.

> So, I'll accept any name you want for this. Now to the semantics. Any
> other ideas, or criticism of the ones I proposed ?

I didn't look at all of them carefully but the approach of creating a
system() like interface is very nice.  In tcl, I'd ask for a way that
you could do

	set stdout [system echo $foo]

We have a backtick() api that does that for us.  Quite pleasant.
--

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

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

(Continue reading)

miguel sofer | 3 Jul 03:46

Re: Future [exec] overhaul

Larry McVoy wrote:
> On Thu, Jul 03, 2008 at 12:04:02AM +0200, Alexandre Ferrieux wrote:
>> Hmm, a "portable" [system] could spawn /bin/sh -c in unix and cmd /c
>> in winblows... But I admit this is so trivial to do in script that it
>> is off-topic for this discussion.
> 
> You really don't want to do cmd /c, the two shells are way too different.
> What we did is make a fair amount of the shell parsing be internal so
> that we could spawn pipelines, redirect files, etc.  We were also 
> careful to spot and barf on shell constructs we didn't support.
> For our needs, it's been great.  And better perf than going through sh.

Is what you did a Tcl command? Ever thought of maybe contributing a tip+patch? 
Or even just a patch that we could use for inspiration?

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

Larry McVoy | 3 Jul 04:02

Re: Future [exec] overhaul

On Wed, Jul 02, 2008 at 10:46:31PM -0300, miguel sofer wrote:
> Larry McVoy wrote:
> >On Thu, Jul 03, 2008 at 12:04:02AM +0200, Alexandre Ferrieux wrote:
> >>Hmm, a "portable" [system] could spawn /bin/sh -c in unix and cmd /c
> >>in winblows... But I admit this is so trivial to do in script that it
> >>is off-topic for this discussion.
> >
> >You really don't want to do cmd /c, the two shells are way too different.
> >What we did is make a fair amount of the shell parsing be internal so
> >that we could spawn pipelines, redirect files, etc.  We were also 
> >careful to spot and barf on shell constructs we didn't support.
> >For our needs, it's been great.  And better perf than going through sh.
> 
> Is what you did a Tcl command? Ever thought of maybe contributing a 
> tip+patch? Or even just a patch that we could use for inspiration?

It's not tcl, it's C, it's part of the BK runtime.

Yes, I have thought about contributing it but every time I've run something
up the flag pole here it has been shot into the ground.  Maybe you guys 
should reconsider who is "abrasive".
--

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

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

(Continue reading)

Donal K. Fellows | 3 Jul 01:45

Re: Future [exec] overhaul

Larry McVoy wrote:
> We've been pretty happy with ours even though it doesn't fork /bin/sh.
> And the nice thing is it works when there is no /bin/sh (winblows).

Firing off /bin/sh as a subprocess is no big deal. When I'm in a
situation where I'm exposing some scripting capability to users without
giving them full Tcl (or Perl, or whatever) I'll often use /bin/sh since
then they can use a syntax that they're used to. As a plus, the overhead
is pretty small; shell scripts start up processes all the time and
nobody's too worried about that. I'd do the same on Windows, except
there users tend to know one end of a shell from the other...

Donal.

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

Larry McVoy | 3 Jul 03:13

Re: Future [exec] overhaul

On Thu, Jul 03, 2008 at 12:45:12AM +0100, Donal K. Fellows wrote:
> Larry McVoy wrote:
> > We've been pretty happy with ours even though it doesn't fork /bin/sh.
> > And the nice thing is it works when there is no /bin/sh (winblows).
> 
> Firing off /bin/sh as a subprocess is no big deal. 

It's about 3x the cost of fork+exec on Linux, which has the best
numbers around.  Try it on windows or macos or solaris and it's worse.
So firing off a shell for some stuff is no big deal, firing off shell
to run something small can hurt if you do it a lot.

And when you are on windows with no shell?

I'm not against /bin/sh, I code in shell scripts all the time.  But
for a [system] interface you mostly don't need sh, you can emulate
the bits people use cheaply and it is much lighter weight.
--

-- 
---
Larry McVoy                lm at bitmover.com           http://www.bitkeeper.com

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

Joe English | 3 Jul 07:56

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

(Continue reading)

Alexandre Ferrieux | 3 Jul 09:47

Re: Future [exec] overhaul

Hello Joe,

On Thu, Jul 3, 2008 at 7:56 AM, Joe English <jenglish@...> wrote:
>
> 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).

OK, so a dedicated script-level signal handler. I like it.

> 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 think on unix the first one is the way to go (Tcl_AsyncMark was
invented exactly for this kind of task; periodic tasks would be an
ugly first-of-a-kind; and Tcl_Reap* is currently called at too coarse
a grain ([exec] and [close] IIRC, and not in the event loop).

On Windows I assume one must add the process handle to
WaitForMultipleObjects, which relates to adding an event source...

> I have some design notes on this topic lying around somewhere.
> Will dig them up and try to describe in a more comprehensible manner

(Continue reading)

Lars Hellström | 3 Jul 13:34

Re: Future [exec] overhaul

Alexandre Ferrieux skrev:
>  (1) Fix the impossibility to pass > < | etc. as isolated arguments.
> This will be done by passing whole commands as sublists:
> 
>      exec2 {foo > <} | {bar | |}

As I understand it, there is a problem (orthogonal to the actual [exec] 
  syntax) in Windows in that the programs don't get a list of 
arguments, but only a "command-line" string which they have to parse 
themselves (and therefore they do so inconsistently). On that platform 
Tcl consequently needs to quote the arguments (and because of the 
inconsistencies doesn't always succeed). Do you plan to address that 
issue as well?

I suppose the basic approach would be to leave room in the [exec2] 
syntax for explicitly specifying a "quoting scheme" to be applied. A 
more cross-platform approach (if otherwise the same [exec] invocation 
can be used on both Unix and Windows, which I'm not sure about) could 
be to have a global table that maps executables to quoting schemes.

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

Out of ignorance (I'm using csh in terminal, and tclsh for anything 
complicated), I wonder: Is it generally agreed that the Bourne shell 
has a clean symmetric syntax in this area? If so, then fine.

(Continue reading)

Alexandre Ferrieux | 3 Jul 15:40

Re: Future [exec] overhaul

On Thu, Jul 3, 2008 at 1:34 PM, Lars Hellström
<Lars.Hellstrom@...> wrote:
> Alexandre Ferrieux skrev:
>>
>>  (1) Fix the impossibility to pass > < | etc. as isolated arguments.
>> This will be done by passing whole commands as sublists:
>>
>>     exec2 {foo > <} | {bar | |}
>
> As I understand it, there is a problem (orthogonal to the actual [exec]
>  syntax) in Windows in that the programs don't get a list of arguments, but
> only a "command-line" string which they have to parse themselves (and
> therefore they do so inconsistently). On that platform Tcl consequently
> needs to quote the arguments (and because of the inconsistencies doesn't
> always succeed). Do you plan to address that issue as well?

See BuildCommandLine in tclWinPipe.c.
As you said, it is orthogonal to the exec/exec2 axis, since with
today's [exec] the arguments are already in a list to be glued
together by this function (adding quotes if needed, etc).
Moving the arglists one level down (sublists) doesn't change the
picture, and certainly doesn' t add new problems (do you have one in
mind ?), while it does remove those like

  DOS PROMPT>   foo a ^| b ^| c ^| d
  EXEC> (impossible apart from cmd /c {...})
  EXEC2>   exec2 {foo a | b | c | d}

> I suppose the basic approach would be to leave room in the [exec2] syntax
> for explicitly specifying a "quoting scheme" to be applied.

(Continue reading)

Donal K. Fellows | 3 Jul 15:51

Re: Future [exec] overhaul

Alexandre Ferrieux wrote:
> See BuildCommandLine in tclWinPipe.c.

The last person to substantially hack around with that was (IIRC) David
Gravereaux. The word "hack" is accurate in that sentence.

Donal.

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

Lars Hellström | 3 Jul 23:08

Re: Future [exec] overhaul

Alexandre Ferrieux skrev:
> On Thu, Jul 3, 2008 at 1:34 PM, Lars Hellström
> <Lars.Hellstrom@...> wrote:
>> Alexandre Ferrieux skrev:
>>>  (1) Fix the impossibility to pass > < | etc. as isolated arguments.
>>> This will be done by passing whole commands as sublists:
>>>
>>>     exec2 {foo > <} | {bar | |}
>> As I understand it, there is a problem (orthogonal to the actual [exec]
>>  syntax) in Windows in that the programs don't get a list of arguments, but
>> only a "command-line" string which they have to parse themselves (and
>> therefore they do so inconsistently). On that platform Tcl consequently
>> needs to quote the arguments (and because of the inconsistencies doesn't
>> always succeed). Do you plan to address that issue as well?
> 
> See BuildCommandLine in tclWinPipe.c.
> As you said, it is orthogonal to the exec/exec2 axis, since with
> today's [exec] the arguments are already in a list to be glued
> together by this function (adding quotes if needed, etc).
> Moving the arglists one level down (sublists) doesn't change the
> picture, and certainly doesn' t add new problems (do you have one in
> mind ?), while it does remove those like
> 
>   DOS PROMPT>   foo a ^| b ^| c ^| d
>   EXEC> (impossible apart from cmd /c {...})
>   EXEC2>   exec2 {foo a | b | c | d}
> 
>> I suppose the basic approach would be to leave room in the [exec2] syntax
>> for explicitly specifying a "quoting scheme" to be applied.
>

(Continue reading)

Alexandre Ferrieux | 4 Jul 00:30

Re: Future [exec] overhaul

On 7/3/08, Lars Hellström <Lars.Hellstrom@...> wrote:
>
> not all Windows programs use the same rules when parsing command lines,
> so a quoting that works for one program may be horribly wrong for
> another. That's the "inconsistency" part above. The cure would be to
> adapt the quoting scheme to the program.

OK.

> A minimal solution (inspired by posting by JE) is a <modifier> that
> means: If $tcl_platform(platform)=="windows", then that <os command>
> back there is not a list of arguments, it is a raw command string. One
> could also imagine that the <os command> to command-string conversion
> is always done by a callback, and the modifier changes this from a
> default.

*That* is much better !
This way we can keep the uniform, list-based, everything-is-argv
allowing to portably say [list foo {*}[glob ...]] (even with spaces in
some filenames), and have your "safety valve" option to pass directly
a string (basically cmd /c but without an extra fork). I like.

> though. "No known shortcomings" is what I wanted to hear.
> ...
> Most people who know Bourne shell syntax are Tclers? :-D Good news! Or
> perhaps not, since reportedly we are comparatively few. Or perhaps you
> took this relation to be symmetric?  Guess I was right to ask for
> verification of the "clean symmetric syntax" part, then.

(Continue reading)

Gustaf Neumann | 4 Jul 10:29

Re: Future [exec] overhaul

Alexandre Ferrieux schrieb:
> Yes, that's what I had in mind with "2>& $ch". It is the most natural
> extension of the Bourne syntax to work with Tcl channels, since
> basically it replaces a numeric file descriptor with a channel
> (fortunately channel names are never raw numbers).
>   

a next generalization would be to allow "stderr >& $ch", since "2" is 
not used elsewhere
in tcl, since it looks less cryptical

-gustaf neumann

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

Joe English | 3 Jul 19:12

Re: Future [exec] overhaul

Lars.Hellstrom wrote:
>
> As I understand it, there is a problem (orthogonal to the actual [exec]
>   syntax) in Windows in that the programs don't get a list of
> arguments, but only a "command-line" string which they have to parse
> themselves (and therefore they do so inconsistently). On that platform
> Tcl consequently needs to quote the arguments (and because of the
> inconsistencies doesn't always succeed). Do you plan to address that
> issue as well?

One approach is to just do things differently on Windows
and on Unix:

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

On Unix, the first element of the list would also be used as the 
"file" argument to exec*p(); on Windows we could parse out
the lpApplicationName argument using the same algorithm
that CMD.EXE does.

--JE

-------------------------------------------------------------------------

(Continue reading)

Joe English | 3 Jul 19:29

Re: Future [exec] overhaul


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

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.

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

(Continue reading)

Alexandre Ferrieux | 3 Jul 21:47

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

(Continue reading)

Andreas Leitgeb | 3 Jul 23:34

Re: Future [exec] overhaul

"Alexandre Ferrieux" <alexandre.ferrieux@...> wrote:
> 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.

Some year ago I proposed a new option to classic exec, that would
cause some special quote-char to be eaten away from each arg that
starts with it. 
The proposed syntax was really ugly, but it solved problem (1).
I didn't ever TIP it, because I found it so ugly, myself.  Anyway,
it might still be reconsidered, as a low-level building block for
a high-level  exec2 (painted whichever color), which then could be
done in pure tcl based on old exec with that quote-extra.

If you don't remember it, here's an abstract:
  exec -quoted  echo '<hello> '| ''blah' >foo
would end up writing the literal string:
<hello> | 'blah'
into file foo. There are of course a couple of different colors
available for painting the option's name.

The trick would be, that a first round parses all the usual 
exec magic arguments, skipping all those starting with that 
quote-char, since it is not magic to exec. Then, just before
really executing the command, it would strip at most one 
quote-char from each argument, thus making it possible to
also have arguments starting with that quote-char.

(Continue reading)

Return

Return to gmane.comp.lang.tcl.core.

Advertisement

Project Web Page

Tcl Core Team discussions about Tcl development

Search Archive

Language

Change language

Options

Current view: Threads only / Showing only 20 lines / Not hiding cited text.
Change to All messages, whole messages, or hide cited text.

Post a message
NNTP Newsgroup
Classic Gmane web interface
XML

XML

RSS Feed
List Information

About Gmane