On Tue, April 10, 2007 2:01 pm, Stewart Stremler wrote: > begin quoting Lan Barnes as of Tue, Apr 10, 2007 at 12:31:47PM -0700:
> > 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. > >> Because I would think that any scripting language (like Tcl) that allows >> new commands to be added using C could easily develop a couple of >> commands >> that would do that (and undo it afterward). > > 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 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? >> Or am I just not getting this? > > 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. -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
