9 ms·

> For example, exa prints human-readable file sizes by default (when would you not want that?) When I've got two similar but non-identical files, and I think t

> For example, exa prints human-readable file sizes by default (when would you not want that?) When I've got two similar but non-identical files, and I think that the difference between their sizes might be important. That's a silly nitpick, though. It's not like I lose ls by installing exa. Plus, it's a nice excuse to see if I can get cargo working around the corporate firewall.

blunte 9y ago
I agree. Relativity is important - uniform units.
- Houshalter 9y ago
  You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.
  - blunte 9y ago
    Indeed, but you are speaking of relativity on a smaller scale. The problem is, at a glance, seeing 990KB flash by next to 1MB, you will mentally categorize them very differently. I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.
  - beagle3 9y ago
    But unless they are differently colored, if you are looking at a column of 50 numbers, all 100-500 except only two of them have an "M" suffix and the rest have "K", it is very easy to miss. From experience with "du -h" which I rarely use anymore because of this,
  - khedoros1 9y ago
    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.
    - kbenson 9y ago
      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.
      - cytzol 9y ago
        You hit the nail on the head! 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.
  - vacri 9y ago
    > You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. Ah, but does "this tool" (whichever tool) mean GB or GiB when it says "GB"? As the prefixes get larger, the difference between powers-of-ten and powers-of-two prefixes gets significant.
  - userbinator 9y ago
    If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. I disagree; what's easier, spotting the biggest and smallest of these at a glance: 6,677,967 5,916,109 7,164,551 3,745,059,597 3,175 4,194,304 3,550,137 or these: 6.37M 5.64M 6.83M 3.49G 3.10k 4.00M 3.39M If they differ by orders of magnitude, then the difference is visually obvious when the full digits are printed out --- sticking out like the proverbial sore thumb. If they're compressed into units, you have to do some more mental multiplication and comparison.
    - Houshalter 9y ago
      That only works when the files you want to compare are in the same folder and next to each other. If you just want to know how big a given file is, then you have to count the digits. And IIRC ls doesn't even print commas like that to make it human readable. It's just a blob of digits with more precision than is reasonably necessary for the vast majority of uses.
    - foobarian 9y ago
      For this reason when I list in -h mode I pretty much also need to sort by size (ls -lSrh).
lsiebert 9y ago
I'd also consider things like piping to awk or finding the largest files in a set of directories. Human readable sorting is much more complex.
- Recursing 9y ago
  Isn't there `sort -h`?
  - kbenson 9y ago
    It's almost as if people used these tools together enough, that they made an effort to make them work well together. ;) Seriously, "du -h | sort -h" is a regular command for me.
    - bostonvaulter2 9y ago
      If you do it quite a bit you may want to check out ncdu, it is an ncurses directory size viewer. Super handy and fast for what it does.
      - kbenson 9y ago
        curses is actually less useful to me. It's often mixed with a grep and a head or tail with a tee.
ktRolster 9y ago
If it turns out you like it, you can use it as a direct replacement for ls by using alias: alias ls=exa If you put that in your bash profile, it will be permanent (until you remove it from your bash profile, of course).
- jachee 9y ago
  And if you want actual ls, you can just: command ls
  - 19guid 9y ago
    Or even: \ls
ouid 9y ago
also, human readable is sort of a misnomer here. it's not that hard for me to count digits, and that gives a much better sense of scale than having to scan manually for Ms and Gs
pmontra 9y ago
I came here to make exactly this comment but you read the post much sooner than me. At least I learned that ls had a -h option. I don't know why I should use it on files but I routinely do df -h to check the size of file systems. That's a place where it is useful.
ino 9y ago
a thousands separator is a good middle ground
always_good 9y ago
To be fair, you're ignoring the "by default" part. Yes, when you want to see uniform units, you can add a command line argument. HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.
- khedoros1 9y ago
  I'm not ignoring the "by default" part; it's the crux of my complaint. There's a reason that I included that part of the text when I quoted it, after all. I perfectly understand that exa has a "-B" option. > HN is so predictable that I knew someone would complain about this the second I read it And I considered there'd be a pretty good chance that I'd get a reply like this.
  - always_good 9y ago
    """When I've got two similar but non-identical files, and I think that the difference between their sizes might be important.""" Doesn't sound like a default case to me. Seems obvious that you're responding to "when would you not want human-readable file sizes?" which was a question never asked.
    - khedoros1 9y ago
      I think it's obvious that you're bikeshedding minor parts of my comments. As I originally stated, the whole thing is a "silly nitpick" about something that I (quite honestly) only have a weak preference toward. So, yes, I concede that my posts weren't composed with exquisite clarity, and they aren't devoid of opportunity for misunderstanding. You win.
Symbiote 9y ago
I'll repeat this here: export TIME_STYLE=long-iso export BLOCK_SIZE="'1" The first option gives ISO dates, the second the thousands separator. You need a locale for a thousands separator, en_GB here: $ ls -on i* -rw-rw-r-- 1 1001 1,335 2017-06-16 14:31 icon-shelters.svg -rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png -rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix Block size: https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html https://www.gnu.org/software/coreutils/manual/html_node/Bloc... Time style: https://www.gnu.org/software/coreutils/manual/html_node/Formatting-file-timestamps.html https://www.gnu.org/software/coreutils/manual/html_node/Form...
- fnj 9y ago
  Thank you! I couldn't live without the alias I use for ls, which specifies BLOCKSIZE with the tick. Now I am going to add TIME_STYLE, which I didn't know about but I love already. The rendering of time in any format other than ISO-8601 is a pet peeve of mine. It always baffles me why people do it.
- masklinn 9y ago
  Sadly not supported by BSD ls.
  - fnj 9y ago
    True, but if you "pkg install gnuls" and set up an alias, you can get gnu ls transparently.
blahedo 9y ago
My problem is that I like having full and exact file sizes, and I like that they really make order-of-magnitude differences stand out in a listing (by taking up an extra column); but if I look at a number longer than five or so digits it's difficult to quickly see how many digits it is, and hence my quick glance can be off by an order of magnitude. In a program that natively makes strong use of colour, though, here's an option: print exact file sizes, but in two related colours (say, bright yellow and dark yellow/brown), as follows: the first colour for the first 1, 2, or 3 digits, and the other for the remaining $n$ digits where $n$ is divisible by 3. That way the first colour will represent a whole number of KB, MB, GB, etc—and which of these it is will be very clear as it's easier to get that rough-count size—and the fainter/darker colour would give the full exact number of bytes. Best of both worlds!
- fnj 9y ago
  Or just use ls -l --block-size=\'1 (make sure your locale is set properly). This way not only your interactive output is fixed, but also any place where it's redirected to text.

blunte 9y ago

I agree. Relativity is important - uniform units.

Houshalter 9y ago
You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. If they are similar, then it's easy enough to tell that also. E.g. 1 GB vs 995 MB.
- blunte 9y ago
  Indeed, but you are speaking of relativity on a smaller scale. The problem is, at a glance, seeing 990KB flash by next to 1MB, you will mentally categorize them very differently. I would prefer to choose the base unit and see the decimals myself. Then I can quickly ascertain the difference.
- beagle3 9y ago
  But unless they are differently colored, if you are looking at a column of 50 numbers, all 100-500 except only two of them have an "M" suffix and the rest have "K", it is very easy to miss. From experience with "du -h" which I rarely use anymore because of this,
- khedoros1 9y ago
  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.
  - kbenson 9y ago
    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.
    - cytzol 9y ago
      You hit the nail on the head! 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.
- vacri 9y ago
  > You would never say that you are 0.0018 kilometers tall. Using sane unit sizes is important. Ah, but does "this tool" (whichever tool) mean GB or GiB when it says "GB"? As the prefixes get larger, the difference between powers-of-ten and powers-of-two prefixes gets significant.
- userbinator 9y ago
  If two files are orders of magnitude different in size, it's easy to tell that just by the units. As opposing to counting the number of digits, which is tedious and error prone. I disagree; what's easier, spotting the biggest and smallest of these at a glance: 6,677,967 5,916,109 7,164,551 3,745,059,597 3,175 4,194,304 3,550,137 or these: 6.37M 5.64M 6.83M 3.49G 3.10k 4.00M 3.39M If they differ by orders of magnitude, then the difference is visually obvious when the full digits are printed out --- sticking out like the proverbial sore thumb. If they're compressed into units, you have to do some more mental multiplication and comparison.
  - Houshalter 9y ago
    That only works when the files you want to compare are in the same folder and next to each other. If you just want to know how big a given file is, then you have to count the digits. And IIRC ls doesn't even print commas like that to make it human readable. It's just a blob of digits with more precision than is reasonably necessary for the vast majority of uses.
  - foobarian 9y ago
    For this reason when I list in -h mode I pretty much also need to sort by size (ls -lSrh).

lsiebert 9y ago

I'd also consider things like piping to awk or finding the largest files in a set of directories. Human readable sorting is much more complex.

Recursing 9y ago
Isn't there `sort -h`?
- kbenson 9y ago
  It's almost as if people used these tools together enough, that they made an effort to make them work well together. ;) Seriously, "du -h | sort -h" is a regular command for me.
  - bostonvaulter2 9y ago
    If you do it quite a bit you may want to check out ncdu, it is an ncurses directory size viewer. Super handy and fast for what it does.
    - kbenson 9y ago
      curses is actually less useful to me. It's often mixed with a grep and a head or tail with a tee.

ktRolster 9y ago

If it turns out you like it, you can use it as a direct replacement for ls by using alias: alias ls=exa If you put that in your bash profile, it will be permanent (until you remove it from your bash profile, of course).

jachee 9y ago
And if you want actual ls, you can just: command ls
- 19guid 9y ago
  Or even: \ls

ouid 9y ago

also, human readable is sort of a misnomer here. it's not that hard for me to count digits, and that gives a much better sense of scale than having to scan manually for Ms and Gs

pmontra 9y ago

I came here to make exactly this comment but you read the post much sooner than me. At least I learned that ls had a -h option. I don't know why I should use it on files but I routinely do df -h to check the size of file systems. That's a place where it is useful.

ino 9y ago

a thousands separator is a good middle ground

always_good 9y ago

To be fair, you're ignoring the "by default" part. Yes, when you want to see uniform units, you can add a command line argument. HN is so predictable that I knew someone would complain about this the second I read it, including ignoring the "by default" part so that they can by contrary.

khedoros1 9y ago
I'm not ignoring the "by default" part; it's the crux of my complaint. There's a reason that I included that part of the text when I quoted it, after all. I perfectly understand that exa has a "-B" option. > HN is so predictable that I knew someone would complain about this the second I read it And I considered there'd be a pretty good chance that I'd get a reply like this.
- always_good 9y ago
  """When I've got two similar but non-identical files, and I think that the difference between their sizes might be important.""" Doesn't sound like a default case to me. Seems obvious that you're responding to "when would you not want human-readable file sizes?" which was a question never asked.
  - khedoros1 9y ago
    I think it's obvious that you're bikeshedding minor parts of my comments. As I originally stated, the whole thing is a "silly nitpick" about something that I (quite honestly) only have a weak preference toward. So, yes, I concede that my posts weren't composed with exquisite clarity, and they aren't devoid of opportunity for misunderstanding. You win.

Symbiote 9y ago

I'll repeat this here: export TIME_STYLE=long-iso export BLOCK_SIZE="'1" The first option gives ISO dates, the second the thousands separator. You need a locale for a thousands separator, en_GB here: $ ls -on i* -rw-rw-r-- 1 1001 1,335 2017-06-16 14:31 icon-shelters.svg -rw-r--r-- 1 1001 1,633,946 2016-11-07 14:50 insects.png -rw-r--r-- 1 1001 1,445,837 2016-11-18 10:32 ix Block size: https://www.gnu.org/software/coreutils/manual/html_node/Block-size.html https://www.gnu.org/software/coreutils/manual/html_node/Bloc... Time style: https://www.gnu.org/software/coreutils/manual/html_node/Formatting-file-timestamps.html https://www.gnu.org/software/coreutils/manual/html_node/Form...

fnj 9y ago
Thank you! I couldn't live without the alias I use for ls, which specifies BLOCKSIZE with the tick. Now I am going to add TIME_STYLE, which I didn't know about but I love already. The rendering of time in any format other than ISO-8601 is a pet peeve of mine. It always baffles me why people do it.
masklinn 9y ago
Sadly not supported by BSD ls.
- fnj 9y ago
  True, but if you "pkg install gnuls" and set up an alias, you can get gnu ls transparently.

blahedo 9y ago

My problem is that I like having full and exact file sizes, and I like that they really make order-of-magnitude differences stand out in a listing (by taking up an extra column); but if I look at a number longer than five or so digits it's difficult to quickly see how many digits it is, and hence my quick glance can be off by an order of magnitude. In a program that natively makes strong use of colour, though, here's an option: print exact file sizes, but in two related colours (say, bright yellow and dark yellow/brown), as follows: the first colour for the first 1, 2, or 3 digits, and the other for the remaining $n$ digits where $n$ is divisible by 3. That way the first colour will represent a whole number of KB, MB, GB, etc—and which of these it is will be very clear as it's easier to get that rough-count size—and the fainter/darker colour would give the full exact number of bytes. Best of both worlds!

fnj 9y ago
Or just use ls -l --block-size=\'1 (make sure your locale is set properly). This way not only your interactive output is fixed, but also any place where it's redirected to text.