jerch

@Tyriar What is the idea behind the 'exit' event of pty? Shall it mark the real process end (as it does atm more or less) or shall it be the...

Yep. I stumbled over the somewhat monolithic c part and had debugging problems in #72 due to it. Separating the basic functionality aspects and exporting them individually to JS would...

@Tyriar Want to bring back this proposal since the current implementation seems to cause several issues (see #134 #85 and #86). For #86 I had a closer look at libuv's...

Agreed. I gonna try to build a first C++ API idea to address the cumbersome C functions like `fork`, `exec*` and `waitpid`. With those tamed we should be able to...

@Tyriar Made some progress with an early C++/JS API - see https://github.com/jerch/node-newpty It is a very early version with hardcoded `exec*` and only tested under linux (Ubuntu 14 LTS). `openpty`...

@Tyriar Regarding issue #85 I end up at the same problem as before - if the pty device is non blocking it dies as soon as the child process exited...

@Tyriar Im far from API sanitizing, still trying to comprehend the conceptual DOs and DONTs with libuv streams and the pty file descriptors. Atm the blocking vs non blocking drives...

@Tyriar Pushed a cleanup version. You can test it with test.js. stdin and stdout are working as expected now. Its a pity that the solution has to reassemble basic libuv...

@Tyriar Hmm as I thought - the stderr thing is completely unreliable and highly depends on the slave process itself - `bash` for example drops back to buffered pipe mode...

Yep, the whole pty subsystem is not intended to have a separate stderr channel, gonna stop hacking against the OS again ;) - So no extra stderr channel for now...