From: Crystal Kolipe <kolipe.c@exoticsilicon.com>
Subject: Re: [PATCH] ls: optional ANSI SGR output
To: Tyler Anderson <achaean@sinelabs.ca>
Cc: tech@openbsd.org
Date: Sat, 15 Aug 2026 06:00:39 -0000

On Fri, Aug 14, 2026 at 11:44:22AM -0700, Tyler Anderson wrote:
> I've been carrying a small local mod to ls, adding optional ANSI SGR
> colouring, and I'd like to put it up for discussion.

[ ... ]

> I'm
> particularly interested in feedback on both the implementation and
> whether this is something that would be appropriate for base at all.

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/* .