>FreeBSD's utilities in contrast check for the largest required width and >adjusts output accordingly:
>-rwsr-s--x 1 oracle dba 133894000 Mai 29 2006 oracle* >-rwxr-xr-x 1 oracle dba 1339524 Mai 19 2006 oratclsh* >-rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxml* >-rwxr-xr-x 1 oracle dba 48 Sep 25 2000 oraxsl* >-rwxr-xr-x 1 oracle dba 10636376 Mai 29 2006 proc* There's this thing with "cut" which makes such output problematic. >So even If you don't see the absolute numbers you quickly realize that >"oracle" is two magnitudes larger than "oratclsh". > >If df had a similar output, I'd prefer this: > > 8388608 3041200 5347408 37% > 33554432 1605719 31794110 5% > 62914560 37766679 14129948 73% > 62914560 11017932 14129948 44% > 1535901696 1187247048 263079735 82% > 134217728 32200480 74728050 31% > 4194304 1392793 2801511 34% > >over this any time: > > 8.0G 2.9G 5.1G 37% > 32G 1.5G 30G 5% > 60G 36G 13G 73% > 60G 11G 13G 44% > 1.4T 1.1T 251G 82% > 128G 31G 71G 31% > 4.0G 1.3G 2.7G 34% > >I don't count digits. I just memorize patterns. More digits => larger size. Sometimes it's nice to know what the size is when you want to do something large. I must admit, though, that I do not like the way we currently split these values; e.g., I prefer 1438G over 1.4T (loss of precision, one space sacrificed to a useless ".". Similarly for 2713M over 2.7G Casper _______________________________________________ opensolaris-discuss mailing list opensolaris-discuss@opensolaris.org
