Re: [HS] Re: calcul de temps
Le 01/08/2014 13:29, Sylvain L. Sauvage a écrit :
>> Par exemple :
>>
>> a=1396459867
>> b=1406879835
>> diff=$(( b - a ))
>> days=$(( diff / 86400 ))
>> # etc.
>
> Oui, du peu que l’on en connaisse, la question originale (une
> fois correctement lue) pouvait se traiter en (ba)sh seul :
> calcul et formatage de (j, h, m, s) à partir d’un nombre de
> secondes.
Et même à partir de chaînes en format « date », on
peut le faire avec la commande "date" (version GNU) :
--------------------------------------------
#!/bin/sh
a='2014-04-02 19:31:07 CEST'
b='2014-08-01 09:57:15 CEST'
# In seconds.
a=$(date -d "$a" '+%s')
b=$(date -d "$b" '+%s')
diff=$(( b - a ))
days=$(( diff / 86400 ))
rest=$(( diff - days * 86400 ))
hours=$(( rest / 3600 ))
rest=$(( rest - hours * 3600 ))
minutes=$((rest / 60 ))
seconds=$(( rest - minutes * 60 ))
printf "%s day(s) %s hour(s) %s minute(s) and %s second(s)\n" "$days" "$hours" "$minutes" "$seconds"
--------------------------------------------
Après ça reste assez moche effectivement. En revanche,
l'équivalent en Perl (ou en tout autre langage de
script dans le même genre) sera certainement plus long
au niveau du temps d'exécution (toujours à cause du
chargement de l'interpréteur).
> Le hic, c’est qu’une durée ça n’est pas une date et qu’il n’y
> a pas de fonction de base pour ça. Donc il faut bien soit
> calculer soi-même (ce que moi-meme appelle bidouillage ? ou
> alors parlait-il de bidouiller la sortie de `date` pour enlever
> le jour de trop ?), soit utiliser quelque chose qui sache qu’une
> durée c’est différent d’une date. Et ce quelque chose, c’est une
> bibliothèque, pour Perl, C, ou autre. D’où le fait que moi-meme
> n’a trouvé que des références à Perl, C, Java… et le fait que,
> moi-même (notez l’accent ;o), voyant des manipulations de dates,
> une réticence à utiliser un vrai langage et une proposition
> d’utiliser un interprète bridé, ai couru à la défense de
> l’utilisation d’un vrai interprète…
Je comprends et encore une fois je suis totalement
d'accord.
>>> Le shell, ça va bien un peu mais ça devient vite difficile
>>> à maintenir
>>
>> D'accord avec ça également.
>>
>>> et très gourmand en processus inutiles.
>>
>> Là aussi, j'ajoute un bémol. Parfois le shell peut
>> s'avérer plus rapide qu'un autre interpréteur (comme Perl
>> ou autre) sur des petits programmes assez simples et courts
>> car, dans le temps d'exécution, il faut compter le temps
>> de chargement de l'interpréteur lui-même, […]
>
> Ok mais il y avait le mot-clef « devient ».
Ah oui, désolé. On est d'accord alors et dans ce cas ma
remarque est plus un petit complément qu'un bémol. ;)
> Ma conclusion
> généralisait : le shell, c’est très bien comme glu (traitement
> par lot, tubes, quelques variables, etc.) mais, souvent, le
> problème se complexifie et, en bash, on se met alors à
> compliquer le script : on utilise de plus en plus de petits
> programmes simples (sed, grep, cut…) pour contourner les manques
> du shell alors qu’un seul processus interprète suffirait et
> serait beaucoup plus clair (parfois un simple awk). (Sans parler
> des UUOC ;o)
Oui, tout à fait d'accord. Quand on commence à faire
du sed, grep, cut, tail, awk dans tous les sens, c'est
qu'il est temps de passer à un langage de script un peu
plus évolué avec davantage de structures de données etc.
--
François Lafont
Reply to: