-
Notifications
You must be signed in to change notification settings - Fork 29.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
test: stdin is not always a net.Socket #5935
test: stdin is not always a net.Socket #5935
Conversation
const spawn = require('child_process').spawn; | ||
|
||
if (process.argv[2] === 'child') { | ||
// Refs: https://github.com/nodejs/node/pull/5916 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you move this comment up to line 2.
LGTM with a couple comments. |
Hmmm, doing this reliably in a must-fail environment is quite tricky. |
f9486f0
to
f384f83
Compare
CI on windows: https://ci.nodejs.org/job/node-test-known-issues/2/ (That ci says to not run with all?) |
@cjihrig LGTY now? |
Yea, LGTM |
`<`-ing a file into stdin actually results in a `fs.ReadStream`, rather than a `tty.ReadStream`, and as such does not inherit from net.Socket, unlike the other possible stdin options. Refs: nodejs#5916 PR-URL: nodejs#5935 Reviewed-By: Colin Ihrig <[email protected]>
f384f83
to
d6c9f64
Compare
@Fishrock123 is there a particular issue on the issue tracker that this maps to? I noticed you |
@Fishrock123 did this pass linting for you? I'm getting this locally: ➜ make lint
./node tools/eslint/bin/eslint.js benchmark lib src test tools/doc \
tools/eslint-rules --rulesdir tools/eslint-rules
/Users/phillipj/node/test/known_issues/test-stdin-is-always-net.socket.js
14:1 error Line 14 exceeds the maximum line length of 80 max-len
✖ 1 problem (1 error, 0 warnings) |
#5980 Fixes the linter error |
Refer: nodejs#5935 PR-URL: nodejs#5980 Reviewed-By: Jeremiah Senkpiel <[email protected]>
Refer: #5935 PR-URL: #5980 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Phillip Johnsen <[email protected]>
Is this applicable to v4? |
@jasnell do we put known-issue tests there? if so, yes this applies back as far as I can remember. |
Yep, we can port the known-issue tests back to v4 now |
`<`-ing a file into stdin actually results in a `fs.ReadStream`, rather than a `tty.ReadStream`, and as such does not inherit from net.Socket, unlike the other possible stdin options. Refs: #5916 PR-URL: #5935 Reviewed-By: Colin Ihrig <[email protected]>
Refer: #5935 PR-URL: #5980 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Phillip Johnsen <[email protected]>
`<`-ing a file into stdin actually results in a `fs.ReadStream`, rather than a `tty.ReadStream`, and as such does not inherit from net.Socket, unlike the other possible stdin options. Refs: #5916 PR-URL: #5935 Reviewed-By: Colin Ihrig <[email protected]>
Refer: #5935 PR-URL: #5980 Reviewed-By: Jeremiah Senkpiel <[email protected]> Reviewed-By: Phillip Johnsen <[email protected]>
@Fishrock123 I know this was a long, long time ago, but what exactly is the issue that this test is catching? It sounds like the underlying idea is that stdio streams should always inherit from |
@addaleax There was this thing at one point where sometimes stdin wasnt a net.Socket... I think this checks when stdin doesn't actually exist that it still makes a socket? It was supposed to be a consistency check. Edit:
Yes. |
Pull Request check-list
make -j8 test
(UNIX) orvcbuild test nosign
(Windows) pass withthis change (including linting)?
Affected core subsystem(s)
test
Description of change
Refs: #5916 (comment)
cc @Trott I think this should cover the known issue.