GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
Already on GitHub? Sign in to your account
See https://savannah.gnu.org/patch/index.php?8007 for a demonstration of the problem (in an editor, using posix.pipeline messes up the terminal).
The advice given here: http://stackoverflow.com/questions/11042218/c-restore-stdout-to-terminal is exactly what posix.pipeline does (independently!), so I'm not sure what the problem is.
I haven't tried it in Lua, but in the toy shell I wrote for the Goat Book, I created new descriptors in the parent process, and attached them to stdin/stdout/stderr in the fork child. The parent would then write into it's end of the input pipe and read back the childs output from it's end of the output pipes and copy the appropriate parts to it's own (os supplied) stdout/stderr. I have no idea whether that's the received wisdom on how to do things, but it seemed to work at the time.
I'll have a proper look at posix.pipeline when I have more time, if you haven't figured it out already by then...
P.S. this is a really nice API to process pipelining: http://amoffat.github.io/sh/
I am open to redoing this API. sh does look nice, and pipeline does offer the ability to run Lua functions, so that API would make sense. Probably worth asking users; I'd be happy to rewrite cw to use a better API, but others might be less pleased!
+1 on all counts.
I guess a separate rock would be better for this. Especially as I would like to understand why pipeline doesn't restore stdout properly...
I now have a use case for this: cw has an (obvious-in-hindsight) bug rrthomas/cw#4 in that it doesn't return exit codes of commands that it colors, because pipeline_iterator doesn't give access to those exit codes. The sh API for Python does, by making each command an object with an iterator property and an exit code property.
Looking at sh, it is (now?) a large module, some 2kLOC long. I'm not keen to reimplement it in one go, nor am I over-fond of its API (other than the command→function transformer).
I just spotted a possible clue as to why stdout-restoring isn't working. One of the comments in the stackoverflow page linked above says: "You do need to worry about flushing standard I/O streams (fflush(stdout)) at appropriate times as you mess around with this. That means 'before you switch stdout over'."
Wow, you're right the implementation of Python's sh is ugly :-( Still, if we can make pipelines work properly, who cares!! :-p LOL
This is still on my radar, soon after I climb back up the dependency stack to Zile (which, realistically speaking is likely quite some way in the future by now)... but it would be awesome if you can try injecting some stream flushes judiciously and get it working properly in the mean time...
34c8aeb replaces the troublesome pipeline with popen_pipeline by cherry-picking from #212