[gentoo-dev] Output of ANSI escape sequences in ebuilds

[gentoo-dev] Output of ANSI escape sequences in ebuilds

[Ulrich Mueller]

[-- Attachment #1: Type: text/plain, Size: 638 bytes --]

Some ebuilds output SGR control sequences (formerly known as ANSI escape
sequences) to the terminal, i.e., they do things like:

  echo -e "\033[1m${@}\033[0m"
  einfo "Fetching \e[1m${r}\e[22m ..."
  ewarn "\033[1;33m**************************************************\033[00m"
  echo -ne "\a"   # (not actually an ANSI escape sequence)

These prevent NOCOLOR in make.conf or emerge --color=n from working
correctly, and I guess they are also problematic from an accessibility
point of view.

Are there any objections against removing these sequences from strings?
AFAICS, they are used by less than ten packages, and one eclass.

Ulrich

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

[Toralf Förster]

[-- Attachment #1.1: Type: text/plain, Size: 366 bytes --]

On 12/14/19 8:16 AM, Ulrich Mueller wrote:
> These prevent NOCOLOR in make.conf or emerge --color=n from working
> correctly, and I guess they are also problematic from an accessibility
> point of view.
+1


Good idea Ulrich !
The SGR control sequences are annoying in script based grepping of issues of log streams.

-- 
Toralf
PGP 23217DA7 9B888F45


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

[Kent Fredric]

[-- Attachment #1: Type: text/plain, Size: 1138 bytes --]

On Sat, 14 Dec 2019 08:16:03 +0100
Ulrich Mueller <ulm@gentoo.org> wrote:

> These prevent NOCOLOR in make.conf or emerge --color=n from working
> correctly, and I guess they are also problematic from an accessibility
> point of view.
> 
> Are there any objections against removing these sequences from strings?
> AFAICS, they are used by less than ten packages, and one eclass.

Maybe we can have some future EAPI feature, or special eclass, that
allows people to add escape codes while also respecting the
configuration.

Sort of like what git has in its formatting codes, where they're turned
off when colours are turned off.

  hl 1 "${@}"  # because 'hl' inherently behaves like echo when not captures 
  einfo "Fetching $(hl "${r}" ) ..."

Or something along those lines?

I'd wager that a large body of things "not using it" is not because
it wouldn't be useful, but due to people knowing this problem exists?

-- Further Bikeshed --

Maybe it could even be thematic?

   "Fetching $(hl url https://path.to/whatever )"

Nah.

But < hl <colour-code-string> <string> > as a general concept works.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 616 bytes --]

On Sat, Dec 14, 2019 at 10:31:06AM +0100, Toralf Förster wrote:
> On 12/14/19 8:16 AM, Ulrich Mueller wrote:
> > These prevent NOCOLOR in make.conf or emerge --color=n from working
> > correctly, and I guess they are also problematic from an accessibility
> > point of view.
> +1
> 
> 
> Good idea Ulrich !
> The SGR control sequences are annoying in script based grepping of issues of log streams.

I agree more with this concern than an accessibility. Along the same
lines, this is a concern when redirecting emerge output to a file then
loading that file into an editor to do searches.

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

[Michael 'veremitz' Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 1293 bytes --]

On 14/12/19 12:03, Kent Fredric wrote:
> On Sat, 14 Dec 2019 08:16:03 +0100
> Ulrich Mueller <ulm@gentoo.org> wrote:
>
>> These prevent NOCOLOR in make.conf or emerge --color=n from working
>> correctly, and I guess they are also problematic from an accessibility
>> point of view.
>>
>> Are there any objections against removing these sequences from strings?
>> AFAICS, they are used by less than ten packages, and one eclass.
> Maybe we can have some future EAPI feature, or special eclass, that
> allows people to add escape codes while also respecting the
> configuration.
>
> Sort of like what git has in its formatting codes, where they're turned
> off when colours are turned off.
>
>   hl 1 "${@}"  # because 'hl' inherently behaves like echo when not captures 
>   einfo "Fetching $(hl "${r}" ) ..."
>
> Or something along those lines?
>
> I'd wager that a large body of things "not using it" is not because
> it wouldn't be useful, but due to people knowing this problem exists?
>
> -- Further Bikeshed --
>
> Maybe it could even be thematic?
>
>    "Fetching $(hl url https://path.to/whatever )"
>
> Nah.
>
> But < hl <colour-code-string> <string> > as a general concept works.
>
Something that could be included in gentoo-functions script(s)?


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: [gentoo-dev] Output of ANSI escape sequences in ebuilds

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 1094 bytes --]

On Sat, Dec 14, 2019 at 08:16:03AM +0100, Ulrich Mueller wrote:
> Some ebuilds output SGR control sequences (formerly known as ANSI escape
> sequences) to the terminal, i.e., they do things like:
> 
>   echo -e "\033[1m${@}\033[0m"
>   einfo "Fetching \e[1m${r}\e[22m ..."
>   ewarn "\033[1;33m**************************************************\033[00m"
>   echo -ne "\a"   # (not actually an ANSI escape sequence)
> 
> These prevent NOCOLOR in make.conf or emerge --color=n from working
> correctly, and I guess they are also problematic from an accessibility
> point of view.
> 
> Are there any objections against removing these sequences from strings?
> AFAICS, they are used by less than ten packages, and one eclass.

I just found another place that uses them very heavily. I don't know if
it is part of cargo.eclass, or if it is a bug in /usr/bin/ebuild, but
I'm working on an ebuild and found that if I run:

$ ebuild foobar.ebuild compile >& output

that output file is full of ansi sequences even though I have
NOCOLOR=yes in make.conf.

Thanks,

William


[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 195 bytes --]