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. 



> 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

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