stdout is not a tty on git bash on Windows

[allevo]

Hi,
I tried to run the below command in git bash under Windows 11 and an error is shown as described below.

$ node http-fastify-complete.mjs | pino-pretty
stdout is not a tty

In fact the git bash is not a tty as desccribed below.

$ node -e 'console.log(tty.isatty())'
false

Is there any change to use pino-pretty in git bash?

Thanks

[mcollina]

Have you tracked down where that error come from? I don't think it comes from pino-pretty.

[allevo]

you are right.

$ echo 'foo' | pino-pretty
foo

works fine.

so, probable it is a problem of node itself?

[mcollina]

I don't know to be honest. Maybe something in the http-fastify-complete example?

[allevo]

I don't think so

$ node -e 'console.log(666)' | pino-pretty
stdout is not a tty

[mcollina]

Does node -e 'console.log(666)' work?

[allevo]

yes

$ node -e 'console.log(666)'
666

[mcollina]

Unfortunately I do not have a windows machine to debug this :(. If it's on pino or pino-pretty, could you send a PR?

[allevo]

seems to be a worse scenario

$ echo 'foo' | node -e 'process.stdin.pipe(process.stout)'
stdin is not a tty

Any suggestion? Just where / how to proceed here: I really don't know if it is a bad stuff on my shell, nodejs problems or others....

[jsumners]

I do not believe Bash as delivered by git for Windows is a true posix implementation. I think it is based on Cygwin. You should try LFS for Windows.

[allevo]

I do not believe Bash as delivered by git for Windows is a true posix implementation. I think it is based on Cygwin. You should try LFS for Windows.

I don't understand, sorry. Do you mean LargeFileSystem for Windows? Do you have some links?

[jsumners]

This https://docs.microsoft.com/en-us/windows/wsl/about

Windows is a video game OS for me 🤷‍♂️

[allevo]

Really thanks for your answers.
Anyway, with PowerShell all the above commands work fine.
So probably, this issue happens only with git bash.

Can I send a PR for updating the documentation?
Probably it is better to have a little section for advising people to use right shells (but I don't know what in this case means right....)

[jsumners]

Can I send a PR for updating the documentation?

Yes.

[SadMap]

using node.exe -e 'console.log(666)' | pino-pretty works just fine

https://stackoverflow.com/a/62532536
@mcollina

[temsa]

using node.exe -e 'console.log(666)' | pino-pretty works just fine https://stackoverflow.com/a/62532536 @mcollina

According to the answers in the ☝️ SO thread:

Git bash is establishing some aliases in its /etc/profile.d/aliases.sh. This includes node which is tested for existing prior to declaring alias node="winpty node.exe". So, node is implicitly run through winpty while node.exe is not.

You can also see it in the actual aliases.sh file

Also git-bash has some issues link more or less to that

• tty settings for git hooks do not match git on other platforms git-for-windows/git#2914
• node stdout is not a tty git-for-windows/git#2651

I also found that we can run either node or node.exe from winpty -Xallow-non-tty (an undocumented option ) as a workaround, e.g. :

$ winpty -Xallow-non-tty node.exe -e 'console.log(666)' | pino-pretty
666
$ winpty -Xallow-non-tty node -e 'console.log(666)' | pino-pretty
666

I'm considering making a small PR on git-bash (aka git-for-windows ) for adding -Xallow-non-tty to the winpty command in the aliases.sh to avoid this kind of trouble for all the aliased programs

[Toooony]

I spent almost whole day on this. (windows 10, trying to use psql would return stdin is not tty)
The only thing that worked for me was to reinstall git and choose Use Windows default console window

As it was suggested on this answer:
https://stackoverflow.com/a/52264707/2357318

Ironically is in the same page along with the more popular answer about writing node.exe instead of node (I give that a try too. It wouldn't throw the error but neither would it execute anything).

[GerHobbelt]

stdin is not a tty is almost always the result of _isatty() returning zero (i.e. not a TTY).

Work-around: use winpty

This has (unfortunately) been a known problem with git-for-windows / bash on Windows: depending on your install options¹ this may happen.

The work-around is to prefix any command you wish to have a full-fledged TTY with winpty, e.g.

winpty node -i

Winpty is installed by git-for-windows, so should be available to you in the very shell where you experience this issue.

Reference material

• https://stackoverflow.com/questions/48623005/docker-error-on-windows-the-input-device-is-not-a-tty-if-you-are-using-mintty (yes, there's other places where isatty() may fail as well!)
• https://stackoverflow.com/questions/48199794/winpty-and-git-bash
• https://stackoverflow.com/questions/32597209/python-not-working-in-the-command-line-of-git-bash (that's another isatty() failure; same problem, different effect)
• https://stackoverflow.com/questions/48749738/how-do-i-get-colorized-output-on-my-windows-git-bash-terminal (ditto; join the club! 🤡 )
• https://github.com/rprichard/winpty
• [4.0.0 | Git Bash | Windows 10] stdin is not a tty typicode/husky#627 (just to note: exec < /dev/tty DOES NOT work for me; winpty DOES and is the generally advertised solution out there.)
• node stdout is not a tty git-for-windows/git#2651
• https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/isatty?view=msvc-170
• https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/posix-isatty?view=msvc-170
• https://stackoverflow.com/questions/36258224/what-is-isatty-in-c-for

Footnotes

1. personal experience is that some git-for-windows releases in the past did not exhibit this issue, even when I did not use that 'default console' setting during git-for-windows installation, but insert some handwaving here, as that same devbox environment has seen some weird shit over the years and nobody seems to know how this issue shows up exactly. Anyway, what definitely works is either re-installing git-for-windows with that 'use windows console' config radio button TICKED or using winpty as the code starter when you need that TTY behaviour you crave. 😉 ↩