Yarn fails under git-bash: Can't answer a question unless a user TTY

[jmathew]

Do you want to request a feature or report a bug? Bug.

What is the current behavior? Running yarn init yields:

$ yarn init
yarn init v1.0.2
error An unexpected error occurred: "Can't answer a question unless a user TTY".

What is the expected behavior? Standard init process.

Please mention your node.js, yarn and operating system version. Versions:

Git-bash
You are downloading the latest (2.14.1) 64-bit version of Git for Windows. 

Which seems to install MinTTY 2.7.7

$ node -v
v8.1.4

$ npm -v
5.0.3

$ yarn -v
1.0.2

$ bash --version
GNU bash, version 4.4.12(1)-release (x86_64-pc-msys)
Copyright (C) 2016 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>

This is free software; you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

Background Research

The problem was previously noted in: https://github.com/yarnpkg/yarn/issues/743

This yielded a fix that tried to autodetect mintty and use winpty: https://github.com/yarnpkg/yarn/pull/2243

That fix worked for interactive operations but breaks any sort of piping.

This fix was removed in favor a explicit environment variable in: https://github.com/yarnpkg/yarn/issues/2998

The reason being yarn shell commands seemed to fail because of winpty when used in a pipe. And there appears to be some terminal output that shows git bash working without the need for winpty. This is not consistent with my experience.

Technical details

I believe yarn uses isTTY to check for an interactive terminal. The discussion attributed the issue to be caused by winpty however running node by itself can produce that error:

$  node -p -e "Boolean(process.stdout.isTTY)"
true

$  node -p -e "Boolean(process.stdout.isTTY)" | cat
stdout is not a tty

I think that's the check that's actually causing the issue when any yarn command is involved in a pipe. But weirdly using yarn in a pipe works for commands that are not interactive like --version.

Below is a bunch of commands I ran on the terminal that I hope help diagnose the issue.

$ yarn --version | cat
1.0.2

$ yarn init
yarn init v1.0.2
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\\jmathew\\work\\FatGolem\\yarn-error.log".
info Visit https://yarnpkg.com/en/docs/cli/init for documentation about this command.

$ YARN_FORCE_WINPTY=1 yarn --version
1.0.2

$ YARN_FORCE_WINPTY=1 yarn --version  | cat
stdout is not a tty

$ bash -c 'yarn install'
yarn install v1.0.2
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...
info Lockfile not saved, no dependencies.
Done in 0.05s.

$ bash -c 'YARN_FORCE_WINPTY=1 yarn install'
yarn install v1.0.2
info No lockfile found.
[1/4] Resolving packages...
[2/4] Fetching packages...
[3/4] Linking dependencies...
[4/4] Building fresh packages...

info Lockfile not saved, no dependencies.
Done in 0.05s.

There's a lot of moving pieces so its hard for me to understand the cause and effect here. So I'm not sure of a good solution that keeps this interactive terminal check.

My initial thought is that this check for interactive terminal isn't really worth the hassle of keeping around. If you design a script that has yarn init and fail to provide input or redirect properly and it spins forever waiting that should be on you right? Npm doesn't do this and I suspect its because of these kinds of problems.

Summary

It would seem that I have to use the YARN_FORCE_WINPTY when using an interactive command in git bash and specifically not use that when trying to do any piping.

Further, YARN_FORCE_WINPTY isn't documented anywhere as far as I know. Other than the old issues and the script itself. Maybe add that to the error message?

Regardless of all that I just want to be able to type yarn init and have it work consistently without having to do anything special to make it work on windows.

[BYK]

This looks a lot like a duplicate of #2591 so closing in favor of that. Reopen if you don't agree.

[alancnet]

Please consider reopening. #2591 may have fixed a related issue, but this issue is still present today (or is present again).

@BYK @jmathew

[Nekosandesu]

Use PowerShell instead.

[alancnet]

I'm not satisfied that this thread ends with "You should use my preferred tool instead of your preferred tool". This is still a problem. NPM works, Yarn doesn't. How about some action here?

@kittens @bestander @arcanis @sebmck @BYK @Daniel15 @rally25rs @zertosh @voxsim

[BYK]

@alancnet sure, we always accept well-written and tested PRs

[alancnet]

My apologies @BYK, it seems this issue has been resolved in v1.17.0. It is still an issue in v1.16.0 which is what is published. I look forward to the next release.

[BYK]

@alancnet don't really see anything that could have fixed this since 1.16.0: https://github.com/yarnpkg/yarn/compare/v1.16.0...master

Are you sure this is not something else?

[alancnet]

@BYK You're right. When you npm install yarn, the yarn shim is ignored, and a cmd-shim is created instead. The yarn shim has code that executes yarn with winpty. There is no functionality in npm to customize the shim.

Do you think it would be appropriate to add a postinstall script to replace the shim?

[BYK]

@alancnet ooh, interesting find! I wonder why they diverge and I'd say this is a bug. So you have no issues when installing from npm but have issues when you install it from another place(which place btw, can you share)?

If so we should file a new bug to align them.

[alancnet]

@BYK The shim shown on the left of my screenshot is when installing from npm:

[lanseria]

[BYK]

@alancnet sorry for the late response! I definitely remember hitting this issue. So when Yarn detects winpty it simply uses that without a way to turn off. I think there should be an option to turn it off or the automatic enabling should use a better test (not in git-bash for instance?).

Did some digging and seems like this behavior was introduced in #4577 to fix this exact issue and the code responsible lives in https://github.com/thetrompf/yarn/blob/master/bin/yarn

I'm reopening the issue. Would you like to try fixing this and submitting a PR to become the hero of all these people :) I am also using Windows and I'd be happy to assist you in the PR journey. Once it is merged, it'll be available in the nightly builds pretty quickly.

[Artoria2e5]

A similar behavior around cmd-shim happens with yarn too: the main shim appears to launch "$basedir/../Data/global/node_modules/.bin/yarn", which is all good, but then you notice that the actual shim looks the same as npm's shim.

I don't think auto-using winpty is a bad idea. The current https://github.com/yarnpkg/yarn/blob/master/bin/yarn is doing it right by making sure it is trying to do winpty only under a cygwin tty. What needs to be changed is how yarn, or cmd-shim, handles the bin field. It needs to learn to search for an identically-named file without the js suffix and to recognize them as what the package author intended as the launcher script.

[rupurt]

I'm also experiencing this on OS X 10.14.5

$ yarn -v
1.17.3
$ node -v
v10.15.3

[rupurt]

Looks like it's a permission problem. sudo yarn upgrade-interactive works for me.

[greenreign]

Has this re-emerged in 1.22?

Or I guess it was never fixed?

[lekoaf]

Still not working on Windows with Git Bash.

$ yarn upgrade-interactive --latest
yarn upgrade-interactive v1.22.4
info Color legend :
 "<red>"    : Major Update backward-incompatible updates
 "<yellow>" : Minor Update backward-compatible features
 "<green>"  : Patch Update backward-compatible bug fixes
Done in 12.73s.
Error: Can't answer a question unless a user TTY

[Leessonomy]

Same problem

[puncha]

Same problem

[lolmaus]

Does prefixing yarn init with winpty make any difference?

E. g. winpty yarn init

[raffa-raffa]

Usando o Windows10...com o git bash , ainda aparece esse mesmo erro . Minha versão do yarn v1.22.4 ao rodar yarn init no meu projeto apareceu:

" 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:\curso-es6\yarn-error.log". info Visit https://yarnpkg.com/en/docs/cli/init for documentation about this command."

Mas usando o power shell modo administrador o yarn install funciona e gera o arquivo package.json

[GuyARoss]

Not sure if this thread is still relevant, in my case the fix was ensuring that my yarn version was set to yarn berry before I ran yarn init.

yarn set version berry

[KatieProchilo]

Same fix for me as @GuyARoss

I had previously run yarn init v1.22.10 to run into this issue

[Pranav016]

Not sure if this thread is still relevant but in my case, the fix was ensuring that my yarn version was set to yarn berry before I ran yarn init.

yarn set version berry

Worked for me initially. But then it was still giving error when I tried to require packages. Those who are looking a solution for this, just use your terminal in vs code for yarn init or the powershell. For me, yarn init was only giving error in my git bash

[caqu]

Running into this same error message and I found one solution.

I'm on Windows 10 and my project needs me to run yarn prepare which runs husky for... reasons. I was getting:

> yarn prepare
yarn run v1.22.10
$ husky install
node.exe : error Couldn't find the binary husky install

I tried the same command on:

• Powershell --> Couldn't find the binary
• Powershell ISE --> Couldn't find the binary
• Git Bash --> Couldn't find the binary
• Ubuntu 18.04 (WSL) --> worked.

I can't recall for sure but I think I installed yarn with Ubuntu 1-2 years ago. Maybe the other shells don't have the correct linkage or user permissions.

[LouieMartin]

Same problem Yarn Version: 1.22.7

[LouieMartin]

Didn't realize until I actually used git bash 🤣

[pabl0xf]

still the same problem, been 5 years or more. Latest yarn version on win 11 using gitbash :(

[JcynR]

Still happening but yarn init -y seems to work fine

[xadxtya]

I think it doesn't work with git, I had the same problem but it started to work normally when I used powershell or command prompt.