Skip to content

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

@jmathew

Description

@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:
#743

This yielded a fix that tried to autodetect mintty and use winpty:
#2243

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

This fix was removed in favor a explicit environment variable in:
#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.

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions