I needed a file for testing that was exactly 1k; no more, no less. Linux is a great platform for doing these kinds of things, so I started off
For the first file I needed, the contents didn't matter, so I turned to /dev/random and dd, like this:
dd if=/dev/random bs=1 count=1024 > file
Worked like a champ. Next I needed to keep making these over and over, so I stuck it in a loop and ran it. Strangely, the loop started running really, really slowly. Turns out that the urandom device requires entropy in order to do it's job, and servers, not having that handy entropy device called a mouse (among others), are really bad about keeping up. When they run out, /dev/random blocks until it builds some up. I need gibberish, not true randomness, so I used /dev/urandom instead, which doesn't block. (Incidentally, if you really do need random, look into rngd to help keep enough entropy..)
Next I needed files that weren't binary; all the data had to be human readable. How will I get urandom to cooperate? I flashed back to an old sckool tool I used long long ago called uuencode, which translates binaries to text for posting to things like web boards, usenet, offline mail, etc.. Uuencode/decode is in a package in most distros called sharutils, so I got it installed and ran my data through:
dd if=/dev/urandom bs=1 count=1024 | uuencode /dev/stdout | grep -v begin | grep -v end
The grep -v's remove header and footer. The problem with this, in case you didn't see it right off the bat, is that uuencode has some overhead; the file is bigger than 1k, since we need more data to define values outside the ascii type set. What to do?
dd if=/dev/urandom bs=1 count=1024 | uuencode /dev/stdout | grep -v begin | grep -v end | dd of=file3 bs=1 count=1024
So why bother with the first dd? The first dd breaks up the data stream coming from urandom.
If you need one meg, try bs=1024 count=1024, and so on..
