Repository navigation
Node.js doesn't run as tty on windows / cygwin #3006
Description
Activity
IIRC, that's because the cygwin shell isn't really a tty, it's a pipe.
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?process.stdincan be a tty, pipe, file, or even a socket. node.js detects what type of device it is and adjusts accordingly.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.
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.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...)If by 'terminal' you mean 'user-visible window', then no, not in general and not reliably.
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?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.
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
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? - Some logic inside of node.js seem to change when
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) - I have added an
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?
- 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
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
22 remaining items
Is this fixed in Node v6?
Reacted by Yair Even OrLooks like the solution was:
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'm not sure we can actually fix this.
Is this fixed in Node v6?
or 7 ?
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.
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.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
Reacted by wulph111, Alex Moros Marco, Tyler and Peter@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.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.@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".Reacted by Neil de Carteretnote : 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 npmmy case is to run npm and gulp only
this fails$npm > /tmp/test stdout is not a tty $
this works
$npm.cmd > tmp/test $
Reacted by Martin Heidegger, Vitalii Goma and Oren@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.@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
$@pmalhaire yes I did:
$/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 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...
@geonanorch it's a workaround
fixing the issue implies fixing mysys2 it self (not nodejs)
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 returnsfalse. It does seem to work in the regular command prompt.