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.

Before growing a solution, can you describe the problem more precisely ?

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

Out of experience, yes.

If you want proof that sh is a scripting language and csh is a bag of
worms, count how many unices use csh in their init/install/whatever
scripts.

On a more factual level, the Bourne command

     foo > a 2> b

is impossible to write (without forking extra children) in csh.

For me that's way enough to just forget about the poor thing.

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

As usual, there's a balance to strike between conciseness and readability.
If we were starting from scratch we could say

    exec2 $l1 -redir 2 chan $ch1 -pipe $l2 -redir 1 file $fn

but as it turns out, an awful lot of peopel actually know about the
Bourne shell, and by genetic proximity that subpopulation has a pretty
high overlap with Tclers, so I' d be bold enough to assume that

    exec2 $l1 2>& $ch1 | $l2 > $fn

would be just as readable (euphemism).

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

Again, there's a delicate cursor. By staying really close to the
Bourne syntax we have a strong guideline with 30(?) years of life, and
no known shortcomings. It is not inconsistent, it is just not a
fixed-width, positional language.

On the other hand, if we endorse a clear divorce from Bourne syntax,
your proposal is beautiful. At this point I'm undecided.

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

OK, I like green paint too 

-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