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.
> 
> Before growing a solution, can you describe the problem more precisely ?

Never having used [exec] on Windows myself, I'm just reporting hearsay 
(http://wiki.tcl.tk/16336), but the problem as I understood it was that 
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.

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. It is probably too ugly to make the basic [exec2] call look like

   exec2 [BuildCommandLine {foo bar \n baz}]

on Windows; better is

   exec2 {foo bar \n baz} quotedby BuildCommandLine

with a suitable default for quotedby.

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

That answer is "sh is much better than csh", but my question was "is 
there anything in the sh model that /doesn't/ work right?" You sort of 
answered it further down by saying

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

though. "No known shortcomings" is what I wanted to hear.

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

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. 

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

Yes, but documenting a new command as "this works just as in a Bourne 
shell, see sh(1) for the details" is a mistake in a language as 
portable and simple as Tcl. No need to repeat the old mistake of 
documenting math functions by the sentence "Each of these functions 
invokes the math library function of the same name; see the manual 
entries for the library functions for details on what they do." If in 
some case the sh behaviour is hard to explain, then a clean break can 
be preferable.

  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.

Perhaps a combination is optimal: "cryptic" character combinations work 
*exactly* as in the Bourne shell, Tcl innovations follow Tcl rules for 
naming things. There in no guarantee that all Bourne shell 
constructions are supported.

Only catch is, redirection to channels (rather than redirections to 
named files) is a Tcl innovation, is it not? So the rule breaks down 
immediately.  Unless one allows some legacy constructions as 
"according to Tcl rules, although cryptic".

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