Well, right, 180cm would be a customary way to show that (probably wouldn't be shot for saying 1.8m either). And 32GB for an SD card, or whatever.
But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes to 2081 bytes because your editor dropped all the \r characters. Or a network transfer ended a bit prematurely, chopping off the end of a file.
I'd consider these to be reasonable cases where the byte-exact filesize might be more useful than the readability-friendly version of the number.
On the other hand, yeah, there are a lot of cases where I just need a general idea of the filesize. "-h" display is wonderful for that.
I think what's really in discussion here is what the default should be. ls was originally conceived and implemented in a period when all the files you would be dealing with could be measured in bytes easily, and would almost never be over four digits. Many common files today (any MP3, most word processing documents, almost every image except for thumbnails, etc) are nine or more digits, and at that level it's very easy to lose track of a digit or two, which is misjudging by an order of magnitude or two.
Human readable units helps quite a bit with this, and I think that makes it a sane default. As long as you can specify you want to see bytes, and the sorting is done on the actual byte value, there's little lost because the majority of the time it will help rather than hurt.
Like I've said in these comments, I'm constantly surprised by which settings people change and which ones they don't, so differing opinions on exa's defaults is nothing new. exa shares my opinion of wanting to see thousand separators and byte suffixes by default; ls, on the other hand, has no opinion because with file sizes that small, it didn't really have to choose what the output should be like.
People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly. If you're writing a script, though, you're going to be taking more care than if you were just wanted to list some files. I've lost count of the number of times I've listed a directory, given up trying to count the digits of the file sizes, then re-ran the command with `ls -h`, but I've never written a script without thinking about what the output should be like.
> People have said that in scripts you'd want to just output the file size in bytes, and they're right, otherwise the numbers won't sort correctly.
Actually, many of the utilities that output in human readable format do so in a way that's also sortable through sort's -h option. It might be worth making sure you have a mode that outputs the same way so people can easily utilize sort. That is, K/M/G instead of Ki,Mi, Gi. Unless sort ignores the second alpha character when using -h and it still works, then no problem. :)
Edit: Actually, I just tested, and at least as of the sort in coreutils 8.4, it recognizes both forms, and actually dies with a warning if you mix them, so you're all good!
# echo -e "100Mi\n100Ki\n10Mi\n10Ki" | sort -h
10Ki
100Ki
10Mi
100Mi
# echo -e "100Mi\n100Ki\n10Mi\n10K" | sort -h
sort: both SI and IEC prefixes present on units
Many common files today (any MP3, most word processing documents, almost every image except for thumbnails, etc) are nine or more digits
I think your perception of filesizes is slightly skewed; "nine or more digits" means roughly >=100MB. Disk images, software, and videos would be in that range, but probably not the average MP3 (100MB of 320k MP3 is over 40 minutes), and I don't think I've ever handled a "word processing document" more than a few dozen MB --- and even that would already be many hundreds of pages.
Of the files sitting on my desktop at the moment, which is not necessarily representative nor typical but covers a wide range of types (pdf, mp3, zip, exe, jpg, mp4, ...), slightly more than 10% are 10MB or more (8 digits), ~15% have 7 digits (1-9MB), and the rest are below 1MB (<= 6 digits).
You're right. I was off by an order of magnitude or two. Not that I planned it, but I just illustrated my point with sizes of seven digits or more with myself as the subject.
Seven digits isn't quite as bad, but without thousands separators it's bad enough.
I think you mean 6 or more digits? I have yet to see a multigigabyte document. Even mp3s that size are extremely rare.
Even then, most of my documents are quite a bit smaller, as I have a tendency to write my documents in wordpad instead of office, and then save as rtf or txt.
I meant seven or more, see the sibling comment. Seven digits is a megabyte or more. That encompasses most single song mp3s, some medium to large size documents, etc.
I'm not sure why I said nine, seven is what I was thinking of.
Well all of that is just a matter of how many significant digits to print. You can print "1.873554727 GB". Its ugly as hell. But at least I can mentally truncate everything after the period without having to count the digits.
But then you run into the case that the "32GB" SD image that you just dd'd won't copy to another card of the same nominal size, because it turns out that the destination card has reduced capacity due to 100KB of bad sectors, or something. Or your file went from 2100 bytes to 2081 bytes because your editor dropped all the \r characters. Or a network transfer ended a bit prematurely, chopping off the end of a file.
I'd consider these to be reasonable cases where the byte-exact filesize might be more useful than the readability-friendly version of the number.
On the other hand, yeah, there are a lot of cases where I just need a general idea of the filesize. "-h" display is wonderful for that.