Tcl's "exec" command is ... I quote Cameron Laird: > One thing that is grossly underappreciated is how well > [exec] and [open] (and [bgexec]!) work across Unix and > Win*. Unless you've lived through it, you can't imagine > how much pain people working with other languages endure > to > exec $myprocess << $some_input > or > open |$myprocess r+ > In fact, the reality continues (in 2001!) to be that > several leading languages just give up on proper semantics > for Win*, because they believe the problems are insur- > mountable. But still, exec has one bad shortcoming, that is nearly impossible to come by: * because the meta-arguments for redirection are mixed with normal arguments (for the external command), it is impossible(!) to pass a normal argument which looks like a redirection. This goes as far as that it is impossible to pass a string starting with a `<' or '>' character. * because exec wants the command line spread out argument by argument, it is quite a pain (involving eval and all lots of extra [[list]-protection of the other arguments) to include a Tcl-list as part of the argument list. Example: % exec /bin/echo "" couldn't read file "hallo>": no such file or directory % A more practical example (someone posted it on c.l.t) % exec gvim --remote-send Actually, there is a unix-only workaround: % exec sh -c {gvim --remote-send ''} but this involves one extra shell to be invoked, and puts you into the hell of quoting for tcl and quoting for sh ... ---- 29-jul-03 Note: Due to recent announcements, some of the stuff below soon becomes obsolete. * A patch was announced, to compatibly solve the problem inside "exec", using a new option "-quote". * Some activity about argument-expansion has come up. (TIP 144) Extended APIs as proposed below can then be implemented as wrapper-procedures to the new enhanced "exec". ---- 24-feb-05 [SLB] well the limitations of [exec] remain an issue for some of us. I've made a stab at tackling this and submitted it as [TIP] [http://www.tcl.tk/cgi-bin/tct/tip/240.html] ---- To work towards a real solution of this problem, I've proposed an alternative API to the awesome work that made exec possible. !! I do NOT propose removal nor (incompatible) modification of "exec" !! Now, there are generally a few possible ways to do it: * Use the same bourne-shell-like syntax, but add a way to distinguish the redirection-arguments from normal arguments. * Invite a new syntax for redirection that is more tcl'ish, by consisting more of readable words than character sequences. These items are discussed in the next few sections below. To me it looks pretty impossible to do it with compatible changes to exec, which means that for compatibility-reasons we won't get around making this a new command. My original suggestion for the new command name was 'pipe', but in a mail someone expressed a dislike for this name and suggested 'run' / 'bgrun' instead. I could live with these, too :-) ---- Preserving bourne shell syntax: file, >>file , >&2, 2>&1, |, ... The simplest way would be to define one marker-argument, e.g. a single or double dash "-", which would remove any meta-syntax meaning of the next argument: % pipe /bin/echo - "" - - >file would then write the string " -" to the file named "file". (the doublequotes are actually redundant here, but improve readability) Although it looks very close to current exec-syntax, it is not compatible; especially not design-bug compatible :-) Pro: easy to implement, and the result is safe. Con: the syntax is even obscurer than before. ---- More Tcl'ish syntax: Like above section, but all the somewhat cryptic symbols are replaced by dash-option (some of them with arguments): % pipe /bin/echo "" - - -outtofile file The ""-strings needs no more protection, the single dash (the second one!) is protected by the preceding one, and -outtofile specifies where the program's stdout should go to. Pro: still easy to implement (& safe); clearer meaning, better readability Con: Tendence to over-verbosity; a whole large bunch of options to learn. It should also be possible to mix them, allowing both "