Re: [PATCH] ls: optional ANSI SGR output

On 8/14/26 23:00, Crystal Kolipe wrote:
> Something like this is highly unlikely to make it into base, especially as
> colorls already exists as a way to quickly and easily get equivalent
> functionality.
> 
> But for future reference developing patches for submission, here are some
> observations:
> 
> * Console control sequences should almost certainly be derived from terminfo,
>    because although ANSI SGR is widespread enough that it mostly 'just works',
>    it's not considered good practice to hard code support for a particular
>    standard.
> 
> * If the base program you propose modifying is included on the ramdisk kernel
>    then any changes will need to be tested in that environment and space
>    considerations taken into account.  (On the other hand, if you can
>    meaningfully reduce the footprint of a ramdisk included program without
>    changing functionality, that would likely be well received).
> 
> * How did you decide on 'e' and 'E' as the command line options?
>    Do these conflict with any other widely used ls implementations?
> 
> By the way, not sure if you realise, but colorls is effectly just regular ls
> from base with patches to implement the colour functionality.  If you look at
> the source code archive and ports makefile for colorls, you'll see that all of
> the colour stuff is added via ports patches in sysutils/colorls/patches/* .

Thanks for the detailed response; it is exactly the sort of feedback
I was hoping to get.

I wasn't aware that colorls is essentially base ls with the colour
functionality carried as ports patches. I had looked at it primarily
from the resulting implementation/behaviour, that's useful context.
My motivation wasn't really to produce a competing colorls, but to
explore how much of the functionality could be provided by a
relatively small modification to the existing ls.

Regarding terminfo, I did consider it, but chose not to use it. My
concern was that $TERM/terminfo adds an env. assumption which can
itself be incorrect. Since the user is explicitly requesting SGR
output, I felt that supporting a small subset directly was a
reasonable tradeoff (in this case). I certainly understand the
argument for terminfo and the potential support of other
non-ANSI/SGR terminal control characters however.

The ramdisk point is particularly interesting. I had intentionally
kept the implementation to fixed-size buffers and existing FTS/stat
information, with no additional filesystem lookups or libraries, but I
hadn't considered the ramdisk footprint separately.

For -e/-E, other than a quick look at GNU and FreeBSD implementations,
and the corresponding POSIX spec. I simply stole the first free
character (with both cases) available; compatibility with other ls
implementations is indeed worth considering more systematically.

Thanks again, specifically the points about ramdisk builds and the
relationship to colorls, the feedback is helpful.

-- 
Tyler Anderson | Canada/Pacific