Hot answers tagged

40

On most unices: head -c 1G </dev/urandom >myfile If your head doesn't understand the M suffix: head -c 1073741824 </dev/urandom >myfile If your head doesn't understand the -c option (it's common but not POSIX; you probably have OpenBSD): dd bs=1024 count=1048576 </dev/urandom >myfile Do not use /dev/random on Linux, use /dev/...


33

To generate a random password you can use pwgen: pwgen generates random, meaningless but pronounceable passwords. These passwords contain either only lowercase letters, or upper and lower case mixed, or digits thrown in. Uppercase letters and digits are placed in a way that eases remembering their position when memorizing only the word. ...


29

You can try shuf from GNU coreutils: shuf -i 1-100 -n 1


29

My favorite way to do it is by using /dev/urandom together with tr to delete unwanted characters for instance to get only numbers and letters: head /dev/urandom | tr -dc A-Za-z0-9 | head -c 13


28

if (( RANDOM % 2 )); then C1; else C2; fi


27

Based on the error message that you get, I don't think /dev/urandom is the problem. If it were, I'd expect an error like "no such file or directory". I searched for the error message you got and found this, which seems like it might be relevant to your issue: http://nerdbynature.de/s9y/?176 Basically, specify the locale by prepending the tr command with ...


22

You're observing a combination of the peculiar behavior of dd with the peculiar behavior of Linux's /dev/random. Both, by the way, are rarely the right tool for the job. Linux's /dev/random returns data sparingly. It is based on the assumption that the entropy in the pseudorandom number generator is extinguished at a very fast rate. Since gathering new ...


22

It will eventually. In: cat /dev/random | strings --bytes 1 | tr -d '\n\t ' cat will never buffer, but it's superfluous anyway as there's nothing to concatenate here. < /dev/random strings --bytes 1 | tr -d '\n\t ' strings though, since its output is not longer a terminal will buffer its output by blocks (of something like 4 or 8kB) as opposed to ...


21

In your special case: C$((RANDOM%2+1)) will work :) And hey, it's the shortest answer!


20

It writes until the disk is full (usually there is still some space reserved for the root user). But as the pool of random data is limited, this could take a while. If you need a certain amount of random data, use dd. For 1MB: dd if=/dev/random iflag=fullblock of=$HOME/randomFile bs=1M count=1 Other possibilities are mentioned in answers to a related ...


20

That's exactly the difference between /dev/random and /dev/urandom -- random uses the entropy pool, which gathers noise from a bunch of sources and keeps track of "how much" noise is currently in the pool, so random knows how much high-quality randomness it can generate. Since the entropy pool has a finite amount of noise, reading from random might need to ...


19

Assuming that pseudo-random data is sufficient, dd if=/dev/urandom of=target-file bs=1M count=1000 will do what you want. dd(1) will read blocks of data from an input file and write them to an output file. The command line language is a little quirky, but it is one of those really useful tools worth mastering the basics of. In this case if is input file, ...


18

You can write to /dev/random because it is part of the way to provide extra random bytes to /dev/random, but it is not sufficient, you also have to notify the system that there is additional entropy via an ioctl() call. I needed the same functionality for testing my smartcard setup program, as I did not want to wait for my mouse/keyboard to generate enough ...


14

Linux has two random number generators available to userspace, /dev/random and /dev/urandom. /dev/random is a source of "true" randomness - i.e. it is not generated by a pseudo-random number generator. Entropy is fed into this by the input driver and the interrupt handler, through the functions add_input_randomness and add_interrupt_randomness. Processes ...


14

Summary: dd is a cranky tool which is hard to use correctly. Don't use it, despite the numerous tutorials that tell you so. dd has a “unix street cred” vibe attached to it — but if you truly understand what you're doing, you'll know that you shouldn't be touching it with a 10-foot pole. dd makes a single call to the read system call per block (defined by ...


13

http://www.fourmilab.ch/random/ works for me. sudo apt-get install ent head -c 1M /dev/urandom > /tmp/out ent /tmp/out


13

In the POSIX toolchest, you can use awk: awk -v min=5 -v max=10 'BEGIN{srand(); print int(min+rand()*(max-min+1))}' Do not use that as a source to generate passwords or secret data for instance, as with most awk implementations, the number can easily be guessed based on the time that command was run. With many awk implementations, that command run twice ...


13

Typically, it's designed by kernel developers and documented in man 4 random: Writing to /dev/random or /dev/urandom will update the entropy pool with the data written, but this will not result in a higher entropy count. This means that it will impact the contents read from both files, but it will not make reads from /dev/random faster.


13

Use this: nl file | shuf -n2 | sort -n | cut -f2- nl to number the lines, shuf to shuffle and limit the output to 2 lines (-n), sort to rebuild the original order, and cut to remove the numeration of nl. It will print 2 lines of your file in the original order of the file. Use shuf -n X, where X can be any number.


11

From man 4 random on a RHEL 5 box: When read, the /dev/random device will only return random bytes within the estimated number of bits of noise in the entropy pool. I get files of size 213 bytes on that machine. Back to man 4 random: When read, /dev/urandom device will return as many bytes as are requested. I get 2048 bytes from ...


11

Entropy is not only lost via /dev/{,u}random, the kernel also takes some. For example, new processes have randomized addresses (ASLR) and network packets need random sequence numbers. Even the filesystem module may remove some entropy. See the comments in drivers/char/random.c. Also note that entropy_avail refers to the input pool, not the output pools (...


11

shuf is the command you are looking for. From man shuf, -n, --head-count=COUNT output at most COUNT lines So, for example to get 4 random lines from the file, you could use the command as, shuf -n 4 file You could even use the below approach. head -$((${RANDOM} % `wc -l < file` + 1)) file | tail -1 Where, the final pipe to ...


9

Your tr attempts to interpret its input as text in UTF-8 encoding. So it will complain and abort upon the first byte sequence which is not valid UTF-8. Prefixing tr with LC_ALL=C or LC_CTYPE=C will export that variable into the environment of tr, thus changing its idea of the local character set to the C standard, i.e. everything is just a sequence of opaque ...


9

On a GNU system: find / -type d -print0 | shuf -zn5 | xargs -r0n1 cp foo (now copying the file to things like /sys or /proc would not make sense or even be possible, you may want to add -xdev to only select directories on the file system mounted at /). You could make it compatible with both FreeBSD and GNU with: find / -type d -print0 | sort -zR | tr '\...


8

dd if=/dev/urandom of=/dev/sda, or simply cat /dev/urandom >/dev/sda, isn't the fastest way to fill a disk with random data. Linux's /dev/urandom isn't the fastest cryptographic RNG around. Is there an alternative to /dev/urandom? has some suggestions. In particular, OpenSSL contains a faster cryptographic PRNG: openssl rand $(</proc/partitions awk '$...


8

There is a grain of truth to this, in fact more truth than myth, but nonetheless the statement reflects a fundamental misunderstanding of what's going on. Yes, moving the mouse while generating a key with GPG can be a good idea. Yes, moving the mouse contributes some entropy that makes random numbers random. No, moving the mouse does not make the key more ...


8

You can do this with coreutils' sort with any of the following: sort -R file sort --random-sort file sort --sort=random file from man sort: -R, --random-sort sort by random hash of keys --sort=WORD sort according to WORD: general-numeric -g, human-numeric -h, month -M, numeric -n, random -R, version -V


7

See man bash, PARAMETERS section, Shell Variables subsection: RANDOM Each time this parameter is referenced, a random integer between 0 and 32767 is generated. The sequence of random numbers may be initialized by assigning a value to RANDOM. If RANDOM is unset, it loses its special properties, even if it is subsequently reset. ...


7

Your example data and constraints actually only allow a few solutions—you must play John B. every other song, for example. I'm going to assume your actual full playlist isn't essentially John B, with random other stuff to break it up. This is another random approach. Unlike @frostschutz's solution, it runs quickly. It does not guarantee a result that ...


7

GnuPG consumes several bytes from /dev/random for each random byte it actually uses. You can easily check that with this command: start cmd:> strace -e trace=open,read gpg --armor --gen-random 2 16 2>&1 | tail open("/etc/gcrypt/rngseed", O_RDONLY) = -1 ENOENT (No such file or directory) open("/dev/urandom", O_RDONLY) = 3 read(3, "\\\...



Only top voted, non community-wiki answers of a minimum length are eligible