[MJ] - Triggered by a discussion on Tcl chat, this page discusses possible replacements for exec. Describe problems with exec here: * piping * quoting '''Chat discussion''' Below the chat discussion (stripped) with some interesting ideas. I will try to make a summary of all this. [00:26] sergiol i am remembering the mess i had when do a exec of gs with < 's and >'s in its args [00:26] LucMove Tcl does have these little flaws in syntax. They are the main reason I still have to look at the manual from time to time - or test the line in Tkcon and see if it throws an error. [00:27] kbk sergiol - < and > in [exec] are *major* flaws. widthxheight±x±y is a nit by comparison, because it doesn't prevent any work from getting done. [00:28] kbk LucMove - Or rather, certain commands have flaws in the syntax of their little languages. [00:29] sergiol is donnable that when exec arg has quotes ("") it will escape only $ for vars and \ for escape chars? [00:30] No. exec does not know the quoting of its arguments. [00:30] dkf_ If you insist on not using tclInt.h, there's always Tcl_Eval [00:30] That would *really* be inconsistent with the rest of the language. [00:30] sergiol i am saying modifying the source of the command [00:31] sergiol no Cameron [00:31] sergiol exec is still the inconsistent thing [00:32] sergiol any other command of tcl treats > has a nomral char [00:32] sergiol normal [00:32] sergiol exec treats it as a redir operator [00:32] dkf_ wanted - a way of setting up redirections that doesn't use shell-like <> chars [00:33] sergiol dkf_ may be we should a VBish syntax? [00:34] dkf_ you're the one doing the work, you choose [00:35] sergiol look at this command [00:35] sergiol if {![catch {exec /etc/alternatives/gs -sPAPERSIZE=a4 -dFirstPage=$pagInicial -dLastPage=$pagFinal -sDEVICE=$aparelho -SOutputFile=$ficheiroPCL -dBATCH -dQUIET -dNOPAUSE -c " << /Duplex $flagDuplex >> setpagedevice" -f $ficheiroPDF}]} { [00:35] kbk sergiol - Just as expr (and friends) treats * as multiplication, regexp (et cetera) treats it as Kleene closure, glob (and such) treats it as arbitrary-length string matching, and everything else says it's just a character. [00:36] sergiol you even helped me with this command, dkf [00:36] kbk sergiol - Yes. We understand. The problem isn't that < is special, it's that [exec] provides no way to escape it... and can't be fixed without breaking existing uses. [00:37] sergiol kbk : may be passing it a -noquote parameter is a good approach? [00:37] kbk What we more need is something like [newexec -infile wherever -outchannel wherever -errfile wherever -- command args] [00:37] dkf_ Those that hunt alligators get to choose their favoured weapons [00:37] mjanssen kbk: would there be any interest for this -noquote switch for exec which shouldn't break existing usage, because I have at least a working windows implementation already? [00:38] kbk ,,, along the lines of blt_bgexec with slightly more tclish syntax (and foregroundability). [00:38] dkf_ mjanssen: there would be interest [00:38] kbk mjanssen - It's *unlikely* to break existing usage - but remember that [exec] doesn't take -args currently - {-noquote} is a perfectly good command name. More's the pity. [00:38] sergiol but this would'nt allow to have both redirection and translineation in same command [00:39] dkf_ [exec] does take options [00:39] sergiol i don't know how to call it "simple interpreting" ? [00:39] mjanssen anyone cominng up with -noquote as a command name has different problems [00:39] dkf_ being -keepnewline and -- [00:40] sergiol yes i know that [00:40] * kbk slaps forehead - so we already broke it. [00:40] kbk In that case... [00:40] mjanssen so exec -- $cmd would still work if $cmd == -noquote [00:40] dkf_ the paranoid does [exec -- $whatever] [00:40] sergiol format c: ? [00:41] sergiol the vbish syntacx i said was parametrization [00:41] dkf_ *and* that is a feature that dates back at least as far as Tcl 7.3 [00:41] kbk In that case, as I was saying... replace <, <<, <@ with -options before the --, and add -noredirect (or some such option) [00:41] dkf_ It's in the JO book [00:42] kbk ... and replace >, >>, >@ similary... [00:42] dkf_ [exec] is eminently fixable [00:42] dkf_ OTOH, [open |...] is trouble [00:43] sergiol like set cmd "ls -la @p1 " [00:43] kbk Hmm, have a version of [exec] that returns a list of channel handles for anything that wasn't redirected? [00:44] kbk sergiol - dkf is right, I forgot that we messed with [exec] a long time ago. So it *is* fixable. [00:45] Uh-oh--I hadn't thought of the problems with [open]. Fiddlesticks. More thought required. [00:45] mjanssen main problem with exec I encountered when adding -noquote is that it goes through a lot of different functions before actually calling the executables so the -noquote option was kind of an ugly hack. That's why I ditched it and use TWAPI instead. [00:46] sergiol the VB ish syntax i said is something like set cmd "gs @p1 2>&1" addparameter cmd @1 "<< /Duplex $flagDuplex >>" exec $cmd [00:47] sergiol /me's gs command was for demo puposes only [00:47] kbk Hmm, [open] is neither the only command that creates a channel nor the only command that creates a pipeline. [00:47] rfoxmich sergiol - how do you distinguish between $cmd built up by addparameter and just any old variable? [00:47] rfoxmich this is very untclish. [00:47] kbk sergiol - We have a *strong* preference for EIAS. [00:47] rfoxmich EHASR ? [00:47] sergiol and it is a string [00:47] rfoxmich (Everything Has A String Representation) [00:47] dkf_ EIAS, even if it doesn't [00:48] kbk Everything Is A Stork [00:48] dkf_ Everything is a string, even if it isn't right now [00:48] sergiol the substitution would be done only when addparameter [00:48] kbk Subsitution isn't a property of a command. It's done uniformly. [00:49] dkf_ That's Tcl's great strength [00:49] rfoxmich See the 11 rules of Tcl [00:49] rfoxmich (man Tcl) [00:49] * jenglish back, catching up [00:49] sergiol I THINK YOU DID'NT UNDERTAND MY APPROACH [00:50] kbk Please don't shout. [00:50] mjanssen exec -out nextchannel ls ; exec -in nextchannel grep tcl ; seems doable [00:50] dkf_ I look forward to seeing code [00:50] rfoxmich ... sounds like a song.. On the first rule of Tcl my true love gave to me scripts that are strings made up of commands. [00:50] mjanssen -out will create a new channel ; -in will read from an existing channel preferably using fileevent [00:50] dkf_ design without code is emptiness without Zen [00:51] sergiol if i execute this command without the addparemeter, the command will have to execute literally @p1 [00:51] rfoxmich And code without design is just empty. [00:51] * sergiol 's shout was incidental [00:51] kbk And in that script there was a command and in that command there was a word and in that word there were square brackets, and the green grass grows all around, all around... [00:51] dkf_ code without design is trouble [00:51] dkf_ and too d*mn common [00:52] rfoxmich Sergiol are you just saying that addparameter just understands and deal with @ specially.. what if I have an @ in a parameter? [00:52] jenglish Re: exec -noquotes -- On the face of it, I think this is a not-terribly-good idea, but since we've already stepped onto the slippery slope with [exec -keepnewline], what the hell. Might as well add it. This way lies [lsearch], but again, what the hell. [00:52] sergiol yeah it may be a kind of regsub [00:53] rfoxmich Seems like addparameter is just supposed to be a pre-processor for srings that helps you build cmd for exec.. but essentially that's what [list] does now for many many things. [00:53] mjanssen jenglish maybe noquotes is not the best name its more -noquotes-and-piping [00:53] sergiol i think the better approah is what you said [00:53] rfoxmich I'm not sure I see the gain over the syntactically much simpler approaches mentioned. [00:53] kbk jenglish - This deserves more thought. I'm wondering whether a clean break - a [newexec] with more Tclish and less Bournesque syntax is in order. [00:54] sergiol exec without any options would act has it does now [00:54] dkf_ We've been on the slippery slope since waaaay before I knew Tcl... [00:54] jenglish *My* idea is: [pipeline $argv ? _redirections_ ? "|" $argv .... ??] [00:55] has left the chat! [00:55] rfoxmich Where argv is a list of words that includes the command name as [lindex $argv 0]? [00:55] dkf_ sergiol: That's good/excellent practice, not breaking existing code. [00:55] mjanssen kbk can I suggest popen (process open) for this newexec (blatently stolen from Ruby) [00:55] kbk jenglish: But how to distinguish redirections from command args? [00:55] sergiol but with -noquote should only substitute $vars,[envolved commands] and \escaped chars [00:56] kbk sergiol - Which part of "substitution applies uniformly to all commands" didn't you understand? [00:56] mjanssen sergiol if enclosed in quotes, yes if enclosed in braces no (standard substitution behaviour) [00:56] rfoxmich Sample syntax: pipeline [list cat file.txt] > logfile.txt [00:56] rfoxmich Is that what you mean jenglish? [00:56] rfoxmich In that ase the redirections are unambiguous since the entire set of commands are the second word of the pipeline command? [00:57] sergiol i am saying this for people don't remove the current behaviour of subsitution [00:57] rfoxmich I kind of like that if so... it reminds me of what you do for -command parameters in TK callbacks. [00:57] kbk rfoxmich - I don't know if jenglish was saying that, but it looks quite promising... [00:57] sergiol and should have the options you said: -redir output, etc. [00:58] jenglish rfoxmich: Yeah, that's pretty much it. [00:58] jenglish is online (back) [00:58] kbk ... and a few options to [pipeline] could make it function as [open |...] as well. [00:58] jenglish is away (afk) [00:58] sergiol can we open a TIP with this or is desirable to have proposal code first? [01:00] dkf_ write the code first [01:00] dkf_ it's simple enough for that [01:00] sergiol ok i am beginning my tsl's source for now [01:00] dkf_ only obscenely complex stuff *needs* a TIP first [01:01] mjanssen for anyone interested the patch at http://marknet.tk/downloads/exec-quote.patch implements a -noquote option for exec on windows [01:01] * dkf_ has been the author of such things in the past [01:01] kbk This one definitely needs the code first, I agree... it's useful as an extension even if not TIPped [01:01] * Colin -keepnewline [01:01] * kbk -keep-your-damned--keepnewline [01:01] jenglish is online (back) [01:02] jenglish kbk -- re: how to distinguish redirections from command arguments -- it's by position. [01:02] sergiol dkf: i was seeing the cource of TclExecCommand [01:02] mjanssen I also have a pexec (plain execute) extension doing pretty much the same [01:02] kbk jenglish - I was enlightened by rfoxmich's example. [01:02] sergiol and people of the chat said to do not begin my learning tfrom that [01:03] rfoxmich Satori? [01:03] Colin Isn't -noquote like [subst -nocommands] ? [01:03] rfoxmich looks at the clock and dashes out the door [01:03] sergiol another thing i remembered now [01:04] Colin oh, no it's not. [01:04] mjanssen colin -noquotes sends the args after exec completely unchanged to the shell so no " escaping no redirecting nothing [01:04] kbk sergiol - It's a bad place to learn from in that it embodies several mistakes. We were saying, "don't copy from that if you're trying to learn *good* design of Tcl stuff." [01:04] sergiol the "open" commnad has an inconsistency too [01:05] kbk Yes, but in the jenglish proposal [pipeline] could replace [open "|..."] [01:05] jenglish And re: a new option to [open "| ...."] -- not needed AFAICT, my idea for [pipeline] would return a file handle with the write end connected to stdin of the first process in the pipeline and the read end connected to stdout of the last process. [01:05] * jenglish xed [01:05] sergiol the | in the file name for pipe should be at the options [01:05] * sergiol searching that TIP [01:05] kbk jenglish - Hopefuly only on request; set var [exec somecommand] is too useful to toss out. [01:06] jenglish kbk -- yes, [pipeline] is more of a replacement for [open "| ..."]. The quoting-hell-free-version-of-exec aspect is secondary. [01:06] mjanssen jenglish that takes care of piping, adding something like noquote is very useful and sometimes necessary. [01:06] Colin I don't see inconsistencies. The [open] and [exec] little languages are completely consistent with all the other [open] and [exec] syntaxes. [01:07] sergiol I don't find the TIP. [01:07] kbk jenglish - Uhm. I meant to say, that [set result [pipeline {somecommand someargs}]] would be useful. [01:07] kbk sergiol - What TIP? I'm talking about what he's informally proposing here. [01:07] sergiol ah ok [01:07] sergiol i thought that was a TIP [01:07] jenglish Hm. [01:08] patthoyts vertrekt stilletjes. [01:08] mjanssen main problem with automatic quoting is calling batch files on windows which have retarded quoting rules [01:08] * sergiol agrees [01:08] jenglish My idea for [pipeline] is that it returns a two-way channel handle ... [01:08] sergiol like "c:\Documents and settings" ? [01:09] mjanssen sergiol no in that case standard quoting in exec is fine [01:09] kbk Oh, yes, on Windows, you have to recostruct a command line when you're creating a pipeline, because Windows commands take command lines, not argc/argv [01:09] sergiol ? [01:09] kbk ... and there are several wqually broken ways to do that, you may need to offer the caller a choice. [01:09] Colin how hard would it be to write a windows_exec which did what was necessary? [01:09] Colin in ... like ... tcl [01:09] mjanssen more like that if you do some.bat a,b , some.bat will see two arguments. You have to add the quotes [01:10] mjanssen some.bat "a,b" [01:10] jenglish ... "spawn process, wait for completion, store stdout in a Tcl variable" is a useful thing to have, but I think that's adequately covered by [exec] -- modulo unquotable metacharacters. [01:10] sergiol what do you mean with "command lines"? [01:10] kbk jenglish - Right, it's the unquotable metacharacters that we have to get around. [01:10] dkf_ on unix, the low-level exec takes an array of arguments [01:10] patthoyts wanders in. [01:10] dkf_ on windows, the low-level exec takes a command line [01:10] mjanssen colin, twapi already delivers that. Doing it in tcl seems impossible to me. [01:11] dkf_ this is because on unix it is the shell that parses a command line into arguments [01:11] dkf_ and on windows, it is each and every program [01:11] jenglish Hm. ISTR more problems than just unquotable metachars with exec ... [01:11] dkf_ (or, more usually, their libc implementation) [01:11] sergiol do you mean the specific sources of the [exec] command? [01:11] * jenglish checking my notes ... [01:12] dkf_ I believe we try to generate output that is sensible when parsed with msvcrt's parsing routines [01:12] mjanssen there seems to be no universally correct and safe windows automatic quoting algoritm because of that. So please let me do it myself [01:13] jenglish Ah: problems with [exec] and [open "|..."]: (1) can't pass arbitrary argv[] (the unquotable metacharacter problem) [01:13] jenglish (2) can't pass arbitrary envp[] (the $::env voodoo problem; mostly a thread-safety issue) [01:13] kbk dkf_ : Indeed, but that means the output we generate is not sensible when parsed as arguments of a .bat file - because cmd.exe doesn't use msvcrt's parsing routines. [01:13] Colin ::env is evilly interlocked. [01:14] Colin Which metacharacters are unquotable, please. [01:14] Colin @ < and > ? [01:14] kbk and | [01:14] jenglish (3) can't usefully use e.g., `sort` in an [open |... ] pipeline [01:14] Colin Ok, that's unfortunately bad. [01:15] Colin You could do what unix always does ... @@ -> @ etc [01:15] Colin heh, >> [01:15] Colin we're screwed. [01:16] kbk jenglish: Can't usefully use `sort`? Explain? Because stderr gets interpolated with the output? [01:16] jenglish (4) redirecting FDs 2 and higher in a pipeline isn't well supported [01:16] dkf_ (3) needs partial channel closure [01:17] kbk (4) Indeed. We could add 2> file, 2>@channel 2>>var if we could make it unambiguous... [01:17] jenglish kbk -- can't use `sort` because there's no way to signal EOF without also closing the read end. [01:17] kbk ... which [pipeline] solves nicely [01:17] Colin You know, this could be obscurely related to why tcl can't replace bash. [01:17] jenglish Colin: other unquotable characters: "1", "2", and possibly other digits, when followed by another metacharacter. [01:17] dkf_ partial closure would be useful for other bidirectional channels too IIRC [01:17] mjanssen it seems extracting the piping and allowing to disable autoquoting on demand seems to cover everything [01:18] kbk Oh, you mean that you can't usefully use [open "|..." w+] because you can't half-close a channel. Yes. [01:18] Colin That is, a solution to the use case 'make tcl replace bash' may well lead to a nice solution to these exec problems. [01:19] * kbk notes time, and wonders why the *interesting* stuff always comes up when I need to leave. G'night. [01:19] Colin Night kbk. [01:20] Colin Ok. I tried to make tcl replace bash one time, and it failed miserably because native tcl syntax does not map well to bash-like uses. [01:20] jenglish and (5) Various horkage on Windows due to impedance mismatch between Unix-style argv[] and DOS-style ... whatever-it-is-that-DOS uses. (Text of command line stored at HEX 0X80 through HEX 0xFF? I have mercifully forgotten...) [01:20] mjanssen pipeline ?-noquote? command ?redirection? ?-noquote? command/file/etc looks reasonable? [01:20] Colin And the reason for that is that tcl is all about applying functions to arguments, whereas bash is about applying them to processes. [01:20] jenglish mjanssen -- with what I have in mind, there'd be no need for a -noquote option. [01:21] Colin May I suggest a different way to look at the problem? Rather than making a little language designed to emulate unix sh (however badly) ... [01:21] mjanssen jenglish why not? [01:21] Colin create a new kind of [proc] which is an executable. [01:21] sergiol what do you have in mind jenglish? [01:21] Colin So you say something like [ex /bin/sort] [01:21] jenglish Command arguments are passed to the command. Redirection directives are interpreted by the [pipeline] command. The [pipeline] command can tell which is which by where it appears in the argument list. [01:22] Colin Then invoke it in such a way as to distinguish between args passed to it, and channels available to it, and those available from it. [01:22] Colin [uniq [sort -args {-n -r -whatever}]] [01:23] Colin Just a stray 2-cup-of-coffee idea. [01:23] mjanssen jenglish but how will {something with spaces} be passed? as "some..." and if so how will {"something..."} be passed as \"some...\"? [01:23] Colin So invoking a command defined by [ex] returns a set of channels. [01:24] jenglish mjanssen: ? [01:24] Colin and all [ex] defined commands expect a set of channels, and are explicitly handed the command line and environment they want. [01:24] mjanssen I understand the piping. But what will happen with the commands? No rewriting whatsoever? [01:24] jenglish mjanssen: Right. [01:24] Colin I think that's probably maximally general [01:25] Colin although not (perhaps) generally maximal. [01:25] jenglish is away (afk) [01:26] Colin It would be sufficiently general to express [exec] and [open] in, I suspect. [01:26] mjanssen Colin, but is it still Tcl? It seems quite a change in command semantics [01:26] Colin it's not a change of tcl command semantics at all. [01:27] Colin [ex] creates a command with all the properties required. It just happens to create a process by fork/exec. [01:27] Colin the command so created does, that is. [01:27] Colin probably needs a better name [01:28] mjanssen in your example [sort -args {-n -r -whatever}] needs to return a string right, so are you saying that that string will be a list of channels? [01:28] Colin yes. [01:29] mjanssen Ok then I understand [01:29] Colin Although perhaps you could have [ex] accept arguments to just return stdout. [01:29] Colin so [ex -simple /bin/sort] might be defined to return a command which returns the result of execution as a string. [01:29] Colin And to error on any output to stderr from sort, e.g. [01:30] Colin you could also add args to [ex] to make it block, etc. [01:30] Colin to make it generate a command which blocks, that is. [01:30] Colin Or you could make it return a [future], too. [01:31] Colin Or you could have a range of such command-generating-commands, all of which have the effect of presenting an external binary as a tcl command. [01:31] Colin Sort of: think of referencing external executables like [load] references external libraries. [01:31] mjanssen so instead of adding special arguments you handle all this stuff by nested commands, neat. [01:32] Colin That's the idea. [01:32] Colin It arises because trying to modify tcl syntax to ape bash is ugly. I know, I tried. [01:32] Colin So since tcl is a general command processing language, why not try making executables into tcl commands? [01:32] Colin You certainly lose the bash-quoting hell problem. [01:33] mjanssen it does seem the return values will have to define some sort of protocol though. so if one command only returns a stdin channel and the other command returns stdin and stderr you should be able to sort both. [01:34] mjanssen or would that be an option of the command? like [sort -stdin [ls -stdout]] ? [01:34] Colin The basic problem with [exec] is, I think, that sh syntax is kind of ugly and in any case wildly inconsistent with tcl's, and uses a lot of strange meta-chars. [01:34] Colin Well, sure, you could do that. [01:35] mjanssen to make the procs generally usable I think you will have to do something like that. [01:35] Colin I should point out, I got this idea between drinking my first, and pouring my second cup of coffee. [01:35] Colin So it's not completely worked [01:36] mjanssen I am doing this discussion between my 1st and second beer so I think you're ahead of me l-) [01:36] mjanssen even [01:36] Colin It just arises from the observation that making a tclsh to replace a bash is *hard*, and that's a shame because tclsh would be great as a system tool. [01:36] dkf_ bash is convenient for interactive use [01:36] Colin And the consideration that this could be because in some sense we're drinking the bash syntax koolaid, instead of finding where tcl's syntax is cool. [01:37] Colin dkf_, yeah, and I'm suggesting that making tclsh convenient interactively would be a bigger win than merely fixing [exec], were it possible to do the former. [01:37] Colin so interactively, [unknown] would do a search and return an [ex]'d command. [01:37] sergiol there is a big problem [01:38] sergiol doing bash commands as tcl commands [01:38] tclguy is away (Automatically away due to idle) [01:39] jenglish is online (back) [01:39] sergiol if do exist commands of the same name in bash and in tcl [01:39] dkf_ I suspect bash is convenient precisely because it plays very fast and loose [01:39] Colin IOW, because it's been around so long people are used to its vagueries, Donal? [01:40] sergiol how do people distinguish them? [01:40] dkf_ it does the right thing most of the time [01:40] Colin sergiol, [rename], or a -name command to [ex] [01:40] jenglish bash is a significant improvement over the classic Bourne shell ... [01:40] dkf_ e.g. usually when I say *.tcl I mean all the files ending in .tcl [01:40] Colin I suspect you could replace [expect] [01:41] dkf_ bash's improvements over conventional bourne shell are almost purely in the interactive arena [01:41] Colin Yeah, that's true. [01:42] dkf_ tcl's improvements over conventional bourne shell are almost purely in the non-interactive arena [01:42] jenglish dkf_: I was thinking more about $( .... ) vs. ` ... ` -- bash syntax for this is composable, /bin/sh syntax is not. [01:42] dkf_ jenglish: OK, that's one of the improvements that is nice [01:43] dkf_ but isn't it from shell standardization? [01:43] tclguy is idle (Automatically away due to idle) [01:43] dkf_ part of the POSIX effort? [01:44] Colin whether bash's improvement over ksh over sh is purely in interactivity doesn't really counter the argument that tclsh is not properly positioned to eat bash's lunch where it counts - in system scripts. [01:45] dkf_ the only real problem there is [exec] [01:46] Colin dkf_, disagree. The real problem is that bash is a language for passing 'round pipelines, whereas tcl is a language for invoking commands. [01:46] Colin Whereas tcl is eminently suited to wiring together channels. [01:46] dkf_ Hmm [01:46] Colin using [fileevent] and stuff. [01:46] Colin You could completely replace netcat, e.g. [01:47] dkf_ I suppose the point when bash starts sucking is when you start trying to do things with it other than building pipelines [01:47] Colin bash has the metacharacter |, whereas tcl doesn't. It's not possible to add | to tcl properly, I think. [01:47] dkf_ (e.g. configure scripts) [01:47] mjanssen colin's suggestions removes one little language parser (exec) with the normal tcl parser, which is good IMO. I guess it's the same with the [+ [* etc commands [01:47] Colin and this observation leads me to suppose that tcl needs to address the question of how best to represent 'em. [01:48] Colin how best to represent pipelines. [01:48] jenglish waitaminnit: re: #1553691 -- shouldn't the question here be, not "Is it OK to extend Tcl's stubs table in a patch release", but rather "Should we be introducing another magic global?" [01:49] * dkf_ is content to let jenglish fight the good fight on that one [01:49] stevel checks into the chat. [01:50] jenglish Grmph. Screw fighting the good fight on that one. If Jeff thinks it's a good idea, it's going in. [01:50] Colin external commands considered as functionals take, what is it, three arguments (a) command line, (b) the entire array of channels, (c) env, and they return another array of channels. [01:50] * mjanssen notices wiki page pipeline is already used for other info. Other suggestions? newexec maybe [01:51] Colin So considered as functions (not functionals, sorry) they are multi-valued, and there's a level of indirection. [01:51] dkf_ jeff's very good at coming up with suggestions that are bizarrely wrong [01:52] Colin I pose the question: what's the most tcl-ish way to represent the functions defined by external commands. I do not find [expect] compelling. [01:52] * stevel staggers in [01:52] Colin Hey Steve. [01:52] stevel hi Colin - hot one in Sydney today I hear [01:53] sergiol mjannssen [01:53] Colin Looks that way. I'm supposed to go on a 2-night 2-day bike camp this weekend, and am looking for excuses to dip out. [01:53] jenglish Colin: In the Unix tradition: inputs are argv[], envp[], and stdin/stdout/stderr file descriptors; return value is the exit status code. [01:53] sergiol execute ? [01:53] Colin jenglish, all file descriptors. [01:53] Colin thank you, exit status. Forgot that one. [01:53] jenglish Right, all file descriptors, stdin/stdout/stderr are the only ones that are (by convention) universal. [01:53] dkf_ sometimes there are other FDs too