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.

I personally find the >|& combinations rather cryptical. I suppose they 
need to consist of funny characters in a shell since they have to be 
syntactically special, but in [exec2] they could just as well be 
ordinary words, could they not? (Problem is perhaps that we're so used 
to the cryptic characters that we don't know which words they would 
correspond to.)

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

Do you have a grammatic principle for the sequence of [exec2] 
arguments? One possible interpretation of the above would be

   <exec2 command> ::= "exec2" <pipeline>
   <pipeline> ::= <os command> | <pipeline> <modifier>

where the <modifier>s occuring above are:

   "2>&1"              (one argument)
   "|" <os command>    (two arguments)
   "2>&" <channel>     (two arguments)

A different kind of <modifier> could then be

   "atexit" <command prefix>

to specify an at-exit callback, as discussed by JE.

That some <modifier>s is one word and others two feels a bit 
inconsistent -- an alternative is that all of them are two arguments, 
so that "2>&1" would rather be ">& {2 1}" -- but perhaps convenience 
will dictate otherwise.

As for the commmand name itself, [file exec] seems reasonable -- [exec] 
requires file names for all the executables, so it has a [file] 
connection -- although people who don't spell out [file executable] 
might not agree.

Lars Hellström

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