> Am 16.05.2025 um 15:35 schrieb Jan Stary <h...@stare.cz>: > > On May 16 15:10:48, fischer+o...@lavielle.com wrote: >> The sh(1) manage does not mention the RANDOM variable. > > But it mentions that sh(1) is ksh(1) > > This version of sh is actually ksh in disguise.
Yes, I mentioned that: >sh(1) does mention that it is based on ksh and ksh(1) does mention the RANDOM >variable. > $ ls -li /bin/*sh > > and the ksh(1) manpage documents RANDOM. It does, but by the same logic, why have a sh(1) manpage at all if the contents of ksh(1) would suffice. You could get by with what grep(1), zgrep(1), etc. do and only have one manage for all. > >> OTOH using RANDOM in a crontab(5), which has the SHELL=/bin/sh line, >> does not seem to work. > > How exactly are you using RANDOM in a crontab, * * * * * time $((RANDOM % 60));/home/username/bin/script.sh The (intended) semantics are slightly different from ~ * * * * /home/username/bin/script.sh The latter calculates the random value once when the crontab is loaded, while the former calculates it each time the crontab entry is triggered. And the former achieves a resolution of seconds instead of minutes. > and how exactly does it not work? Given these two crontab lines the second never produces output: * * * * * echo "$(date)">>/home/username/test-trigger-a.log * * * * * time $((RANDOM % 60));echo "$(date)">>/home/username/test-trigger-b.log But you are correct: It is not RANDOM that is the problem, but apparently the $((...)) calculation does not work. E.g. this works: * * * * * echo $RANDOM>>/home/username/test-trigger-c.log This doesn’t: * * * * * echo $((RANDOM % 60))>>/home/username/test-trigger-d.log > Anyway: > > man 5 crontab: > A random value for a field may be obtained using the ‘~’ character. > A value is generated every time the tab is loaded. On its own, > it denotes a random value appropriate for the field. > > So use that instead: it knows the semantics. Like I wrote above, slightly different semantics. Mike
