I want to log my public ip to a file using cron. Something like this:


Here's what I've cobbled together:

* * * * * { date +%FT%T | tr "\n" " "; curl https://ipinfo.io/ip -s ; echo "" ; } >> /home/mario/logs/pubip.log

It works* in at sh prompt but once I put the asterisks in front and put it into crontab -e I get the following error:

/bin/sh: 1: Syntax error: end of file unexpected (expecting "}")

OS: Ubuntu 20.04.2 LTS

*There's gotta be a more elegant way to handle the formatting. What I frankensteind feels pretty awkward.

  • After some more experimenting, removing the "+" argument in the date command gets rid of the error.Cron doesn't like it for some reason. Any ideas why? The same command with the "+" argument works fine from a sh prompt and in a cronjob via bash script
    – nuifd
    May 27, 2021 at 11:48
  • Or just use a simpler API.. api.ipify.org - curl https://api.ipify.org
    – Fanatique
    May 27, 2021 at 14:12

3 Answers 3


I couldn't reproduce your. If the command for cron is too bulky, more elegant way is to wrap it inside a separate cron script and call that from crontab:

$ cat ~/crontab.ip 
{ date +%FT%T | tr "\n" " "; curl https://ipinfo.io/ip -s ; echo "" ; } >> ~/log.ip

and my crontab is:

$ crontab -l
* * * * * ~/crontab.ip

It should work.

  • Thanks. The script does appear to work fine. Probably similar to the reason why the command works from a shell prompt. I'll likely be doing this since the command is so bulky. For educations sake, did you try the non-script way and not get the error I got? I'd still like to know why that's not working. After some testing it appears to be because of the + symbol in the date command. Why would that not work as a cron job?
    – nuifd
    May 27, 2021 at 11:47

So it turned out to be the '%' symbols. Should have read the docs more: crontab(5)

The "sixth" field (the rest of the line) specifies the command to
       be run.  The entire command portion of the line, up to a newline
       or a "%" character, will be executed by /bin/sh or by the shell
       specified in the SHELL variable of the cronfile.  A "%" character
       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.

Correct cron line that worked in the end is

* * * * * { date +\%FT\%T | tr "\n" " "; curl https://ipinfo.io/ip -s ; echo "" ; } >> /home/mario/logs/pubip.log

That said, I'll be moving this into a script just for readability's sake as @scimerman suggested.

  • date +"\%FT\%T $(curl https://ipinfo.io/ip -s)"
    – roaima
    May 27, 2021 at 17:03

When putting commands in the cron system, you must use the full path for the command.

date should be /bin/date
tr should be /usr/bin/tr
curl should be /usr/bin/curl.
echo should be /usr/bin/echo

  • 2
    Couldn't find any reference to this requirement. In fact, crontab(5) lists examples without full paths.
    – nuifd
    May 27, 2021 at 12:42
  • It's not a requirement - but its a strong recommendation to do so. May 27, 2021 at 13:17
  • 1
    In fact, I recommend against this. In a highly stable system that does not get regular updates - sure, it improves security a tiny bit. But in a system that is getting updates regularly, this is NOT ok. Reason #1 is that on some distributions updates sometimes change the location of a binary. This is a breaking change when you're using full paths. Also note that on one of the most stable distros - Debian - this IS an issue. Reason #2 is that this is barely a security issue for when you're using root to execute crons. root's PATH variable is hardly accessible.
    – Fanatique
    May 27, 2021 at 14:17
  • Also, for echo it is generally recommended nowadays that you use the shell function, rather than the binary. In the old days it was recommended so that you use a more "portable" version. But different distributions have it in different locations nowadays - totally not "portable", and also the shell function pretty much has all the options you need on all shells.
    – Fanatique
    May 27, 2021 at 14:21
  • @Fanatique, what does it have to do with security? Its ridiculous to say that not using the full path is LESS secure somehow. What if the path to echo was changed in the environment path to rootkit? Answer that. You are posting REALLY BAD information.
    – Shōgun8
    May 28, 2021 at 1:32

Not the answer you're looking for? Browse other questions tagged or ask your own question.