-
Notifications
You must be signed in to change notification settings - Fork 30k
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: skip whether TTY is availble #13991
Conversation
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.
LGTM, but at some point I’d like it if we could split up the async_hooks test directory and move these to the pseudo-tty tests
New code works here (on Windows), but I see you have problems in linux
https://ci.nodejs.org/job/node-test-commit-linuxone/7060/nodes=rhel72-s390x/console |
return common.skip('no valid TTY fd available'); | ||
const ttyStream = (() => { | ||
try { | ||
return new (require('tty').ReadStream)(tty_fd); |
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.
This i'm not in love with... does require('tty')
have significant side effects?
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.
Hm. Reason I return null
here then check it below is because I'd have imagined that common.getTTYfd()
should only return a positive number if there's a valid fd for the TTY. Thus ReadStream
/WriteStream
shouldn't fail. Appears that isn't always the case. So I'll go back to the null
check and early return.
I will defend the use of getTTYfd()
, which also does a require('tty')
when called. So I'm not worried about the possible side effects of calling it here.
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.
So if we don't fear side effect, why not move the require
to the top?
The invoked lambda I understand (return null
and assign to const is very functional-programing, and I like 👍 )
@@ -16,47 +16,39 @@ const ttyStream = (() => { | |||
return null; |
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.
Ohh here it is again.
Is it easy to parameterize and merge these two? |
Probably. If not in this PR I'll add another that merges them later. |
@refack Don't know why I didn't think of the fact that |
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. Fixes: nodejs#13984 PR-URL: nodejs#13991
Match changes made to test-ttywrap.readstream for consistency. PR-URL: nodejs#13991
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.
K.I.S.S. FTW!
Anything preventing this from landing? |
I believe just etiquette, to customarily let Collaborators land their own PRs 🤷♂️ |
That is why I asked :) |
Yes and no. Anyone should feel free to land any PR that is ready to land, particularly ones that are more or less trivial. For PRs that are more involved, then yes, it's best to let the authoring contributor land as they have the best context to know when it's ready to go. |
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. PR-URL: nodejs#13991 Fixes: nodejs#13984 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Match changes made to test-ttywrap.readstream for consistency. PR-URL: nodejs#13991 Fixes: nodejs#13984 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Since @trevnorris is busy with another PR, and I'm pretty aware of the context: |
@refack Thanks for landing this. |
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. PR-URL: #13991 Fixes: #13984 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
If TTY isn't available then the test will always fail. Also use the already available process.stdin instead of opening another ReadStream. PR-URL: #13991 Fixes: #13984 Reviewed-By: Anna Henningsen <anna@addaleax.net> Reviewed-By: James M Snell <jasnell@gmail.com> Reviewed-By: Refael Ackermann <refack@gmail.com>
Checklist
make -j4 test
(UNIX), orvcbuild test
(Windows) passesAffected core subsystem(s)
test
Description
If TTY isn't available then the test will always fail.
Fixes: #13984
CI: https://ci.nodejs.org/job/node-test-pull-request/8879/