Mon collègue a couru grep | crontab. Après cela, tous les emplois ont disparu. On dirait qu'il essayait de courir crontab -l.
Que s'est-il donc passé après avoir exécuté la commande grep | crontab? Quelqu'un peut-il expliquer?
Mon collègue a couru grep | crontab. Après cela, tous les emplois ont disparu. On dirait qu'il essayait de courir crontab -l.
Que s'est-il donc passé après avoir exécuté la commande grep | crontab? Quelqu'un peut-il expliquer?
Réponses:
crontabpeut installer une nouvelle lecture crontabpour l'utilisateur invoquant (ou l'utilisateur mentionné en tant que root) à partir de STDIN. C'est ce qui s'est passé dans votre cas.
grepsans aucune option générera un message d'erreur sur STDERR comme d'habitude et vous grepdirigez le STDOUT de vers STDIN crontabdont le champ est vide, ce qui vous crontabfera disparaître.
Comment a-t-il mis fin à l'emploi? At-il tapé Cc ou Cd? S'il a tapé Cd, cela revient à courir crontab < /dev/nullet vous avez remplacé le fichier crontab de l'utilisateur par un fichier vide. D'un autre côté, si vous tuez crontabavec Cc, alors le crontab peut avoir été conservé, mais vous pouvez facilement le vérifier en exécutant crontab -l.
Tout ce que ce programme fait est d'éditer les fichiers crontab dans /var/spool/cron/, donc si vous avez une sauvegarde du système de fichiers, vous pouvez simplement restaurer le fichier crontab de l'utilisateur à partir de là.
Je n'ai pas vu qu'il n'y avait pas d'argument à la grep, donc grep sera une erreur et en effet le fichier crontab sera toujours emporté.
crontabvous obligent à utiliser-comme nom de fichier pour lire à partir de l'entrée standard. Je suppose que c'est parce que trop de gens ont fait sauter leurs crontabs avec des erreurs comme ça.