Expose an stderr stream

[aashidham]

how do I access the stderr of a process spawned with this module?

[Tyriar]

You can't differentiate stderr/stdout that is passed through a pty AFAIK, see http://stackoverflow.com/a/16839544/1156119

[aashidham]

But this isn't a tty it's a pty, or does that not matter?

…

On Apr 2, 2017, at 9:46 PM, Daniel Imms ***@***.***> wrote: You can't differentiate stderr/stdout that is passed through a pty AFAIK, see http://stackoverflow.com/a/16839544/1156119 — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Tyriar]

A pty is a pseudo tty and I think they behave the same in this regard.

[aashidham]

Links that help me understand this would be helpful.

…

On Apr 3, 2017, at 7:28 AM, Daniel Imms ***@***.***> wrote: A pty is a pseudo tty and I think they behave the same in this regard. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[aashidham]

Also why does the node module child_pty have a defined stderr pipe? Which one of you has the right implementation?

…

On Apr 3, 2017, at 7:28 AM, Daniel Imms ***@***.***> wrote: A pty is a pseudo tty and I think they behave the same in this regard. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread.

[Tyriar]

stderr in child_pty is just to fill in the child process interface, it doesn't actually do anything:

https://github.com/Gottox/child_pty/blob/85a2e70cf73a055af7ac2b238e51f48a07e1ccf7/README.md#childprocess
https://github.com/Gottox/child_pty/blob/85a2e70cf73a055af7ac2b238e51f48a07e1ccf7/lib/child_pty.js#L86

[jerch]

@Tyriar To be able to reroute the STDERR might be a useful enhancement. Not sure if it is worth the trouble, since it will deal only with the first process on slave end (bash etc.) and might lead to weird behavior (some programs tend to behave differently if they find a blocking buffering fd for any of the standard channels).
To get this done, the module needs some OS level pipe abstraction to be exported to JS land.

[Tyriar]

No plans to invest in this at the moment, the fact that it might lead to some weird behavior is another reason for not implementing 😃

[stevenvachon]

So, we can never get the error message to find out why the child process crashed?

[Tyriar]

I'm guessing we would need to do something like this to support pulling stderr https://reviews.llvm.org/D15073

[jerch]

@stevenvachon A process behind a pseudo terminal is not to be expected to have other "channels" than the bidirectional terminal fd, which handles all the input and output. This simple setup dates back to teletype writers (tty) in the 60s even before the UNIX gurus came up with the STDIN, STDOUT, STDERR process interface idea. Therefore the low level forkpty does not give any option to set up another side channel to handle STDERR elsewhere. This does not mean it is impossible, but needs several considerations before trying to implement it:

1. good unix citizens behave differently for tty standard IO channels than for buffered normal pipe channels - Does the extra STDERR channel need to be its own pty device or will a simple pipe fd do the trick? This can lead to weird behavior of the child process if not done right.
2. What about child-children? How to get their error messages? A session leader (typically a shell) would spawn own children with dupes of the controlling terminal fd for STDIN, STDOUT, STDERR unless you explicitly tell it to do otherwise (e.g. redirects in a shell script). This might be a dead end right after the first child process here (unless you undermine the shell's fork & exec calls).
3. circumvent the forkpty limitation by doing your own fd dupes

The real show stopper is 2. imho, it is simply not much of a use, if you can't propagate the additional fd to the sub children.

@Tyriar Yeah it is possible with that, it is basically setting up an additional fd before exec, kinda implementing 3. I see a use case for this if you need to run a single process behind a pty (omitting the shell subchildren problem in 2.) 1. still needs to be tested carefully, which heavily depends on the subprocesses themselves (one might test with isatty against STDERR, others might not). Side note here - node-pty is kinda broken atm for a single subprocess due to #85

[Tyriar]

Closing this as designed, no plans to do this extra work when it will only apply to the parent shell.