Date: Wed, 12 Jan 2000 17:45:51 -0500 From: Garance A Drosihn <drosih@rpi.edu> To: Garrett Wollman <wollman@khavrinen.lcs.mit.edu> Cc: "Rodney W. Grimes" <freebsd@gndrsh.dnsmgr.net>, current@FreeBSD.ORG Subject: Re: Additional option to ls -l for large files Message-ID: <v0421010ab4a2b121c34e@[128.113.24.47]> In-Reply-To: <200001122151.QAA75948@khavrinen.lcs.mit.edu> References: <200001120201.SAA26378@gndrsh.dnsmgr.net> <v04210106b4a296b28cc2@[128.113.24.47]> <200001122151.QAA75948@khavrinen.lcs.mit.edu>
next in thread | previous in thread | raw e-mail | index | archive | help
At 4:51 PM -0500 1/12/00, Garrett Wollman wrote: ><<On Wed, 12 Jan 2000, Garance A Drosihn <drosih@rpi.edu> said: > > > In 'ls' we are not talking about a block count, we are talking about > > a byte-count. > >ls -s Hmm, valid point. 'ls -l' is not using a block count though, and so all of my previous comments still make sense for 'ls -l' and the new option. 'ls -s' and the new option should follow a block count, but then 'ls -s' is showing a block count for ALL files that it lists. The examples I gave in my previous message don't end up as confusing for 'ls -s' as they do for 'ls -l'. Maybe the new option should not even apply to 'ls -s'? I have no preference for 'ls -s' behavior. In any case, I'm still saying that in practice, people will find it less confusing if 'ls -l' used 1000 as the divisor, not 1024. Or at least, I found it less confusing, when I have done this same thing. Yes, it may be "more pure" to use 1024 when comparing 'ls' listings to block counts, but it is less confusing WITHIN a single 'ls -l' listing if all the numbers are decimal, and not some combination of base-10 and base-2. 'ls -l' listings (without the -s...) are already a problem when comparing to 'du' or 'df' listings. --- Garance Alistair Drosehn = gad@eclipse.acs.rpi.edu Senior Systems Programmer or drosih@rpi.edu Rensselaer Polytechnic Institute To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?v0421010ab4a2b121c34e>