Skip to content

regression with tty detection #1459

Description

@ssbarnea

A recent regression was introduced via #1382 which broke detection on various conditions.

For example, on my MacOS host, only stdout and stdin report True on isatty() while stderr reports False, even if in reality there is no problem with sending ANSI to stderr.

Probably we should rely solely on stdout for the test or to assure that we respect it for each tty.

This issue is not happening with lots of people because only few of them use a method to colorize stderr, which apparently is what has a side-effect of marking it as a non tty.

Example of zsh snippet from ~/.zshrc that does this:

    export STDERRED_ESC_CODE="$fg[red]"
    if [[ "$STDERR_COLORIZE" != $$ ]]; then
      if (( $+commands[colorize] )); then
        exec 2>>(colorize $fg[yellow] $reset_color > /dev/tty &)
      else
        exec 2>>(while read line; do
          print ${fg[yellow]}$line$reset_color > /dev/tty; print -n $'\0'; done &)
      fi
      export STDERR_COLORIZE=$$
    fi

Once this runs you no longer gave a tty-enabled stderr.

Vast majority of CLI tools I know are using sys.stdout.isatty(), the only other exception I know is mypy. https://bixense.com/clicolors/ seems to support that approach too.

Regarding the never-ending struggle to control ANSI on/off behavior where each tool invented its own implementation and variables to configure behavior, it seems that someone realized that maybe is time to do something about it https://no-color.org/ :)

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions