Updated 2006-09-22 00:50:30 by MJ

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