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/ :)

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