tech-userlevel archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: colorls in base



On 15.02.2019 02:56, Rin Okuyama wrote:
> Hi,
> 
> I'd like to propose to introduction -G (colorized output) option
> to ls(1), which is compatible to FreeBSD and macOS:
> 
> http://www.netbsd.org/~rin/colorls-20190215.patch
> 
> I know that we already have misc/colorls in pkgsrc. In the era of
> statically-linked /bin, pulling terminfo stuff into /bin/ls would
> require some overhead. However, it increase only < 4KB of binary
> size for dynamically-linked /bin/ls on m68k, for example.
> 
> Also, when SMALLPROG is defined, colorized output is completely
> disabled; no additional space is required for install media.
> 

I'm for adding colors...

however can we go for GNU style that is more flexible? In LS_COLORS we
can add custom rules against regex of file name and this can be very useful.

http://linux-sxs.org/housekeeping/lscolors.html

We will also win more compat with existing shells and interoperability.

The FreeBSD style in my opinion generates too many env variables
CLICOLOR, COLORTERM, COLORS, CLICOLOR_FORCE, LSCOLORS and this
implementation is partial (it doesn't honor COLORTERM). Also it's not so
flexible.

I think that COLORTERM as top-level variable for all userland utilities
and *_COLOR is more natural. We could grow next PS_COLORS for ps(1) and
retain compat with GNU.

-G option could be skipped entirely in my opinion and we could rely on
env(1) only.

I don't have stronger opinion on dynamic linking, but maybe dlopen(3)
for libterminfo can be used as microptimization? Recently we were
optimizing similarly sh(1).

> Thanks,
> rin
> 


Attachment: signature.asc
Description: OpenPGP digital signature



Home | Main Index | Thread Index | Old Index