begin quoting Lan Barnes as of Tue, Apr 10, 2007 at 03:32:36PM -0700: > > On Tue, April 10, 2007 2:01 pm, Stewart Stremler wrote: > > That's pretty much how you implement pipes in a shell. Create a pipe, > > fork, fork, close stdin, dup to stdin, close stdout, dup to stdout, > > exec, exec. [snip] > > You pretty much need to spawn off processes to do this, or write your > > command to read/write from/to streams that you passed in to the > > function. > > Hmm again. All this is perfectly doable from a Tcl standpoint using C, but > it seems to me it's be pissing up a rope from the standpoint of doing > things the "Tcl way." For example, fork is conspicuously absent from Tcl > (but present in perl, and I'm sure perl's the better for it) mostly
And present in Expect, as well as something called TclX, according to wiki.tcl.tk at least. > because there is no need for it. Tcl lets you open slave interpreters, > safe interpreters, co-conspirial interpreters, and communicate between > them all, so fork-exec is just an unecessary level of complication. Why > manage all that when you can have a bunch of cakes all at the same time > and eat them too? Poking around at the web did not leave me with a clear picture about the interpreters, although that the "after" command is considered "unsafe" leads me to think that the other interpreters don't use fork. If they did, "after" wouldn't have to be unsafe. > > I am not sure I'm getting it either. I await enlightenment. > > I just cannot imagine for the life of me what a pipe-oriented language > statement looks like or does (other than, you know, a pipe), or when I > would reach for one. But that happens to me a lot when the grown-ups talk. Conditionals would seem to be difficult. -- Pipes are great for glue. Stewart Stremler -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
