From: Ingo Schwarze <schwarze@usta.de>
Subject: Re: mtime format in ls -l
To: Crystal Kolipe <kolipe.c@exoticsilicon.com>
Cc: tech@openbsd.org, Jan Stary <hans@stare.cz>, sthen@openbsd.org
Date: Sun, 18 Jan 2026 16:21:21 +0100

Hello,

Crystal Kolipe wrote on Fri, Jan 16, 2026 at 09:55:02PM +0000:
> On Fri, Jan 16, 2026 at 08:45:18PM +0000, Stuart Henderson wrote:
>> On 2026/01/16 20:04, Crystal Kolipe wrote:

>>> I wonder if the 'see also' section should include a reference
>>> to stat(1), since ls(1) doesn't provide an option equivalent
>>> to -P in df(1), for obvious consumption by scripts.

>> I don't think there's any good portable tool to do this from the shell.
>> GNU ls doesn't do -T and we don't have the overengineered --time-style,
>> and stat(1) is probably the least portable of all the standard unix
>> utilities I've come across. Seems like a job for perl.

> We've had a similar version of this discussion before about the
> non-portability of stat(1).
> 
> But at the end of the day, people writing scripts on OpenBSD are not
> necessarily interested in portability, so that doesn't seem like a
> reason to exclude simple solutions that work without difficulty on
> OpenBSD in favour of something more complicated that hopefully
> works 'everywhere'.

Well, writing scripts portably can still be considered good practice,
even in cases where the need for portability is not immediately
apparent - on the one hand, it is not uncommon that even local,
private scripts need to be migrated in some way at some point, and
besides, always giving a thought to portability helps form and
preserve good habits, keeping coders and sysops sharp and limiting
the tendency we all have of becoming negligent and lazy over time.

Anyway, the question to ask is: will the entry be useful for a
significant number of readers of this manual page?

The most plausible reason for looking at the ls(1) manual is the
desire to inspect some properties of some files (in particular
more unusual properties, or in unusual ways).  But almost all
properties of files *can* be inspected with ls(1) - there are
very few that stat(1) can show but ls(1) cannot:

 * st_dev, the device number -
   irrelevant because it's the same for the whole file system
 * st_rdev for non-device files -
   irrelevant because it has no meaning
 * st_blksize - if i understand correctly,
   irrelevant because it's the same for the whole file system
 * st_blocks, the number of blocks allocated
 * st_birthtime, st_gen - my impression is OpenBSD does not support these(?)

So the only property that could (maybe) matter appears to be st_blocks -
but the probability of someone looking at ls(1) because they want to
inspect that field feels very low, making the benefit of adding stat(1)
to ls(1) SEE ALSO very small.

On the other hand, there is a minor downside to adding it.
While stat(1) does not sport a STANDARDS section and the HISTORY
section makes it quite apparent that it is unlikely to be particularly
portable, that is easy to overlook, in particular when getting there
from a place as prominent as the manual of the POSIX ls(1) command,
so such a link could incite people to lower portability of whatever
they are doing without even becoming aware of the issue.

So i'm mildly opposed to adding stat(1) to ls(1) SEE ALSO,
unless someone can convince me what stat(1) can provide that
readers of ls(1) might be looking for.

Yours,
  Ingo