On Fri, May 16, 2025 at 9:26 AM Mike Fischer <fischer+o...@lavielle.com> wrote:
> > 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.
The reason is that it makes it clear what behavior is actually
standardized for sh and thus (more) portable, vs what are extensions
that may or may not operate with other shells.
> >> OTOH using RANDOM in a crontab(5), which has the SHELL=/bin/sh line,
> >> does not seem to work.
...
> > 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
It's not the $((...)) syntax, nor the use of RANDOM inside such.
Let's check the crontab(5) manpage:
The command field (the rest of the line) is the command to be run. The
entire command portion of the line, up to a newline or % character, will
be executed by /bin/sh or by the shell specified in the SHELL variable of
the crontab. Percent signs (‘%’) in the command, unless escaped with a
backslash (‘\’), will be changed into newline characters, and all data
after the first ‘%’ will be sent to the command as standard input.
So, it's the % which is throwing this off. The syntax error from the
shell that cron invoked should have been mailed to you, unless you
disabled or redirected that with the MAILTO setting.
I'll gently suggest that you'll get answers faster if you include the
actual failing operation from the get go, but at least it was an
interesting thread in some ways.
Philip Guenther
