[Linux-bruxelles] y aurait-il un gros bug dans at ?

Gildas Cotomale gildas.cotomale at gmail.com
Ven 15 Jan 11:09:11 CET 2010


> 3) pour pouvoir faire l'essai grandeur nature j'ai mis en pj ce que je peux:
>        3-1: progstation, cad le script dont il est question
>        3-2: whichstation.lst cad la liste des postes sur laquelle retombent
>        l'ensemble des scripts rec/dump/which/prog-station qui font partie
>        du set, rec* enregistre en wav, dump en mp3, prog préprogramme et
>        which* streame live la radio choisie
>        3-3: ajoutez si utile mplayer vu que c'est indispensable
>        3-4: cp les pièces jointes dans /usr/local/bin
et les rendre exécutable =p
> 4) Sortie d'un test (typescript)
>
> That's it! avis aux chevronnés que vous êtes (note progstation c'est pas moi
> qui m'en suis occupé, ça me dépasse totalement!)

et le problème était dans progstation..!
je l'ai lancé, il s'est correctement exécuté, mais pas eu
d'enregistrement... par contre, en rentrant la commande à la main,
tout se passe bien (mais ça on s'en doutait ; tu as bien diagnostiqué
que le problème venait de at). il a donc fallu se concentrer sur les
lignes avec at... et faire des essais (comme mettre les dates à la
main à la place des variables (ce qui ne marchait pas mieux, mais
pouvait permettre de constater l'anomalie que je n'ai pourtant pas vu)
en affichant l'erreur (qui était redirigé vers /dev/null), ça confirme
qu'il y a bien un problème avec les paramètres passés (comme constaté
en les remplaçant par leurs valeurs plus tôt) : at dit ne pas savoir
programmer d'événement à une date passée...
=====code===bash==\
  at `printf "%02i:%02i %02i%02i%02i" $s_hour $s_min $s_month $s_day
9` 2> /dev/null
=====code===bash==/
je suis donc allé relire attentivement le man de at qui dit qu'on lui
indique l'heure sous forme hh:mm (là c'est correct) et que ça
correspond à la prochaine fois que l'horloge affichera cette heure ;
mais on peut choisir/préciser une date (et c'est là que doit se
trouver l'histoire du retour dans le passé) qui est sous la forme
mmjjaa ou mm/jj/aa ou jj.mm.aa ! tu as utilisé la première forme avec
l'année qui vaut 9 ! (et printf le traduit en 09) c'est donc normal
que le script fonctionne en 2009 et plus en 2010 xD
pour que tu n'ai plus cette déconvenue l'année prochaine (sauf si la
programmation est à cheval sur deux années, par exemple la nuit du 31
décembre au 1er janvier...) j'ai mis une variable s_year et e_year qui
sont automatiquement rempli avec l'année courante au début du fichier
;-)
enfin, je ne sais pas si c'est une bonne idée d'envoyer aux oubliettes
les messages d'erreurs, vu que c'est un programme interactif (ça peut
avoir un sens pour des choses qui sont lançable par cron ou un autre
script, mais même là, il faut prévoir de gérer les erreurs --script
plus long et complexe donc-- et d'écrire un fichier de log...) j'ai
donc supprimé la redirection vers /dev/null (en plus sa présence nous
a fait perdre un temps fou pour identifier le problème).
=====code===bash==\
  at `printf "%02i:%02i %02i%02i%02i" $s_hour $s_min $s_month $s_day $s_year`
=====code===bash==/
affaire at classée...

petit hors propos maintenant : une autre modification que j'aurais vu
est de n'avoir qu'un fichier (mais il y a tellement de radio que ça va
faire gros et difficile à lire en cas de modification) ou d'avoir les
données complètement séparées (et pour ne pas compliquer, pourquoi ne
pas avoir nom et url dans un même fichier, que je verrai tabulé par
exemple pour qu'il y ait une ligne par radio)
-------------- section suivante --------------
Une pièce jointe autre que texte a été nettoyée...
Nom: progstation.tar
Type: application/x-tar
Taille: 10240 octets
Desc: non disponible
URL: </pipermail/linux-bruxelles/attachments/20100115/a8b766a6/attachment-0002.tar>


Plus d'informations sur la liste de diffusion Linux-bruxelles