Arch Linux

Hmm. Do we get any benefit out of actually using -b, or can we drop that? The only difference seems to be with sparse file handling unless I am interpreting things wrong, and installing things on any recent filesystem will accommodate sparse files anyway so we should be ok.

-b, --bytes
equivalent to ‘--apparent-size --block-size=1'

--apparent-size
print apparent sizes, rather than disk usage; although the apparent size
is usually smaller, it may be larger due to holes in (‘sparse') files,
internal fragmentation, indirect blocks, and the like

There doesn't seem to be any equivalent for that. It does produce a difference on linux, at least it did on the first directory I tried.
As it said, the apparent size is smaller. For example on firefox3-bin package, I get 25632 kB vs 25001 kB.
But well, it is probably not a big deal, we don't need a perfectly accurate result here.
And maybe the space it occupies on the disk is more interesting than just the apparent size anyway..
So I think we can drop it.

-B, --block-size=SIZE
use SIZE-byte blocks

Now, that option doesn't exist either on bsd du. I find it silly that gnu du prints it kilo byte by default,
and both gnu and bsd du have option to display in kilo byte : -k and mega byte : -m, but not byte, which is what we want.
To get size in byte on bsd, you apparently need to do : BLOCKSIZE=1 du
Interestingly, this works on linux as well, but it is not documented in the man page. Can we still use it?

To sum up, I propose to replace du -b by BLOCKSIZE=1 du, which will produce slightly different results but should still be good.

Alternatively we could check which system is running with uname -s and run the appropriate du command for the system.

No, that is not a solution I would ever want to see, that is not clean by any definition.

Xavier's suggestion has been the best so far if it works correctly. We should probably get a proposed patch and some testing for that possible solution.

It doesn't work for me. Running it on FreeBSD 7.0 (setenv BLOCKSIZE 1 && du $file) gives the error "du: minimum blocksize is 512". The same thing occurs on Mac OSX 10.5. It does work on linux, but that's no help.

I looked into using stat, which can produce the exact same result as `du -b` (haven't tested it much), but it appears that, once again, the parameters are different. On linux you can use `stat -c "%s"`, on BSD it's `stat -f "%z"`. I guess the easiest was it so use `ls -l` and extract the size from the output. This seems like the most portable and consistent solution. It also appears to have the same output as `du -b`.

I was thinking about the same yesterday, either using stat, but it seemed totally not portable indeed. or ls, but ugly parsing.
But then I realized both solutions were not practical at all anyway. What we want is the size of a directory, which is exactly what du does :P

So my last idea was to just use size in kilo bytes with du -k
When we look at size, we usually look either in MB or kB anyway..
But these size in bytes are already in every arch package, local database and sync database, so converting is totally not practical.
So maybe we can just do this : du -sk | awk '{print $1 * 1024}'
(btw, awk is amazing, I just added the * 1024 like that without knowing anything and it worked :D)

It would be interesting to compare the results between du -k foo | awk '{print $1 * 1024}' and ls -l foo on freebsd and macos.

Also, du -k and du are equivalent on linux so -k is the default here, which might be a good argument for using it.

I just checked `du -k` and ls -l` on FreeBSD 7.0 and Mac OSX 10.5. What's interesting is that du on FreeBSD shows a higher value than du on Mac OSX. I only checked one file, so I suppose that's nothing to go by, but in general the values are fairly close:

FreeBSD:
$ du -k libfetch-6.2.0.0.tar.bz2 | awk '{print $1 * 1024}'
245760
$ ls -l libfetch-6.2.0.0.tar.bz2 | awk '{print $5}'
223875

Mac OSX:
$ du -k libfetch-6.2.0.0.tar.bz2 | awk '{print $1 * 1024}'
225280
$ ls -l libfetch-6.2.0.0.tar.bz2 | awk '{print $5}
223875

Archlinux:
$ du -k libfetch-6.2.0.0.tar.bz2 | awk '{print $1 * 1024}'
225280
$ ls -l libfetch-6.2.0.0.tar.bz2 | awk '{print $5}
223875

ls still seems to be the most consistent ;). I'll test it more thoroughly, especially on directories, a little later. Seems like a winner though :)

Ah yeah, I finally think the apparent size is more interesting because it is consistent across systems and file systems.

I found another way which I was happy with : echo $(find . -printf "%s + ") 0 |bc
But that printf thing is not standard and not supported on bsd :(
We could probably combine find + stat, but then we are back on the stat problem which has a totally different syntax..

Oh well, that du -k solution looks like the simplest one by far, and the result seems to be good enough.