Co jest nie tak z tymi dwoma zadaniami crona?

Mam zdefiniowane następujące zadania cron.

55  8   *   *   3   /usr/bin/php /home/mark/dev/processes/customClient/events.php > /home/mark/dev/processes/customClient/events-`date +%Y-%m-%d --date='last Wednesday'`-`date +%Y-%m-%d`.csv
0   9   *   *   3   /usr/bin/echo 'The csv for last week, trying my hand at automatiging this' | /usr/bin/mutt <emailaddress> -s 'Events from `date +%Y-%m-%d --date='last Wednesday'`-`date +%Y-%m-%d`' -a '/home/mark/dev/processes/customClient/events-`date +%Y-%m-%d --date='last Wednesday'`-`date +%Y-%m-%d`.csv'

Wygląda na to, że działa poprawnie, jeśli uruchomię powyższe polecenie bezpośrednio z wiersza poleceń. Ale kiedy rano rano sprawdziłem działanie skryptu, dostałem e-mail z informacją (parafrazuję, bo przypadkowo je usunąłem), że tylne tiki nie zostały poprawnie zamknięte.

Zdecydowanie zalecam umieszczanie wszelkich nietrywialnych zadań cron we własnym pliku skryptu powłoki z wielu powodów:

• Łatwiejsze do debugowania: możesz po prostu uruchomić skrypt zamiast kopiować wklejając długą linię, a przy odpowiedniej linii shebang zachowuje się znacznie bardziej przewidywalnie niż gdybyś miał te same polecenia bezpośrednio w crontab
• Łatwiejszy do odczytania: nie trzeba tworzyć z niego ponad 200 znaków, można go ładnie sformatować, aby każdy mógł go łatwo odczytać i zrozumieć
• Dodaj skrypt do kontroli wersji

Istnieją trzy typowe przyczyny, dla których polecenia zadania cron zachowują się inaczej niż polecenia wpisane bezpośrednio w interaktywnej powłoce, w przybliżonej kolejności:

• Cron zapewnia ograniczone środowisko, np. Minimalne $PATHi brak innych oczekiwanych zmiennych.
• Cron wywołuje /bin/shdomyślnie, podczas gdy możesz używać innej powłoki interaktywnie.
• Cron traktuje %znak specjalnie (w poleceniu zamienia się go w nowy wiersz).
• Cron nie zapewnia środowiska terminalowego ani graficznego.

Musisz poprzedzić wszystkie %znaki znakiem \w pliku crontab, który mówi cronowi, aby po prostu wstawił procent w poleceniu. Pamiętaj, że kiedy używasz datepolecenia w zadaniu cron.

55  8   *   *   3   /usr/bin/php /home/mark/dev/processes/customClient/events.php > "/home/mark/dev/processes/customClient/events-$(date +\%Y-\%m-\%d --date='last Wednesday')-$(date +\%Y-\%m-\%d).csv"
0   9   *   *   3   /usr/bin/echo 'The csv for last week, trying my hand at automatiging this' | /usr/bin/mutt <emailaddress> -s "Events from $(date +\%Y-\%m-\%d --date='last Wednesday')-$(date +\%Y-\%m-\%d)" -a "/home/mark/dev/processes/customClient/events-$(date +\%Y-\%m-\%d --date='last Wednesday')-$(date +\%Y-\%m-\%d).csv"

Naprawiłem również problemy z cytowaniem:

• Nie powodowało to innych problemów niż czytelność, ale nie należy używać strzałek wstecznych do zastępowania poleceń. Użyj $(…)zamiast tego: jego zasady analizy są prostsze.
• Zawsze używaj podwójnych cudzysłowów wokół podstawień zmiennych i poleceń: "$somevariable", "$(somecommand)". Tutaj brak cudzysłowów był nieszkodliwy, ponieważ datepolecenie nigdy nie zwróciło żadnego znaku specjalnego dla używanych formatów, ale musisz uważnie zapamiętać, które znaki są specjalne i sprawdzać to za każdym razem, gdy pozostawiasz zamianę bez cudzysłowu. Upraszczaj, zawsze używaj podwójnych cudzysłowów, chyba że chcesz, aby wynik był dzielony na pola i generowanie nazw plików.
• Masz kilka pojedynczych cudzysłowów, które uniemożliwiają rozwinięcie niektórych podstawień poleceń. Zamiast tego użyj podwójnych cudzysłowów.

Wygląda na to, że zagnieżdżono się 'w muttpoleceniu:

„Wydarzenia z date +%Y-%m-%d --date='last Wednesday'- date +%Y-%m-%d”

Spróbuj użyć "zamiast wewnętrznego ', aby oświadczenie brzmiało

„Wydarzenia z date +%Y-%m-%d --date="last Wednesday"- date +%Y-%m-%d”