Shell Programming and Scripting

Yes, wc -c is the best answer. It gives the exact correct answer.

As you suggest, do not worry about "overhead" at this point. As you can see from my previous post with the time test, wc runs very fast on large files. If there were really an "overhead" problem, if your script takes too long, you could worry about it then.

By the way if you want just the file size and forget about piping the output to another process:

Code:

wc -c < file

No, "wc -c" causes too much I/O load, because it must read the whole file!
Better stick to the "ls -l"; you can set a consistent locale:

Code:

LC_ALL=C ls -l

most OS take the -o option

Code:

LC_ALL=C ls -lo

how can you measure the I/O load consumption of a process?

Have a 10GB file on an NFS share, and run "wc -c" on it on a hundred NFS clients simultaneously.
This will take very long, and your NFS server will be overloaded the whole time.
And your server admin will be angry. (The redness of his face is proportional to the overhead that you have caused.)

There is I/O load and time load.

I/O load is normally the file size, unless the file is already cached into RAM.

Time load is measured with time command, using an uncached copy, such as:

Code:

$ time wc -c 2011.bb
4234978 2011.bb

real    0m0.009s
user    0m0.000s
sys     0m0.004s

Unless you are dealing with large files, much bigger than the test file above, or you run into a problem, I would not worry about such "overhead" concerns. It's called "premature optimization" to "fix" something by making it complicated, before there is a known problem. On the other hand, if your script is too slow, then time to try something that does not read the actual data on the disk.

Sorry but I totally disagree with you, Hanson44. Using wc -c to retrieve the size of a file is absolutely the wrong approach to take.

A better approach is to use some very simple shell script logic to parse the the output of ls -l in order to figure out the file size column.