Re: io.popen read and write, again

[Sean Conner <sean@...>]

It was thus said that the Great Gary V. Vaughan once stated:
> 
> Interestingly, the first version of this used luaposix to hook up the
> pipes, which required a lot more code and was considerable more hairy. 
> But most of the overhead is in setting up the pipes, so for no noticeable
> speedup in execution and swapping a dependency on /bin/sh for a dependency
> on luaposix, I got to maintain all the low-level grungy pipe hookups
> instead of letting /bin/sh do the work.

  Actually, there is some stuff you can do.  Like LPeg, you can create Unix
command objects [1] such that you could do:

	list = {}
	cmd = U("ls -l") .. U("grep foobar") / "grep-stderr" .. function()
			for line in io.lines() do
	 		  table.insert(list,line)
	        	end
	  	  return 0
		end
	result = R(cmd) -- actually run the command
			-- this does the actual redirection
			-- and handles waiting for the processes
			-- to finish running.

	-- result[1] is the return code from "ls -l"
	-- result[2] is the return code from "grep"
	-- result[3] is the return code from the given function

	if result[1] ~= 0 then
	  print("error with ls -l")
	end

(and here, I'm using ".." to mean pipe stdin/stdout, and "/" to pipe stderr,
in this case, to "grep-stderr"; "/" has a higher precedence than ".." and
thus, I'm giving redirection of stderr a higher precedence than stdout. 
Also, there's nothing to say you can't redirect stderr to another pipeline)

  I mean, if you're going to that much trouble, might as well go crazy with
it 8-)

  -spc (But I'm not sure how I feel about this ... )

[1]	I did this in a language I implemented in college [2].  It was
	pretty cool to have Unix commands (and pipes) as first-class
	objects.

[2]	A Forth-like language with object oriented features.