Cosa c'è di sbagliato in questi due lavori cron?

Ho definito i seguenti lavori 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'

Sembra funzionare correttamente se eseguo il comando sopra direttamente dalla riga di comando. Ma quando stamattina ho controllato l'esecuzione della sceneggiatura ho ricevuto un'e-mail in cui si afferma (sto parafrasando perché li ho cancellati accidentalmente) che i segni di spunta posteriori non erano chiusi correttamente.

Consiglio vivamente di inserire qualsiasi cron job non banale nel proprio file di script di shell, per molte ragioni:

• Più facile da eseguire il debug: puoi semplicemente eseguire lo script invece di copiare incollando una lunga riga e con la giusta riga shebang, si comporta in modo molto più prevedibile che se avessi gli stessi comandi direttamente nel crontab
• Più facile da leggere: non è necessario trasformarlo in una sola riga di oltre 200 caratteri, puoi formattarlo bene in modo che sia facile da leggere e capire per tutti
• Aggiungi lo script al controllo versione

Esistono tre cause comuni per cui i comandi cron job si comportano in modo diverso rispetto ai comandi digitati direttamente in una shell interattiva, in ordine approssimativo:

• Cron fornisce un ambiente limitato, ad esempio un minimo $PATHe altre variabili previste mancanti.
• Cron richiama /bin/shper impostazione predefinita, mentre potresti usare in modo interattivo un'altra shell.
• Cron tratta il %personaggio appositamente (viene trasformato in una nuova riga nel comando).
• Cron non fornisce un ambiente terminale o grafico.

Devi precedere tutti i %caratteri con a \in un file crontab, che dice a cron di inserire solo una percentuale nel comando. Ricorda che quando usi il datecomando in un lavoro 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"

Ho anche risolto alcuni problemi di quotazione:

• Questo non ti stava causando problemi diversi dalla leggibilità, ma non dovresti usare i backtick per la sostituzione dei comandi. Usa $(…)invece: le sue regole di analisi sono più semplici.
• Utilizzare sempre virgolette doppie attorno alla sostituzione di variabili e comandi: "$somevariable", "$(somecommand)". Qui la mancanza di citazioni era innocua perché ildate comando non ha mai restituito alcun carattere speciale per i formati che hai usato, ma devi ricordare attentamente quali caratteri sono speciali e controllare questo ogni volta che lasci una sostituzione non quotata. Mantieni la semplicità, usa sempre le virgolette doppie a meno che tu non voglia che si verifichino divisione dei campi e generazione del nome file sul risultato.
• C'erano alcune virgolette singole che impedivano l'espansione attorno ad alcune sostituzioni di comandi. Utilizzare invece virgolette doppie.

Sembra che tu abbia nidificato 'nel muttcomando:

"Eventi da date +%Y-%m-%d --date='last Wednesday'- date +%Y-%m-%d"

Prova a utilizzare al "posto di quello interno in 'modo che l'istruzione reciti

"Eventi da date +%Y-%m-%d --date="last Wednesday"- date +%Y-%m-%d"