GNU bug report logs - #56710
ls vs. stat display of st_size

Previous Next

Full log

View this message in rfc822 format

From: Paul Eggert <eggert <at> cs.ucla.edu>
To: Pádraig Brady <P <at> draigBrady.com>
Cc: 56710 <at> debbugs.gnu.org, schwab <at> linux-m68k.org
Subject: bug#56710: ls vs. stat display of st_size
Date: Sun, 24 Jul 2022 09:18:45 -0700

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").


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


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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.