[asterisk-bugs] [JIRA] (ASTERISK-25695) safe_asterisk -c breaks color in asterisk -r because of missing TERM for /dev/tty.

[Walter Doekes (JIRA)]

     [ https://issues.asterisk.org/jira/browse/ASTERISK-25695?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Walter Doekes updated ASTERISK-25695:
-------------------------------------

    Description: 
Unfortunately, color support isn't sane yet.

If asterisk is started with console=yes and the TERM environment variable isn't set to something that supports color, then {{asterisk -r}} doesn't get any color.

In fact, we're talking two bugs:
(1) safe_asterisk default settings break color support in rasterisk.
(2) Asterisk reads TERM in the master process to decide whether color support should be enabled in data fed to the rasterisken.

Quickest/partial fix would be to fix 1:
for example, we could do this (see ASTERISK-25695_safe_asterisk_TERM.patch):
{noformat}
        if test "$CONSOLE" != "no"; then
+               # If TERM is not set, the rasterisk would get no color.
+               # Set to safe default for BSD and Linux.
+               test -z "$TERM" && export TERM=xterm
                ASTARGS="${ASTARGS} -c"
        fi
{noformat}

However, that might enable color support for several installations, and that would cause more visibility to the fact that the {{-n}} option does absolutely nothing (ooh, bug number (3)!) -- except disable color support on the application itself, but not for feeding back/forth data from the (colorized) asterisk daemon.

  was:
Unfortunately, color support isn't sane yet.

If asterisk is started with console=yes and the TERM environment variable isn't set to something that supports color, then {{asterisk -r}} doesn't get any color.

In fact, we're talking two bugs:
(1) safe_asterisk default settings break color support in rasterisk.
(2) Asterisk reads TERM in the master process to decide whether color support should be enabled in data fed to the rasterisken.

Quickest/partial fix would be to fix 1:
for example, we could do this:
{noformat}
--- a/contrib/scripts/safe_asterisk
+++ b/contrib/scripts/safe_asterisk
@@ -125,6 +125,9 @@ if test -n "$TTY" && test "$TTY" != "no"; then
        fi
        ASTARGS="${ASTARGS} -vvvg"
        if test "$CONSOLE" != "no"; then
+               # If TERM is not set, the rasterisk would get no color.
+               # Set to safe default for BSD and Linux.
+               test -z "$TERM" && export TERM=xterm
                ASTARGS="${ASTARGS} -c"
        fi
 fi
{noformat}
(I hereby release all my claims for this inline patch, as usual)

However, that might enable color support for several installations, and that would cause more visibility to the fact that the {{-n}} option does absolutely nothing (ooh, bug number (3)!) -- except disable color support on the application itself, but not for feeding back/forth data from the (colorized) asterisk daemon.


> safe_asterisk -c breaks color in asterisk -r because of missing TERM for /dev/tty.
> ----------------------------------------------------------------------------------
>
>                 Key: ASTERISK-25695
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-25695
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Core/General
>    Affects Versions: 11.20.0, 13.6.0
>            Reporter: Walter Doekes
>            Severity: Minor
>         Attachments: ASTERISK-25695_safe_asterisk_TERM.patch
>
>
> Unfortunately, color support isn't sane yet.
> If asterisk is started with console=yes and the TERM environment variable isn't set to something that supports color, then {{asterisk -r}} doesn't get any color.
> In fact, we're talking two bugs:
> (1) safe_asterisk default settings break color support in rasterisk.
> (2) Asterisk reads TERM in the master process to decide whether color support should be enabled in data fed to the rasterisken.
> Quickest/partial fix would be to fix 1:
> for example, we could do this (see ASTERISK-25695_safe_asterisk_TERM.patch):
> {noformat}
>         if test "$CONSOLE" != "no"; then
> +               # If TERM is not set, the rasterisk would get no color.
> +               # Set to safe default for BSD and Linux.
> +               test -z "$TERM" && export TERM=xterm
>                 ASTARGS="${ASTARGS} -c"
>         fi
> {noformat}
> However, that might enable color support for several installations, and that would cause more visibility to the fact that the {{-n}} option does absolutely nothing (ooh, bug number (3)!) -- except disable color support on the application itself, but not for feeding back/forth data from the (colorized) asterisk daemon.



--
This message was sent by Atlassian JIRA
(v6.2#6252)