Welp... when you call `process.exit`, Node just loses data that was successfully written to stdout if there's enough of it; it never makes it through the pipe. I realize that I'm a broken record here, but this problem does not exist in other languages.https://github.com/nodejs/node/issues/6456 …
-
Show this thread
-
The context here is: I have a test runner. When a test fails, it does `process.exit(1)`. But that means that any failing test that prints a lot of data to stdout or stderr will have some of it silently truncated. And it only happens sometimes.
2 replies 2 retweets 20 likesShow this thread -
This is really blowing my mind. "Send things across a pipe when they're written to stdout" is one of the most fundamental Unix things, but Node can't do it. Yet it was marketed as being Unixy from the very beginning.
6 replies 8 retweets 39 likesShow this thread -
What is Unixy is: blocking IO.
3 replies 1 retweet 22 likesShow this thread -
Three hours in. Still doesn't work. I first used a Unix in 96 or 97. I've never seen anything break stdout like this.
1 reply 1 retweet 24 likesShow this thread -
-
-
Replying to @garybernhardt
I'm sure there's a long discussion with reasoning and tradeoffs out there, but I'm baffled at how a language could have non-blocking/buffered IO by default and not make flushing part of the required API
1 reply 0 retweets 3 likes -
It seems like `process.stdout.write('', () => process.stderr.write('', () => exit()))` might emulate "exit once stdout and stderr are flushed", but based on the description of the API, always immediately calling the callback when given an empty string would be valid behavior
-
-
Replying to @sgrif @garybernhardt
Which is my long-winded way of saying I'm with you on this being mind-blowingly bad
0 replies 0 retweets 2 likesThanks. Twitter will use this to make your timeline better. UndoUndo
-
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.