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