On 2026/01/16 19:59, Ingo Schwarze wrote:
> 
> I think this is a case where being less specific is more valuable:
> being less specific conveys a feeling to the reader that the output
> is mainly intended for human consumption.  Also, being very specific
> has little value as simply running ls(1) in an arbitrary directory
> makes it clear how the output looks (roughly, in usual cases).
> 
> So, here is what i propose; OK?
>   Ingo
> 
> 
> Index: ls.1
> ===================================================================
> RCS file: /cvs/src/bin/ls/ls.1,v
> diff -u -r1.79 ls.1
> --- ls.1	24 Oct 2016 13:46:58 -0000	1.79
> +++ ls.1	16 Jan 2026 18:47:59 -0000
> @@ -281,8 +281,7 @@
>  .Fl g ) ,
>  group,
>  size in bytes,
> -time of last modification
> -.Pq Dq mmm dd HH:MM ,
> +date and time or date and year of last modification,
>  and the pathname.
>  In addition, for each directory whose contents are displayed, the first
>  line displayed is the total number of blocks used by the files in the
> 

Good idea - ok.


On 2026/01/16 20:04, Crystal Kolipe wrote:
> Any half sensible script that was parsing dates from ls(1) would surely be
> using -T together with -l, (or -g, or -n), anyway, so the 'mmm dd HH:MM' would
> not even apply in that case.
> 
> 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.