* Paul Eggert (egg...@cs.ucla.edu) wrote:
> On 9/8/22 14:23, Andreas Dilger wrote:
> > GNU "ls" has this unfortunate misfeature of reading the whole directory to
> > read+stat every entry in a directory to determine field width before
> > displaying anything (even if unsorted), and this is a real
On 9/10/22 09:51, Dr. David Alan Gilbert wrote:
Why 'user/group size' and not two separate fields of 'user/group' and 'size'?
Two separate fields would consume more screen space, because the first
column is left-adjusted and the second column is right-adjusted. It's
the same reason that tradi
On 9/8/22 14:23, Andreas Dilger wrote:
GNU "ls" has this unfortunate misfeature of reading the whole directory to
read+stat every entry in a directory to determine field width before displaying anything
(even if unsorted), and this is a real problem for large directories on a network
filesyste
Whatever the limit may be, can't/shouldn't the list output always arrange
the columns correctly below each other at least for such short user and
group names as in my example?
Look at
https://github.com/libfuse/libfuse/releases/download/fuse-3.11.0/fuse-3.11.0.tar.xz
for a real life example:
$ t
On Sep 8, 2022, at 13:01, Paul Eggert wrote:
>
> On 9/8/22 12:25, Ingo Brückl wrote:
>> I'm talking about the Unix
>> UserID/GroupID with a historical maximum of 8*characters* each!
>
> I see no such limit in 7th Edition Unix. The only limit I see is around 500
> bytes for user and group name
On 9/8/22 12:25, Ingo Brückl wrote:
I'm talking about the Unix
UserID/GroupID with a historical maximum of 8*characters* each!
I see no such limit in 7th Edition Unix. The only limit I see is around
500 bytes for user and group names.
Paul Eggert wrote:
> I don't know where that "8" comes from. In the original Unix, user IDs had
> at most 5 digits.
Oh, misunderstanding!
I chose the digits only to show the influence of the length of the UserID
(name!) and GroupID on the list output. But I'm talking about the Unix
UserID/GroupI
On 9/8/22 03:46, Ingo Brückl wrote:
The offset seems to occur when length(u_id) + length(g_id) >= 14.
Wouldn't it make sense to at least consider the possible Unix length
(8-digit u_id, g_id)?
Sorry, I don't know where that "8" comes from. In the original Unix,
user IDs had at most 5 digits.
The offset seems to occur when length(u_id) + length(g_id) >= 14.
Wouldn't it make sense to at least consider the possible Unix length
(8-digit u_id, g_id)?
Since tar can't know the maximum values in each column, other than by
looking at machine maximum, it'd havetomake those columns very wide to
have them line up. I doubt whether that would be a win in general.
10 matches
Mail list logo
