Fwd: [Linux-bruxelles] outil le plus adapté: cron ou at?

[Jérôme Warnier]

[..]
> > > Pour des trucs qui se repetent il n'est a priori pas besoin d'un
> > > script pour les lancer... ; il faut les écrire une fois pour de bon...
> > > :-) Ceci dit, "crontab -e" signifie "e"diter ma "crontab"le... et
> > > cette édition se fait avec "vi" ou son clone... Si tu trouves le
> > Correction: se fait avec l'éditeur référencé par la variable
> > d'environnement $EDITOR, ou le programme qui s'appelle "vi" si elle est
> > vide (par défaut, quoi). Cette variable sert à plein d'autres choses,
> > mais souvent, on n'utilise pas ça...
> 
> Tu as raison. Je l'ai presqu'oubié car comme tu dis, on s'en sert
> presque hélas pas... Elle est purtant si pratique (par exemple avec le
> mail) pour utiliser "jed" ou "joe" ou "emacs" voire "ed" [joke] entre
> autres plutôt que l'éditeur par défaut ; d'autant plus que
> l'utilisateur peut redefinir ces variables d'environnement à son
> niveau..
Oui, et c'est utilisé par plein de programmes pour savoir quel éditeur lancer.

> > > fichier ainsi édité [c'est formidiable ce SE où tout est fichier], je
> > > t'autorise à le scripter a coup de "echo ... >>" ;-)
> > Non, si tu fais cela, il n'y a aucune garantie que cron le relira avant
> > sa date d'exécution. Utiliser crontab garantit que ce sera réellement
> > appliqué à cron.
> >
> Comme on a dû le comprendre, je ne sais pas le(s) fichier(s)
> modifié(s). Ma suggestion était dû au fait que je croyais que crontab
> est un script (un peu comme useradd, la vraie commande étant adduser)
> et que l'exécution du cron incombait à "crond"... Mais bon, j'ai pas
> eu encore le temps de regarder ça ; merci donc pour l'info.
Le problème est simple: cron est un daemon (il tourne tout le temps). Si
tu édites son fichier, rien ne garantit qu'il sera mis au courant de
cela à temps pour exécuter ton cronjob. Tandis que si tu utilises
crontab, ce dernier le tiendra au courant au moment où tu sauves.