Repository navigation
tty.isatty(1) and process.stdout.isTTY in worker_threads worker return different values #28386
Description
- Version: 12.4.0
- Platform: Darwin C02WJ0U4HTDG 17.7.0 Darwin Kernel Version 17.7.0: Wed Apr 24 21:17:24 PDT 2019; root:xnu-4570.71.45~1/RELEASE_X86_64 x86_64
- Subsystem: tty
I found out recently that in a worker which is run with worker_threads, tty.isatty(1) returns True whereas process.stdout.isTTY returns False.
This led to a weird issue in mocha - a popular library for testing: mochajs/mocha#3955
Activity
richardlau commentedon Jun 22, 2019
See #26946 (comment)
1999 commentedon Jun 22, 2019
Thanks for the link, interesting. But it doesn't say anything about
tty.isattyAPI, does it?addaleax commentedon Jun 22, 2019
@1999 This still seems like expected behaviour – fd’s are per-process, so fd
1is going to be a TTY in one thread if it is a TTY for any thread. The problem is that in Workers,process.stdoutdoes not refer to fd1.1999 commentedon Jun 22, 2019
@addaleax I didn't know that
tty.isatty(fd)is talking about the whole process. Maybe it's worth it to add a note about it do the documentation?bnoordhuis commentedon Jun 24, 2019
You're welcome to open a documentation pull request but where would you add it? There are tens if not hundreds of core methods that accept a file descriptor. It'd be incongruent to single out
tty.isatty().Its behavior also isn't the least bit surprising to me but maybe that's just me.
1999 commentedon Jun 24, 2019
For me as a Node.JS developer, it's not clear if I should use
tty.isatty(fd)orprocess.stdout.isTTY- they look the same from the documentation and also the documentation doesn't explicitly say that one is about the process even when we create a thread within this process and another is talking about a thread.addaleax commentedon Jun 24, 2019
I’m having the same issue as Ben here – I don’t see a good place in the documentation that isn’t “everywhere”…
We could document that
tty.isatty(fd)should be used when dealing with a file descriptor, andprocess.stdout.isTTYwhen dealing withprocess.stdout, but that seems somewhat redundant? But that’s kind of the answer to the question of which function to use…devsnek commentedon Jun 24, 2019
i think the question is more like (@1999 correct me if i'm wrong) when should someone be dealing with fd 1 vs when should someone be dealing with process.stdout.
1999 commentedon Jun 25, 2019
Exactly.
addaleax commentedon Jun 25, 2019
I would think of the fd-handling functions as low-level primitives that are there for when you really need them, but generally dealing with the corresponding JS objects makes more sense when available (e.g. 99 % of the time using
fs.createReadStream()makes more sense then manually reading data usingfs.read()).In the case of
isatty(), I think the use cases are very limited. I could see somebody using it for detecting TTY-ness for non-stdio fd’s (e.g. for nativeopenpty()ortcgetattr()/tcsetattr()wrappers), or maybe when the goal is to intentionally test the per-process state, including whenprocess.stdouthas been overridden or when you’re in a Worker. But here too, I think 99 % of the time you’d want to use the convenience JS objects.Is that helpful? Is that something that we could or should document in some way?
devsnek commentedon Jun 25, 2019
it's also worth noting that accessing process.std{out, in, err} can change their modes and that node will start processing data (which may or may not be a good thing depending on your use case)
Fishrock123 commentedon Jul 2, 2019
Related to this, we may want to properly publicly (think, docs) expose
process.stdout.fd?doc: explain process.stdout in worker_threads
doc: document process.std*.fd
doc: document process.std*.fd
doc: document process.std*.fd
doc: document process.std*.fd