In bash, `$RANDOM` and `$SECONDS` return a different value each time they are read. What do these shell-maintained variables give you, and what should `$RANDOM` not be used for?

## Variables the shell computes for you Most shell variables are inert storage: you assign, you read back the same thing. A handful are maintained by bash itself and produce a value at the moment you reference them. `RANDOM` and `SECONDS` are the two you meet most often in scripts. ## RANDOM Every expansion of `$RANDOM` yields a fresh pseudo-random integer in the range 0 through 32767 — roughly 15 bits. ```bash echo $((RANDOM % 6 + 1)) # a die roll ``` Assigning to `RANDOM` seeds the generator, which makes a sequence reproducible — useful for a deterministic test, and a clear signal about what kind of generator this is: ```bash RANDOM=42; echo "$RANDOM $RANDOM" RANDOM=42; echo "$RANDOM $RANDOM" # same two numbers again ``` Two consequences follow from the 15-bit range. First, the *birthday problem*: with only 32768 possible values, a loop generating a few hundred names will very likely produce a duplicate. Anything relying on uniqueness — a filename, a job id, a lock name — is unsafe on that basis alone. Second, `$RANDOM % n` is biased whenever `n` does not divide 32768 evenly, because the low residues get one extra chance. For a die roll nobody cares; for anything measured, it matters. The bigger rule is that `RANDOM` is not cryptographically secure. It is a small seeded PRNG whose output is predictable to anyone who can observe or influence the seed. Never derive a password, a token, a session id, a nonce or a secret temporary path from it. Draw from the system entropy source instead — reading from `/dev/urandom` and encoding the bytes, or using a tool built for the purpose — and for temporary files use the dedicated facility that creates the file atomically rather than inventing a name and hoping. Bash 5.1 added `SRANDOM`: each reference gives a 32-bit value obtained from a system entropy source, and it cannot be seeded by assignment. It is a better generator, but it is recent enough that you cannot assume it exists — macOS still ships bash 3.2 by default, and plenty of long-lived images carry bash 4.x. ## SECONDS `SECONDS` reports the number of whole seconds since the shell started. Assigning to it resets the origin, which is what makes it a convenient timer: ```bash SECONDS=0 run_migration echo "migration took ${SECONDS}s" ``` It is whole seconds only — no sub-second resolution — so for anything short or precise you want a real clock reading instead. It is also wall-clock elapsed time, not CPU time, and it keeps counting while a process is blocked or the machine is asleep. For a build step or a deploy phase that is exactly the number you want to log; for benchmarking it is not. A natural pairing is a bounded wait loop, where `SECONDS` gives the deadline without spawning a process per iteration: ```bash SECONDS=0 until service_is_up; do (( SECONDS > 60 )) && { echo "timed out" >&2; exit 1; } sleep 2 done ``` ## The unset trap Both variables share a rule worth remembering: if you `unset` `RANDOM` or `SECONDS`, the name loses its special properties *permanently* for that shell, even if you later assign to it again. It becomes an ordinary variable holding whatever you put in it. The same is true of the other shell-generated variables such as `LINENO`. In practice this bites when a script does a blanket cleanup loop that unsets a list of names, or when someone uses `SECONDS` as an ordinary counter name in one function and wonders why the timer elsewhere stopped moving. Treat these names as reserved and do not reuse them for your own data. ## Related generated variables `LINENO` expands to the line number in the script where it appears, which is why it shows up inside error handlers and trace messages. `$$` is the process id of the shell, and `$_` holds the last argument of the previous command. Like `RANDOM` and `SECONDS`, these are produced by the shell rather than stored, and like them they are names your own code should not shadow.