Docker Bash Prompt Does Not Display Color Output

Docker Bash prompt does not display color output

The OP SolomonT reports that docker run with env do work:

docker run --rm -it -e "TERM=xterm-256color" govim bash -l

---

And Fernando Correia adds in the comments:

To get both color support and make tmux work, I combined both examples:

docker exec -it my-container env TERM=xterm-256color script -q -c "/bin/bash" /dev/null

---

As chepner commented (earlier answer), .bash_profile is sourced (itis an interactive shell), since bash_prompt is called by .bash_profile.

But docker issue 9299 illustrates that TERM doesn't seem to be set right away, forcing the users to open another bash with:

docker exec -ti test env TERM=xterm-256color bash -l

You have similar color issues with issue 8755.

To illustrate/reproduce the problem:

docker exec -ti $CONTAINER_NAME tty
not a tty

The current workaround is :

docker exec -ti `your_container_id` script -q -c "/bin/bash" /dev/null

Both are supposing you have a running container first, which might not be convenient here.

Docker build colored messages unreadable

[Updated 2022-08-02]

As of PR #2954 (which may take a bit to get released into Docker Desktop), you can run:

export NO_COLOR=1

There have also been changes to make the default text colors more readable.

---

[Original answer]

With docker, you can pass the --help option to a command to see usage. E.g.:

$ docker build --help

Usage:  docker build [OPTIONS] PATH | URL | -

Build an image from a Dockerfile

Options:
      --add-host list           Add a custom host-to-IP mapping (host:ip)
      --build-arg list          Set build-time variables
      --cache-from strings      Images to consider as cache sources
      --disable-content-trust   Skip image verification (default true)
  -f, --file string             Name of the Dockerfile (Default is 'PATH/Dockerfile')
      --iidfile string          Write the image ID to the file
      --isolation string        Container isolation technology
      --label list              Set metadata for an image
      --network string          Set the networking mode for the RUN instructions during build (default "default")
      --no-cache                Do not use cache when building the image
  -o, --output stringArray      Output destination (format: type=local,dest=path)
      --platform string         Set platform if server is multi-platform capable
      --progress string         Set type of progress output (auto, plain, tty). Use plain to show container output (default "auto")
      --pull                    Always attempt to pull a newer version of the image
  -q, --quiet                   Suppress the build output and print image ID on success
      --secret stringArray      Secret file to expose to the build (only if BuildKit enabled): id=mysecret,src=/local/secret
      --squash                  Squash newly built layers into a single new layer
      --ssh stringArray         SSH agent socket or keys to expose to the build (only if BuildKit enabled) (format: default|<id>[=<socket>|<key>[,<key>]])                                                                                                                     
  -t, --tag list                Name and optionally a tag in the 'name:tag' format
      --target string           Set the target build stage to build.

For turning off the colored output, you can set --progress plain which removes the color formatted text and other tty features like updating the time for each build step. You can make this the default with:

export BUILDKIT_PROGRESS=plain

Alternatively, you may just want to change the color of your terminal. Black and white both work nicely. But a bluish background will clash with the blue text.

---

The other option is to disable buildkit and revert back to the classic build engine. That can be done with an environment variable:

export DOCKER_BUILDKIT=0

or configuring the default in /etc/docker/daemon.json:

{
  "features": {"buildkit": false }
}

However, the classic builder will not support features being added to buildkit and is unlikely to see much development going forward.

Why `~/.bashrc` is not executed when run docker container?

Each command runs a separate sub-shell, so the environment variables are not preserved and .bashrc is not sourced (see this answer).

You have to source your script manually in the same process where you run your command so it would be:

CMD source /root/.bashrc && /workspace/launch.sh

provided your launch.sh is an executable.

As per documentation exec form you are using does not invoke a command shell, so it won't work with your .bashrc.

Edit:

BASH wasn't your default shell so

CMD /bin/bash -c "source /root/.bashrc && /workspace/launch.sh"

was needed in order to run your script.
If you want yo set your shell as BASH by default, you can use SHELL instruction as described in documentation, e.g.:

SHELL ["/bin/bash", "-c"]

Jq doesn't highlight Docker inspect output

Apparently, this is an idiosyncrasy of jq Windows implementation, forcing the color output with -C option, as hinted by several commenters above, resolved the issue for me:

Why run Docker container with -t?

Your test shows that color codes still work, but what it's missing is that without -t many programs will stop trying to send them.

Many programs check isatty(3) in C or [ -t 0 ] from shell scripts to see if they're connected to a TTY. If so they'll enable interactive features like colors and line editing to make the experience more pleasant.

You can witness this with shells like Bash and text editors like Vim. Programs like ls, grep and git have "auto" color modes that only use ANSI color codes interactively. If you leave out -t they'll revert to plaintext.

---

Related Topics