-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Yarn init fails on Windows under Git bash / MinGW / Cygwin #743
Comments
Seems like this is an issue with Cygwin and MinGW in that they're not 'proper' TTYs: nodejs/node#3006 I don't think we can fix this at our end. |
Well, one thing you could do would be to remove the check ;) In all seriousness though. It is my understanding that the check is in place because you're trying to make sure that the I/O scenario that is about to happen will work. Does that check actually achieve this? Will the scenario actually fail in MinGW? If not, then a different check should be performed or it should be omitted completely IMHO. |
My understanding is that the check is to stop the process hanging indefinitely when not using a TTY (for example, if running as part of a build process that pipes stdin and stdout). In theory, if there's no TTY, there's no way to accept input. May be the check should "if it's a TTY or if it's MinGW" to handle this case specifically? I think that'd fail if you try to pipe the output to a file when running under MinGW though (it'd hang). |
FWIW the yarn master branch works with
|
Yeah, I just noticed that |
They're simply not enforcing |
Ahh, that's an interesting approach @oliversalzburg. I guess it means trying to run it in a script would result in the script "freezing" as it sits waiting for user input. Not ideal 😕 Maybe we could do that just for Git Bash and Cygwin - Only check isTTY on platforms that properly support it |
So on the one side you have the users who, for some reason, try to run a command that requires user interaction in a script, which will now fail loudly and would otherwise fail silently and on the other side you have everyone who uses a somewhat popular terminal on Windows and is unable to use the command. I really don't see why this is a hard choice or why it would need even more complicated terminal detection code to solve. The check is counter productive and should be removed. Slapping more prone-to-error code on top is not the solution. That being said, I really don't care one way or the other, as there are other terminal emulators that run Git Bash which are not affected by this "problem". I would suggest that everyone who runs into this should have a look at ConEmu. |
I also face this issue, so I run Yarn version:
|
btw. same for nodejs 6.9.1 |
How is this going ? |
Hope this will be fixed soon. |
I really don't get why it fails, yarn uses the "proper" way for testing this in
by testing for I'm using
bkc@DESKTOP-NNSLT74 ~ $ node
> process.stdout.isTTY
true
>
(To exit, press ^C again or type .exit)
>
bkc@DESKTOP-NNSLT74 ~ $ cd workspace/ts-test/
bkc@DESKTOP-NNSLT74 ~/workspace/ts-test (master) $ yarn init
yarn init v0.17.10
error An unexpected error occurred: "Can't answer a question unless a user TTY".
info If you think this is a bug, please open a bug report with the information provided in "C:\\Users\\bkc\\workspace\\ts-test\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/init for documentation about this command.
bkc@DESKTOP-NNSLT74 ~/workspace/ts-test (master) $ |
Interestingly enough, if I install yarn as a dependency, to a project
and in invoke yarn via node and yarn.js it works fine.
So it must have something to do with the native windows version? |
Now it gets really weird, if I omit the
as an executable, it fails. |
It's possible - Running "yarn" on Windows actually goes through either a batch file (when using a regular terminal like cmd.exe, Cmder, etc) or a shell script (when using something Bash-based like MinGW, Cygwin, etc). If you installed to the default location, it's at |
Previous fix only supported some old configuration of Git bash provided by Git for windows, newer Git bash use standard MINGW which uses a different `uname` but the fix is ultimately the same Github: yarnpkg#743
* Support interactive commands in standard MINGW as well Previous fix only supported some old configuration of Git bash provided by Git for windows, newer Git bash use standard MINGW which uses a different `uname` but the fix is ultimately the same Github: #743 * Refactor: use better variable name when determine to use winpty * Support both MSYS 32bit and 64bit terminal emulators
I fixed this by updating my git for windows to the latest version, it looks to be a problem with winpty.exe I also updated to the latest nightly version of yarn v0.20.0 as there was a patch concerning this applied in version 0.19. node.js - v6.9.4 | yarn - v0.20.0-20170117.1018 | git for windows - 2.11.0.3 with MinGW teminal |
I second with ArtistsTechGuy, upgrading to latest versions solved the issue. |
Even upgrading Git to the latest version, it fails for me: yarn init (yarn 0.24.5) |
Cygwin's mintty returns false to I wonder if this stalls compound scripts such as
|
I got the same error as @astudio8
Windows 10 |
Git Bash error ..
Good thing is, Windows PowerShell works without errors. |
Is there any solution now? |
I think I have a solution. Add the following to your .bashrc file:
Running |
I had the same problem. |
As previously stated in this thread, the problem is TTY handling in git-bash. So successfully ran 'yarn upgrade-interactive' using 'winpty yarn.CMD upgrade-interactive' and latter aliased yarn to 'winpty yarn.CMD' in .bashrc |
I think it's worth noting that sometimes you want winpty and sometimes you dont. Though in 90% cases you're safe with it prefixed. From what I can tell it boils down to:
|
@thetrompf I haven't tested it but the script change makes sense. Thanks! |
To me this was a pretty silly issue, |
Under Git Bash on Windows when entering 'yarn init' I get the following error:
error Can't answer a question unless a user TTY
at ConsoleReporter.question (C:\Program Files (x86)\Yarn\lib\reporters\console\console-reporter.js:189:29)
at Object. (C:\Program Files (x86)\Yarn\lib\cli\commands\init.js:91:38)
at next (native)
at step (C:\Program Files (x86)\Yarn\node_modules\babel-runtime\helpers\asyncToGenerator.js:17:30)
at C:\Program Files (x86)\Yarn\node_modules\babel-runtime\helpers\asyncToGenerator.js:28:20
at run (C:\Program Files (x86)\Yarn\node_modules\core-js\library\modules\es6.promise.js:87:22)
at C:\Program Files (x86)\Yarn\node_modules\core-js\library\modules\es6.promise.js:100:28
at flush (C:\Program Files (x86)\Yarn\node_modules\core-js\library\modules_microtask.js:18:9)
at _combinedTickCallback (internal/process/next_tick.js:67:7)
at process._tickCallback (internal/process/next_tick.js:98:9)
Other yarn commands seem to work as expected.
Yarn v0.15.1
Node v6.0.0
Windows 10 Pro 1607
The text was updated successfully, but these errors were encountered: