Could not open terminal for stdout: Could not get termcap entry

[Redrield]

Expected Behavior

Gradle should function as normal

Current Behavior

Build fails with the error in the title

Context

I'm trying to run a gradle build, along with some other tasks. When I run gradle, it fails with the error in the title. When I run gradle as so: TERM=dumb gradle build it functions. The current value of my TERM variable is xterm-256color. Gradle was working fine before today, but after rebooting and applying updates it fails to work.

Steps to Reproduce (for bugs)

1. Clone https://github.com/FRCTeam4069/Year2018
2. run gradle build with TERM=xterm-256color
3. Build will fail with the error in the title

Your Environment

Can't get a build scan without altering TERM value.

OS: Arch Linux
Kernel version: 4.15.3-2-ARCH
Gradle version: 4.5.1

[tadfisher]

What did you do to fix this? It looks like Arch removed the termcap database as it's been replaced by terminfo.

Gradle should probably use terminfo as well for native terminal support, as termcap is pretty ancient and unmaintained.

[Redrield]

I just screwed with the Konsole environment to change the TERM variable to something that's in the database, in this case xterm-color

[calcmogul]

I had this issue last night as well (same build environment as OP) and discovered the same workaround. xterm-256color is a valid TERM setting though, so using a different setting as a workaround doesn't change the fact that there's a bug in Gradle.

[Redrield]

I checked my local database and couldn't find xterm-256color, so I assumed that's what was causing my problems

[calcmogul]

At least for terminfo, xterm-256color exists and is currently recognized as my terminal type. infocmp xterm-256color also prints a bunch.

[tav@myriad ~]$ tset -q
xterm-256color
[tav@myriad ~]$ ls /usr/lib/terminfo/x | grep xterm-256color
xterm-256color

[tadfisher]

I uninstalled ncurses5-compat-libs and that seemed to fix it.

[Redrield]

Actually yeah, now that I grep xterm-256color is in there. In that case this is definitely a bug with gradle

[tadfisher]

I don't think this is a bug in Gradle; native-platform is just calling ncurses `tgetent()`, which for me was messed up when `ncurses5-compat-libs` was installed. Other ncurses programs calling this were failing as well or falling back to dumb terminal modes.

…

On Mon, Feb 19, 2018, 3:54 PM Redrield ***@***.***> wrote: Reopened #4426 <#4426>. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#4426 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAH4fFQvunCVTKALrHYvhYu2D5jeVslJks5tWgmXgaJpZM4SJxcW> .

[Redrield]

I'll try to reproduce at home after uninstalling compat libs and see if I still get it

[calcmogul]

I have ncurses5-compat-libs installed and the test program I wrote last night from the native-platform code worked fine for me:

[tav@myriad ~]$ cat Main.cpp
#include <cstdlib>
#include <iostream>

#include <curses.h>
#include <term.h>
#include <unistd.h>

int main() {
    int current_terminal = -1;
    int output = 0;

    if (!isatty(output + 1)) {
        std::cout << "not a terminal" << std::endl;
        return 1;
    }
    if (current_terminal < 0) {
        char* termType = std::getenv("TERM");
        if (termType == nullptr) {
            std::cout << "$TERM not set" << std::endl;
            return 1;
        }
        int retval = tgetent(nullptr, termType);
        if (retval != 1) {
            std::cout << "could not get termcap entry" << std::endl;
            return 1;
        }

        std::cout << "$TERM=" << termType << std::endl;
    }
}
[tav@myriad ~]$ g++ -o Main Main.cpp -lncurses
[tav@myriad ~]$ ./Main
$TERM=xterm-256color

[calcmogul]

Uninstalling ncurses5-compat-libs made Gradle work for me immediately, but Gradle then always acts as if TERM=dumb is set or --console=plain was passed. This occurs even if I change TERM to a non-broken value like in TERM=xterm-color ./gradlew build.

If I install ncurses5-compat-libs again, Gradle has the same breaking behavior as before with TERM=xterm-color ./gradlew build building successfully with non-plain, colored console output.

[lipnitsk]

This just started happening for me after the latest Arch update. A root cause would be good to know, but thanks for the TERM=xterm-color workaround. Also would be good to know why ncurses5-compat-libs is a must for Gradle pretty console output

[franciscocpg]

Same for me (happening after the latest Arch update).

TERM=xterm-256color breaking everything is very strange.

[fredszaq]

Hello !

The problem seems to come from the update to ncurses 6.1 on Archlinux. The ncurses5-compat-libs on AUR is still build based on the 6.0 release.

I've posted an updated PKGBUILD in the comments here hopefully it will be updated by the maintainer soon.

With the ncurses5-compat-libs built with my PKGBUILD, gradle works fine and with colored output

cheers !

[djreep81]

I was also having the same issue on archlinux after upgrade. I replaced the PKGBUILD for the ncurses5-compat-libs that fredszaq provided. That worked great. everything back to normal. Thanks fredszaq

[cxspxr]

it's been just fixed, get the update from AUR

[jbaldassari]

it's been just fixed, get the update from AUR

@caspermadara what has been fixed? Did this turn out to be an issue with ncurses 6.1 or some incompatibility between that package and ncurses5-compat-libs? It looks like Arch is up to 6.1-r3.

I'm running into the same problem on Gentoo with ncurses 6.1-r2. There is no ncurses5-compat-libs package in the Gentoo repos, so I don't think that's the issue. Maybe I'll try downgrading to 6.0-r1, which was working fine.

[jbaldassari]

I filed a related bug here: https://bugs.gentoo.org/651644

[calcmogul]

ncurses5-compat-libs is ncurses6 built with the old ncurses ABI (ABI 5). If I recall correctly, the package versions of ncurses and ncurses5-compat-libs not matching broke things.

[eriwen]

This seems to be fixed. Please re-open if it's discovered to be a Gradle bug.

[Coehill]

I'm still getting this issue on Manjaro Linux XFCE. @tadfisher's solution worked for me though.

[ihexon]

I uninstalled ncurses5-compat-libs and that seemed to fix it.

Yes, THis fix the issue, But the gradle can not output color anymore....

[msva]

@eriwen

1. IIRC, even issue-opener can't re-open issue after it was closed by project member
2. I'd bet it's gradle bug, because all the other soft in the same conditions (both ncurses-5 and 6 installed altogether) works like a charm without complaining about TERM or anything. It's only gradle who complains on termcap, in the first place.
   As already mentioned, termcap is deprecated long time ago, and modern distributions even disable it when building ncurses packages.
   All the "fixes" mentioned here are just workaround in one or another way: changing TERM, passing --console=plain (btw, my 5.1.1 somewhy ignores it), and even Archlinux users hack of building ncurses-6 with ABI-5 and symlinking libtic...

I think, gradle should either use a terminfo or return to the "old" ("plain") behaviour and drop that "marmalade" (like, say, progressbar) things away.

[lJoublanc]

workaround for me was to use TERM=xterm enviornment variable in linux, in case anyone stumbles here from google.

[blshkv]

@eriwen please re-open and review this bug. Our user just hit this bug with gradle 5.2.1

[ZeroChaos-]

Another work-around is to "unset TERM". doesn't seem to have any adverse reaction (builds fine)

[winksaville]

I'm on a recent Arch Linux update

$ uname -a
Linux wink-desktop 5.2.11-arch1-1-ARCH #1 SMP PREEMPT Thu Aug 29 08:09:36 UTC 2019 x86_64 GNU/Linux

And tried to use the wrapper (./gradlew) supplied by the project author. It failed and a work-around was to use @ZeroChaos- suggestion of "unset TERM". Using gradlew seems to be the suggested way of using gradle, but any work arounds specific to Arch Linux don't work as I don't have gradle installed in the system.

So as suggested multiple times, it seems gradle should be able to use terminfo in some manner.

My 2 cents.

[cono]

Same issue here. Wrapper ./gradlew doesn't give any help.

Gentoo linux with latest stable ncurses installed here:

     Installed versions:  5.9-r101(5/5)(03:46:21 PM 07/16/2019)(tinfo unicode -gpm ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="64 -32 -x32")
                          6.1_p20181020(0/6)(02:11:42 AM 07/20/2019)(cxx split-usr tinfo unicode -ada -debug -doc -gpm -minimal -profile -static-libs -test -threads -trace ABI_MIPS="-n32 -n64 -o32" ABI_RISCV="-lp64 -lp64d" ABI_S390="-32 -64" ABI_X86="32 64 -x32")

term:

# echo $TERM
xterm-256color
# tset -q
xterm-256color

[Tapchicoma]

@cono fix for Gentoo that worked for me - you need to uninstall =sys-libs/ncurses-5.9-r101, then this issue went away.

[cono]

@Tapchicoma thanks, but I don't think I can:

sudo emerge -av --depclean '=sys-libs/ncurses-5.9-r101'

Calculating dependencies... done!
  sys-libs/ncurses-5.9-r101 pulled in by:
    net-misc/dropbox-58.3.88-r1 requires sys-libs/ncurses:5/5
    net-misc/telnet-bsd-1.2-r1 requires sys-libs/ncurses:=, sys-libs/ncurses:5/5=
...

[AdislanSaidov]

workaround for me was to use TERM=xterm enviornment variable in linux, in case anyone stumbles here from google.

it worked, thanks

[joakim-tjernlund]

I think I have an explanation in:
https://bugs.gentoo.org/648720

[Pistos]

I solved it on my Gentoo system by upgrading sys-libs/ncurses-compat (from 5.9 to 6.1) so that its version matched sys-libs/ncurses (6.1). Didn't need to fiddle with my TERM env var (which happened to be tmux-256color).

[stale]

This issue has been automatically marked as stale because it has not had recent activity. Given the limited bandwidth of the team, it will be automatically closed if no further activity occurs. If you're interested in how we try to keep the backlog in a healthy state, please read our blog post on how we refine our backlog. If you feel this is something you could contribute, please have a look at our Contributor Guide. Thank you for your contribution.

[blshkv]

ping, unstale