MJ - Triggered by a discussion on Tcl chat, this page discusses possible replacements for exec.
Describe problems with exec here:
Chat discussionBelow 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] <Cameron> 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] <Cameron> 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] <Cameron> 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] <dwu> 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 
