Subject: Re: bug#56710: ls vs. stat display of st_size

From: Pádraig Brady <[email-masked]>
Date: Sun, 24 Jul 2022 18:14:31 +0100

On 24/07/2022 17:18, Paul Eggert wrote:
> On 7/24/22 01:48, Pádraig Brady wrote:
> 
>> Well ls(1) was explicitly changed to assuming only positive,
>> citing POSIX (though I can't see it in POSIX myself):
>> https://github.com/coreutils/coreutils/commit/67ba4ac01
> 
> I vaguely recall being involved with that decades-old change. The POSIX
> requirement is here:
> 
> https://pubs.opengroup.org/onlinepubs/9699919799/utilities/ls.html#tag_20_73_10
> 
> (look for "%u").

Right, that's fairly conclusive for ls.

>> Also ls(1) can sort by size, which gives a little more
>> credence to assuming positive only size.
> 
> I don't see why; negative sizes sort just as well as positive ones do.

Fair enough.

>> For these reasons I would keep ls(1) as is (assuming positive).
>>
>> As for stat(1), it's now consistent with ls(1) which has some benefit.
>> It is lower level though, so in my mind it might be better
>> to output the raw value, especially since it's such an edge case.
>>
>> So I'd leave ls(1) as is, and I'll leave it up to you
>> how to handle stat(1) given the above points.
> 
> Consistency is reasonably important here (as per the original bug
> report), so if those are the choices let's leave things as-is.

Cool.

For reference stat(1) on FreeBSD takes the lower level approach,
outputting signed by default (I presume from looking at the man page),
and allowing the user to override that.  I.e. it defaults
to `stat -f %z` but the user can override to `stat -f %Uz`.
We don't have many letters left to play with but I suppose
we could default to unsigned (as we now are) and support %Is etc.
for signed integer quantities. I'm not suggesting we need this,
just thinking out loud.

cheers,
Pádraig