From: Alexandre F. <ale...@gm...> - 2008-07-03 22:30:07
|
On 7/3/08, Lars Hellström <Lar...@re...> 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. :-) :-) > 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. Who said we should fail to document it ? > If in some case the sh behaviour is hard to explain, then a clean break can > be preferable. That's a big If. Do you have something specific in mind ? > 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". 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). And we can even satisfy both sh-purists and worshippers of the Tcl Way (Thou Shalt Not Shimmer) by allowing simultaneously ... 2>& $ch and ... 2>&$ch just as we do today in [exec]. Now if a majority around this table prefers "@" instead of "&" here, it could also make sense. I'm undecided here too. -Alex |