Is it possible to set the unit of measurement to a specified value,like KB?

[TYzzt]

When the size of storage is large, the accuracy loses the angle

[TYzzt]

https://github.com/bootandy/dust/pull/322

[bootandy]

I'm not particularly keen on adding this flag. What is the usecase for it?

If you need to know the exact size of a file you can use du for that.

dust is going to ignore several files anyway with its targetted summary so I'm not sure what value this adds.

[TYzzt]

Fast and relatively accurate estimation of storage usage in HPC distributed storage scenarios

[bootandy]

Hmm, maybe, let me sleep on it.

[sergeevabc]

How do I get the size in bytes? When I share files, I prefer to specify the size in bytes so that people don't get confused (KB, KiB, etc). In addition, one can later process the output in bytes by other programs, such as awk, and convert it to the desired units.

[cgkantidis]

Please add a --format option, to specify the output's size format.

I want to parse the output from another script (in Python in my case) to merge it with other reports.
I prefer to call dust in a subprocess, and parse its output, because it's much faster than a native-Python solution.
But I don't want to turn my Python script which merges reports to Rust, because it would be too much work and it's already fast enough.

Any chance to implement that?

dua offers this option:

  -f, --format <FORMAT>
          The format with which to print byte counts

          [default: binary]
          [possible values: metric, binary, bytes, gb, gib, mb, mib]

[bootandy]

Ok, clearly people want this. I'll look into it.

[bootandy]

We could merge the --format flag with the --iso flag. - they seem to do similar things.

[nda-cunh]

I also need this feature. currently i'm forced to use du which is extremely slow and slows down an important script. i wanted to replace it with dust but it forces the -h (human readable). a --format or the inverse of a -h even if it's not precise would be great! thank !

[bootandy]

#373

it's merged it'll be in the next release.

[sergeevabc]

@bootandy, every time I run dust.exe on Windows 7 x64 the first thing that appears on the screen is the following line: “This version of Windows does not support ANSI colors”. Not sure why it happens, since, for example, ripgrep and bat render colors fine. Anyway, I don't want to feel second-rate here.

[bootandy]

I don't have a windows box. - Does dust go on to print with colors or not ?

Does this happen with all versions ?

[sergeevabc]

$ dust.v.0.5.0.exe C:\TEMP
thread 'main' panicked at 'Couldn't enable color support: 87', src\libcore\result.rs:1188:5
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace.

$ dust.v.1.0.0.exe C:\TEMP
This version of Windows does not support ANSI colors
1.2M     ┌── 25ac4429-4010-4cb0-ae65-ff1163082860.tmp                │█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │   1%

1.7M     ├── c3846ae4-d804-49ac-9640-961b052d976a.tmp                │█░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │   2%

2.3M     ├── 8970d8850fb3c3cfc8eb4b517bc2fd39f84670c1.megatools.cache│██░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░ │   2
...