On 27/02/15 13:48, Karel Zak wrote:
> On Mon, Feb 16, 2015 at 11:32:41AM +0100, Samuel Thibault wrote:
>> Karel Zak, le Mon 16 Feb 2015 10:47:47 +0100, a écrit :
>>> On Mon, Feb 16, 2015 at 04:35:33AM -0500, Mike Frysinger wrote:
>>>> On 16 Feb 2015 10:10, Karel Zak wrote:
>>>>> What we want to duplicate? What exactly in lib/colors.c is duplicate?
>>>>> The code evaluates filenames and parses files with "name colorcode".
>>>>
>>>> whether the terminal even supports color in the first place. if i picked a
>>>> terminal that doesn't support color so i didn't have to worry about it, it's a
>>>> bit crazy i also have to go to multiple config files and also tell them i don't
>>>> want color otherwise i get corrupted output.
>>>
>>> For now it checks isatty() and nothing else, it would be possible to
>>> check number of supported colors in terminfo too, or is there any
>>> other way?
>>
>> It should also check how to change the colors. Not all terminals will
>> support the ANSI way.
>
> OK, linked with libtinfo, now it checks if the current terminal supports
> colors ("colors" from tinfo) and all the stuff is disabled for terminals
> like vt100.
>
>>> Anyway, we don't want to create (duplicate) any database, all it
>>> provides are knobs for customization and enable/disable.
>>
>> It provides only that because the source code currently hardcodes the
>> \033[%sm sequence, but it really should not, and use terminfo instead.
>
> This is not implemented yet, I (or any volunteer?) will try to add to code
> an extra layer to avoid the hardcoded sequences and read the colors from terminfo.
I'd be careful to not over engineer that.
coreutils currently hardcodes ansi sequences,
and I've not heard specific complaints about it.
What terminals are not catered for here?
--
To unsubscribe from this list: send the line "unsubscribe util-linux" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
