0

We have a crontab entry that ends up sending an ambiguous redirect error. Pretty sure it's the command to read the date, but don't know how to fix. Are there other solutions?

/bin/sh redirects to /bin/bash

 /opt/startup-shutdown/startup.instances Other > /tmp/`date +%Y%m%d%H%M%S`-cron.log 2>&1

gives:

/bin/sh: 1  
: ambiguous redirect
CGCampbell
  • 208

2 Answers2

1

crontab uses % for a special purpose:

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 file. Percent-signs (%) in the command, unless escaped with backslash (), will be changed into newline characters, and all data after the first % will be sent to the command as standard input.

If you put a date command into the crontab, every % must be quoted with a backslash.

Paul_Pedant
  • 8,679
0

I think that's a carriage return issue.

That's the error Bash gives e.g. if the word to the right of a redirection operator expands to multiple fields E.g. as in echo > * gives bash: *: ambiguous redirect.

Here, it mentions 1 and there's a line break after. I can get a similar error with an input that has 2>&1<CR><LF>, e.g.:

$ printf 'echo foo 2>&1\r\n' |bash
: ambiguous redirect

There, the CR moves the cursor to the start of the line, so whatever comes after writes over the first part. Here with the CR visible:

$ printf 'echo foo 2>&1\r\n' |bash 2>&1|cat -A
bash: line 1: 1^M: ambiguous redirect$

I don't know why in your case the CR would be printed as a regular line break, it's probably a terminal setting.

Check if your file came from Windows and run it through dos2unix or sed -i 's/\r//' or whatever. A search for "carriage return" should bring some hits.

ilkkachu
  • 138,973