2

I have picked up a habit of including . from some blog post:

0 0 * * * . /usr/local/bin/somescript.sh

...instead of:

0 0 * * * /usr/local/bin/somescript.sh

For instance a visual cron schedule expression editor cron.guru considers using the character as an error, but my scripts appear to have ran as specified at least until now.

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
user598527
  • 437
  • 2
  • 17
  • 1
    Be aware that `crond` runs the command with a fairly arbitrary shell: nominally /bin/sh, which may be a link to another shell (like ksh), and may also be overridden by a SHELL directive in the crontab. Sourcing your command script means its own shebang gets ignored, and the default shell may not like the syntax. – Paul_Pedant Apr 12 '22 at 20:44
  • And, your "`.`" will malfunction if your `source`d file is not a `/bin/sh` compatible script. If it's an ELF binary or an incompatible script, BOOM! – waltinator Apr 13 '22 at 13:17
  • I've moved the scripts to `/usr/local/bin`, they appear in `$PATH` now. The question had a bad location. – user598527 Apr 14 '22 at 20:30

1 Answers1

11

cron passes the entire command, including a dot if present, to a shell for execution; so . is the corresponding shell command, which “sources” the script in the current shell instead of launching a new process to run it. For an .sh file, that would probably be a new shell.

See What is the difference between sourcing ('.' or 'source') and executing a file in bash? for details.

cron.guru only validates schedule expressions, i.e. the part of the crontab entry which defines when it should run; that’s why “0 8 * * Mon .” is marked invalid — that’s not a valid schedule expression.

ilkkachu
  • 133,243
  • 15
  • 236
  • 397
Stephen Kitt
  • 411,918
  • 54
  • 1,065
  • 1,164
  • @ilkkachu thanks for the edit. I didn’t think it worth distinguishing, since anything that works when sourced involves a shell ;-). – Stephen Kitt Apr 13 '22 at 10:01
  • @StephenKitt, yeah of course :D But the opposite of going from `whatever` to `. whatever` might not work. I wasn't sure if to edit or comment or how to phrase it though... – ilkkachu Apr 13 '22 at 10:12
  • 1
    @ilkkachu right, converting from one to the other could be useful information to add, especially since the linked Q&A doesn’t address it directly. Even going from `. whatever` to `whatever` might not work since `. /path/to/whatever` only requires `whatever` to be readable, not executable. – Stephen Kitt Apr 13 '22 at 11:02