You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Node.js doesn't run as tty on windows / cygwin #3006
Just had a report @ nodeschool that node -p -e "Boolean(process.stdout.isTTY)" on Windows 8.1 Pro with Node.js 4.1.0 on Cygwin 2.2.1 returns false. It does seem to work in the regular command prompt.
I am confused (general state of mind these days): Ain't I supposed to be able to do things like process.stdin.resume() on cygwin? Is process.stdin.resume() not tied to it being a tty? Am I not understanding something?
Let me rephrase the question: In my understanding tty is indicating that there is some user input loop that can be .resume()ed. Is that correct? A pipe would not indicate that there is ui attached to it?!
Note: clarification on Cygwin: I meant the Cygwin bash.
I am sorry to ask differently yet again: Does this mean that there is no reliable way to figure out whether node (or any other app) is running inside a terminal?
I need to ask again to form a good question here (so sorry for taking your time - and anyone who reads this). I am still not clear what tty means in the node context. I am still assuming it has to do with "user input". As far as I read in the api documentation, depending on process.stdout.isTTY other parts of the stdio of node (tty.ReadStream) change. If I can't rely on isTTY to tell me if the terminal supports asks for user input or not, can I force node to use the tty.Read/WriteStream ?
Medium version: Cygwin (and others) that attempt to provide "terminal windows" have a lot of problems with standard Windows programs (e.g. node).
Long version...
POSIX has pty's, which allows programs to work the same way on the console, serial terminals, ssh sessions, and GUI terminal windows (e.g. XTerm). The program sees a standard "tty" interface in all cases, and can easily differentiate this interface from a pipe or file redirection.
Windows has no equivalent feature. Windows consoles are a special facility built in to the OS, and generally aren't extensible. The Windows console can do things that no other application can do.
cygwin (and others) attempt to emulate POSIX pty's and provide "terminal windows" with varying degrees of success. These terminal windows are generally NOT Windows consoles, and can confuse standard Windows programs (e.g. node). Some of them use pipes, but pipes have problems. A program with a pipe for stdin or stdout has no way to know if it's being run in a traditional shell pipeline (e.g. "ls -l | head"), or if the other end of the pipe is a process attempting to emulate an interactive tty.
Reacted by Daniela Rodríguez Careri, Jonas Berlin, Maximilian Lenkeit, Tomasz Wesołowski, jsilveira, zrisher, etune, gin1314, William Wenge-Murphy, wulph111 and 7 more
@mcnameej Thank you for your detailed explanation. The problem with this situation is that the bash of cygwin and the bash of github have been promoted widely in the nodeschool community. I also meet many windows developers that use it in their corporate computers.
I seem to have the following problems after processing all your great input:
In node.js 4 (probably before that in one of the iojs versions) something seemingly changed in the tty detection. The result is that now it is false where before it probably was true (have not tracked non-issues). Those problems have only been reported since the 4.0 release. Does anyone know what has changed? Have people similar issues?
Some logic inside of node.js seem to change when isTTY is detected but since we can't guarantee that it is detected properly I would like to be able to enforce that behaviour - making the code assume that it is a tty. Would that be possible? Is that even necessary? (Keep in mind that I don't know what the internals are about)
I have added an isTTY check to my code in response to some strange error that occurs when you try to use setRawMode and resume(). It seems I have used isTTY wrong. When and how is it appropriate to do a isTTY check?
bash itself is not the problem -- the problem is running node inside a "fake" console. If you run bash in a regular Windows console, it gets along fine with node. See screen shots below. .
In node.js 4 (probably before that in one of the iojs versions) something seemingly changed in the tty detection.
I don't know what changed. A review of the code (probably in libuv) could probably determine the cause, but IMHO, that's asking the wrong question. You're trying to do something that is inherently unreliable on Windows, and any "fix" made today may break again tomorrow.
Would it be possible to make the code assume that it is a tty?
I'm not the right person to answer that; perhaps @bnoordhuis will chime in. I have a lot of experience with Win32, and can talk about the OS-level issues, but I'm not an expert on node's internals.
@mcnameej Don't have time for a lengthy reply but there is one thing to point out: those screenshots are made with win 7, the problem has been reported with windows 8.1
I don't know if this helps, but when installing Git for Windows 2.7.0 there is a prompt now (I don't recall seeing it in some fairly earlier version) that defaults to using MinTTY, but if you choose Use Windows' default console window, $ node -p -e "Boolean(process.stdout.isTTY)" prints true and I don't experience any of the problems that I do with MinTTY (some gulp hangs, inquirer prompts not working correctly, etc.)
I completely failed to make the pop-up windows happen at all, so could not verify that my change was capable of hiding the pop-up... if you can build and verify that branch, I could re-PR it and I'm sure we could get it merged in short order.
I had this problem and I tried running a 'sub-shell' (mean I ran bash and the command line and created another shell). Then I ran node program < infile and I don't have the problem anymore
It is not a node problem, I investigated this in context of yarnpkg. The way git-bash "fixed" the problem is by wrapping the node process in a program called winpty, which emulates some/enough of the unix teletype to make it work: https://github.com/rprichard/winpty
If you have a "newer" version of git bash installed, you will find a hack in /etc/profile.d/aliases.sh wrapping common programs like node, php and python to run through winpty.
WinPTY works with cygwin as well, so if you introduce a similar "hack/fix" your bash profile for, it should work "just as well" in cygwin.
@thetrompf I am sorry but that seems like it is a Node.js problem after all: If you have to wrap it with some other method that "does the compatibility" it means - by what I understand - that the Node.js compatibility is not given.
@martinheidegger Node.js works fine with the standard windows shells (cmd.exe and power shell), using cygwin/msys shells is the users who has decided to use shells that looks like teletype terminals but are not, and the common way to test if you are command line programs is running in an interactive shell is by checking for process.stdout.isTTY or in a unix shell script http://stackoverflow.com/questions/911168/how-to-detect-if-my-shell-script-is-running-through-a-pipe CygWin ans Msys terminals has implemented some of the teletype layer, but unfortunately not enough to work in all cases. If you ask me cygwin and msys/mingw should include whatever winpty is doing in their terminals so they actually work.
@thetrompf I do know that cygwin does not implement certain parts correctly. But: if cygwin would break interactive mode then it wouldn't be possible for winpty to "fix" it. In other words: if an application running in cygwin can fix it node - an application running in cygwin can fix that too. That being said Cygwin is afaik not a officially supported platform. It would be good if it became one though (since several tools on windows promote cygwin as "best shell for windows".
@pmalhaire I use msys2 (from msys2-x86_64-20160205.exe) and do not seem to need the workaround, calling the npm shell script directly works fine.
I do need winpty for running node itself, though.
$/C/Program\ Files/nodejs/npm > test
$cat test
Usage: npm <command>
. . . .
(remark: I installed node/npm independently of MSYS2)
Note that things aren't perfect for me either though: when invoking npm init for instance I have to type CTRL-C to exit the program, it just hangs after generating package.json (and going through winpty first does not help in this case).
I wish there existed a 'standard' library which allowed to build windows console programs with dual support native-console/mintty...
Activity
bnoordhuis commentedon Sep 22, 2015
IIRC, that's because the cygwin shell isn't really a tty, it's a pipe.
martinheidegger commentedon Sep 22, 2015
I am confused (general state of mind these days): Ain't I supposed to be able to do things like
process.stdin.resume()on cygwin? Isprocess.stdin.resume()not tied to it being atty? Am I not understanding something?bnoordhuis commentedon Sep 22, 2015
process.stdincan be a tty, pipe, file, or even a socket. node.js detects what type of device it is and adjusts accordingly.martinheidegger commentedon Sep 22, 2015
Let me rephrase the question: In my understanding
ttyis indicating that there is some user input loop that can be.resume()ed. Is that correct? Apipewould not indicate that there is ui attached to it?!Note: clarification on Cygwin: I meant the Cygwin bash.
bnoordhuis commentedon Sep 22, 2015
You can
.resume()either way, it's not specific to ttys. stdin being a pipe doesn't say anything about the other end having a UI.martinheidegger commentedon Sep 22, 2015
I am sorry to ask differently yet again: Does this mean that there is no reliable way to figure out whether node (or any other app) is running inside a terminal?
(I am asking because http://stackoverflow.com/questions/4426280/what-do-pty-and-tty-mean tells me that
ttymeans having a terminal...)bnoordhuis commentedon Sep 22, 2015
If by 'terminal' you mean 'user-visible window', then no, not in general and not reliably.
martinheidegger commentedon Sep 22, 2015
I need to ask again to form a good question here (so sorry for taking your time - and anyone who reads this). I am still not clear what
ttymeans in the node context. I am still assuming it has to do with "user input". As far as I read in the api documentation, depending onprocess.stdout.isTTYother parts of the stdio of node (tty.ReadStream) change. If I can't rely onisTTYto tell me if the terminal supports asks for user input or not, can I force node to use thetty.Read/WriteStream?mcnameej commentedon Sep 22, 2015
Short version: Cygwin sucks. Don't use it. 😄
Medium version: Cygwin (and others) that attempt to provide "terminal windows" have a lot of problems with standard Windows programs (e.g. node).
Long version...
POSIX has pty's, which allows programs to work the same way on the console, serial terminals, ssh sessions, and GUI terminal windows (e.g. XTerm). The program sees a standard "tty" interface in all cases, and can easily differentiate this interface from a pipe or file redirection.
Windows has no equivalent feature. Windows consoles are a special facility built in to the OS, and generally aren't extensible. The Windows console can do things that no other application can do.
cygwin (and others) attempt to emulate POSIX pty's and provide "terminal windows" with varying degrees of success. These terminal windows are generally NOT Windows consoles, and can confuse standard Windows programs (e.g. node). Some of them use pipes, but pipes have problems. A program with a pipe for stdin or stdout has no way to know if it's being run in a traditional shell pipeline (e.g. "ls -l | head"), or if the other end of the pipe is a process attempting to emulate an interactive tty.
martinheidegger commentedon Sep 23, 2015
@mcnameej Thank you for your detailed explanation. The problem with this situation is that the bash of cygwin and the bash of github have been promoted widely in the nodeschool community. I also meet many windows developers that use it in their corporate computers.
I seem to have the following problems after processing all your great input:
falsewhere before it probably wastrue(have not tracked non-issues). Those problems have only been reported since the 4.0 release. Does anyone know what has changed? Have people similar issues?isTTYis detected but since we can't guarantee that it is detected properly I would like to be able to enforce that behaviour - making the code assume that it is a tty. Would that be possible? Is that even necessary? (Keep in mind that I don't know what the internals are about)isTTYcheck to my code in response to some strange error that occurs when you try to usesetRawModeandresume(). It seems I have usedisTTYwrong. When and how is it appropriate to do aisTTYcheck?mcnameej commentedon Sep 23, 2015
bash itself is not the problem -- the problem is running node inside a "fake" console. If you run bash in a regular Windows console, it gets along fine with node. See screen shots below. .
I don't know what changed. A review of the code (probably in libuv) could probably determine the cause, but IMHO, that's asking the wrong question. You're trying to do something that is inherently unreliable on Windows, and any "fix" made today may break again tomorrow.
I'm not the right person to answer that; perhaps @bnoordhuis will chime in. I have a lot of experience with Win32, and can talk about the OS-level issues, but I'm not an expert on node's internals.
martinheidegger commentedon Sep 24, 2015
@mcnameej Don't have time for a lengthy reply but there is one thing to point out: those screenshots are made with win 7, the problem has been reported with windows 8.1
22 remaining items
voltuer commentedon Sep 28, 2016
Is this fixed in Node v6?
Fishrock123 commentedon Sep 28, 2016
Looks like the solution was:
I'm not sure we can actually fix this.
yairEO commentedon Nov 1, 2016
or 7 ?
sam-github commentedon Nov 2, 2016
No. I tried to fix it, but gave up, see #2908 (comment)
I just rebased my branch at https://github.com/sam-github/node/tree/spawn-detached-window-hide-option, feel free to adopt it if you want.
I completely failed to make the pop-up windows happen at all, so could not verify that my change was capable of hiding the pop-up... if you can build and verify that branch, I could re-PR it and I'm sure we could get it merged in short order.
trevor-mink commentedon Dec 2, 2016
I had this problem and I tried running a 'sub-shell' (mean I ran bash and the command line and created another shell). Then I ran node program < infile and I don't have the problem anymore
thetrompf commentedon Dec 13, 2016
It is not a node problem, I investigated this in context of yarnpkg. The way git-bash "fixed" the problem is by wrapping the node process in a program called winpty, which emulates some/enough of the unix teletype to make it work: https://github.com/rprichard/winpty
If you have a "newer" version of git bash installed, you will find a hack in
/etc/profile.d/aliases.shwrapping common programs like node, php and python to run through winpty.WinPTY works with cygwin as well, so if you introduce a similar "hack/fix" your bash profile for, it should work "just as well" in cygwin.
Checkout this pull-request for further details: yarnpkg/yarn#2230
martinheidegger commentedon Dec 13, 2016
@thetrompf I am sorry but that seems like it is a Node.js problem after all: If you have to wrap it with some other method that "does the compatibility" it means - by what I understand - that the Node.js compatibility is not given.
thetrompf commentedon Dec 13, 2016
@martinheidegger Node.js works fine with the standard windows shells (cmd.exe and power shell), using cygwin/msys shells is the users who has decided to use shells that looks like teletype terminals but are not, and the common way to test if you are command line programs is running in an interactive shell is by checking for
process.stdout.isTTYor in a unix shell script http://stackoverflow.com/questions/911168/how-to-detect-if-my-shell-script-is-running-through-a-pipe CygWin ans Msys terminals has implemented some of the teletype layer, but unfortunately not enough to work in all cases. If you ask me cygwin and msys/mingw should include whatever winpty is doing in their terminals so they actually work.martinheidegger commentedon Dec 13, 2016
@thetrompf I do know that cygwin does not implement certain parts correctly. But: if cygwin would break interactive mode then it wouldn't be possible for
winptyto "fix" it. In other words: if an application running incygwincan fix it node - an application running in cygwin can fix that too. That being said Cygwin is afaik not a officially supported platform. It would be good if it became one though (since several tools on windows promote cygwin as "best shell for windows".pmalhaire commentedon Feb 2, 2017
note : if it can help someone there is a workaround for this issue using msys2 I guess it would be the same for cygwin
the issue I face is how to write npm's output to a file using msys2.
it's not the exact same issue but it has the same root as this issue.
I am using msys2w64 under windows 10
the workarround is:
use npm.cmd instead of npm
my case is to run npm and gulp only
this fails
this works
geonanorch commentedon Feb 14, 2017
@pmalhaire I use msys2 (from msys2-x86_64-20160205.exe) and do not seem to need the workaround, calling the npm shell script directly works fine.
I do need winpty for running node itself, though.
pmalhaire commentedon Feb 14, 2017
@geonanorch did you try to redirect it's output to a file as done in my example ?
$npm > /tmp/test
stdout is not a tty
$
geonanorch commentedon Feb 15, 2017
@pmalhaire yes I did:
(remark: I installed node/npm independently of MSYS2)
Note that things aren't perfect for me either though: when invoking
npm initfor instance I have to type CTRL-C to exit the program, it just hangs after generating package.json (and going through winpty first does not help in this case).I wish there existed a 'standard' library which allowed to build windows console programs with dual support native-console/mintty...
pmalhaire commentedon Feb 15, 2017
@geonanorch it's a workaround
fixing the issue implies fixing mysys2 it self (not nodejs)