CircleCI terminal is a TTY but TERM is not set


#1

Hi folks. Some time in the last couple of days, something has changed with regards to the way the terminal is announcing itself to programs. I think one of two things has happened:

  1. The TERM environment variable used to be set (I don’t know what the value would have been), but now it’s not.
  2. The shell output handler used to be a non-TTY file/device, but now it’s a TTY and TERM is not set.

Either way, if we’re going to have a TTY as the output, can TERM be set to “dumb”? The current state of things breaks Flow, causing it to output the following error message:

Fatal error: exception Not_found

I’ll be submitting a PR to Flow shortly too.


#2

Which executorType is this on?


#3

It’s on the docker executorType. Here’s the relevant portion of our circle.yml with the TERM variable added.

version: 2

executorType: docker

containerInfo:
  - image: node

  - image: elasticsearch

stages:
  build:
    workDir: ...
    steps:
      - type: checkout

      ...

      - type: shell
        name: 'Run tests'
        command: npm test
        environment:
          TERM: dumb
          ELASTICSEARCH_HOST: localhost
          ELASTICSEARCH_PORT: 9200

#4

That’s…weird. I’m seeing $TERM as dumb

https://circleci.com/gh/ryanwohara/test-2.0/79#config/containers/0


#5

That is odd. I just tested it and Flow is still failing with the same error. Perhaps it’s not being exported to subprocesses? Can you try a script that echoes $TERM instead?


#6

It worked under /bin/bash but not /bin/sh and calling a script
https://circleci.com/gh/ryanwohara/test-2.0/84

If setting the TERM there fixes your problem, I definitely advise keeping it. Does adding it to the top of the file work, as well?


#7

No, unfortunately not. I get the same error message as before from Flow.

I tried a few more tests. With it set in the environment, echo $TERM works in an embedded script but not when calling a script that echoes.

So that’s two bugs, I guess?


#8

Did this work on 1.0? If so, can you link me to a build for each so I can forward it on to our team? You can always PM me instead of sharing publicly.


#9

It did, and it also worked on 2.0 until earlier this week. We have commits that passed that were rebuilt to find out if this was a problem with us or with CircleCI, and failed on rebuild. I will send you links by private message.


#10

I’m also seeing this error in one of our builds.

Setting the $TERM environment variable to dumb for the command fixed the issue for me! Though it would certainly be cleaner to not need it at all.


#11

If you wrap the command in anything like sudo it’ll cause issues with your env vars.


#12

@rohara

Is there any particular reason for the change to TTY, or some option to disable it? I’m basically forced to change all progressbar-emitting commands to run through a pipe to get reasonable output.


#13

As 2.0 is today, we leave that up to you. But we’re still in beta and certainly open to changes.


#14

@rohara So I’m certainly not an expert on the topic, but the question of TTY/non-TTY for CI logs has gone around for other systems as well, e.g. Travis discussion topic.

Reasons for TTY:

  • Some rare commands (namely docker -ti) require a TTY and error out otherwise, but these can usually be fixed with different flags (dropping -ti)
  • Many commands will drop colorized output without TTY

Reasons against:

  • Usually leads to smaller log sizes (e.g progress bars will emit many lines)
  • The way the log capturer works in CircleCI 2.0, it seems to leave large blank spaces where progress bars would have been, which is very distracting

Of course, the optimal wish list solution would be enable TTY and then make the client window an actual TTY so that control codes just works properly, but that would require modifying more of the stack. I’m assuming the web terminal output is just a line-by-line stream from stdout right now.


#15

Anyway to disable TTY?


#16

@SamirTalwar did you end up submitting a PR to flow? Let me know if it didn’t get taken care of.

kinda surprised to find this issue. I’m on the Flow team! I ran into this issue with opam erroring rather than Flow, while trying to move Flow itself to CircleCI :slight_smile:


#17

Yup, it got merged in. Hasn’t been an issue for a long time. :grin:


#18

I came across the same issue building android using gradlew. The &TERM is not set.
I did add a run command to set it but no joy.

run: export $TERM=xterm

Any ideas why it still wouldn’t pick up the ENV Var?

I posted a quick question about it here:


#19

The $ is not necessary when assigning variables. It’s probably expanding the variable, so what you’re ending up with is:

export =xterm

You’ll need to remove the $ so your line looks like the following:

export TERM=xterm

#20

Your right, doing the following progressed the android build further:

- run: export TERM=xterm && ./gradlew androidDepedencies

I did notice the ./gradlew androidDepedencies command still fails but on a different issue than this question:

A problem occurred configuring project ‘:app’.

failed to find Build Tools revision 23.0.1

In my projects compileSdkVersion 23 property in build.gradle, so I need use
circleci/android:api-23-alpha docker image. But it doesn’t find the build tools on the image in the error above.

Shouldn’t the image provide the 23.0 build tools or is that an extra command in the build?

This is the yaml definition for that job:

android:
    working_directory: ~/repo/android
    docker:
      - image: circleci/android:api-23-alpha
    steps:
      - checkout:
          path: ~/repo
      - restore_cache:
          key: jars-{{ checksum "build.gradle" }}-{{ checksum  "app/build.gradle" }}
      - attach_workspace:
          at: ~/repo
      - run: sudo chmod +x ./gradlew
      - run: export TERM=xterm && ./gradlew androidDepedencies    
      - run: export TERM=xterm && ./gradlew assembleRelease