calcul de temps

Philippe Delavalade

01/08/2014 à 08:00

moi-meme jeudi 31 juillet à 22:09

encore un question tordue, je m'en excuse.

Pas trouvé de réponse sauf en PERL ou en C ou java mais je suis dans du
bash.

j'ai 2 dates epoch par exemple : 1406779635 et 1406484823

Jeopeux avoir leur valeur vraie par
moi$ date -d @1406779635
jeudi 31 juillet 2014, 06:07:15 (UTC+0200)
et
moi$ date -d @1406484823
dimanche 27 juillet 2014, 20:13:43 (UTC+0200)

mais la différence de temps je ne vois pas comment la sortir
la différence est de : 294812
moi$ date +"%d jours %H heures %M minutes %S secondes" -d @294812
04 jours 10 heures 53 minutes 32 secondes

Ya un jour de trop. C'est normal la différence est toujours une date et
le calendrier ne démarre pas au 0 Janvier :-)

Question con : est -il possible de calculer le temps entre 2 epoch sans
bidouille ?

(calcul du nombre de jours, enlever nb jours*(60*60/24) pour trouver le
nombre d'heures, etc)

Merci pour toute proposition.

Le paquet concalc devrait pouvoir t'aider.

--
Ph. Delavalade

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Sylvain L. Sauvage

01/08/2014 à 08:40

Le vendredi 1 aoÃ»t 2014, 07:56:39 Philippe Delavalade a Ã©crit :

moi-meme jeudi 31 juillet Ã 22:09
[â¦ calcul de durÃ©e en shell â¦]

Le paquet concalc devrait pouvoir t'aider.

En mÃªme temps, lancer date, concalc, ou Perl (ou autre langage
de script), câest toujours lancer un processus de plus dans le
(ba)sh. Donc mon avis, câest dâutiliser :
â le programme que lâon comprend le mieux ;
(ou qui est le plus testÃ© ou facilement comprÃ©hensible par
dâautres ou facilement (re)trouvable)
â et qui est disponible partout.

Avoir
perl -e 'mini script'
ou
perl <<EOF
script plus long
EOF
ou encore
/usr/local/bin/script.pl <arguments>
dans un script (ba)sh me semble plus propre, plus Ã©conomique et
plus portable quâune sÃ©rie de manipulations bashiennes foi reuses
non portables ou dâappels Ã 36 commandes (donc processus)
prÃ©tendues simples.

Le shell, Ã§a va bien un peu mais Ã§a devient vite difficile Ã
maintenir et trÃ¨s gourmand en processus inutiles. Il faut savoir
utiliser les bons outils.

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

moi-meme

01/08/2014 à 09:50

Le Fri, 01 Aug 2014 08:40:02 +0200, Sylvain L. Sauvage a écrit :

ou encore
/usr/local/bin/script.pl <arguments>
dans un script (ba)sh me semble plus propre, plus économique et plus
portable qu’une série de manipulations bashiennes foireuses non
portables ou d’appels à 36 commandes (donc processus) prétendues
simples.

pas de problème de ressource : c'est appelé quand j'en ai besoin (2 fois/
semaine)

Le shell, ça va bien un peu mais ça devient vite difficile à
maintenir et très gourmand en processus inutiles. Il faut savoir
utiliser les bons outils.

c'est ce que je recherche

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/53db41af$0$2368$

moi-meme

01/08/2014 à 10:00

Le Fri, 01 Aug 2014 08:00:03 +0200, Philippe Delavalade a écrit :

Le paquet concalc devrait pouvoir t'aider.

c'est un bc amélioré : on peut entrer un calcul dans la ligne de commande.

çà aide dans le script

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/53db425d$0$2368$

Jean-Jacques Doti

01/08/2014 à 10:30

Salut,

Le 31/07/2014 22:09, moi-meme a écrit :

encore un question tordue, je m'en excuse.

Pas trouvé de réponse sauf en PERL ou en C ou java mais je suis dans du
bash.

j'ai 2 dates epoch par exemple : 1406779635 et 1406484823

Jeopeux avoir leur valeur vraie par
moi$ date -d @1406779635
jeudi 31 juillet 2014, 06:07:15 (UTC+0200)
et
moi$ date -d @1406484823
dimanche 27 juillet 2014, 20:13:43 (UTC+0200)

mais la différence de temps je ne vois pas comment la sortir
la différence est de : 294812
moi$ date +"%d jours %H heures %M minutes %S secondes" -d @294812
04 jours 10 heures 53 minutes 32 secondes

Ya un jour de trop. C'est normal la différence est toujours une date et
le calendrier ne démarre pas au 0 Janvier :-)

Il y a aussi une heure de trop en raison du décalage entre l'heure
française et l'heure UTC puisque date, sans l'option -u, te donne
l'heure locale…

Question con : est -il possible de calculer le temps entre 2 epoch sans
bidouille ?

C'est quoi une bidouille ?

(calcul du nombre de jours, enlever nb jours*(60*60/24) pour trouver le
nombre d'heures, etc)

Ça c'est pas une bidouille mais un calcul…

Merci pour toute proposition.
C Hiebel

Et bien, si tu veux tout faire en bash, il suffit de le calculer. Voici
donc une proposition de calcul (ou de bidouille, si tu préfères ;-) ) :
s)4812
echo "$(($s/60/60/24)) jours $(($s/60/60%24)) heures $(($s/60%60))
minutes $(($s%60)) secondes"
→ 3 jours 9 heures 53 minutes 32 secondes

Et ça devrait marcher même si tu dépasses les 31 jours (mais il faut
peut-être adapter pour afficher correctement les durées de moins d'un
jour ou de moins d'une heure).

A+
Jean-Jacques

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Salut,

Le 31/07/2014 22:09, moi-meme a écrit :

encore un question tordue, je m'en excuse.

Pas trouvé de réponse sauf en PERL ou en C ou java mais je suis dans du
bash.

j'ai 2 dates epoch par exemple : 1406779635 et 1406484823

Jeopeux avoir leur valeur vraie par
moi$ date -d @1406779635
jeudi 31 juillet 2014, 06:07:15 (UTC+0200)
et
moi$ date -d @1406484823
dimanche 27 juillet 2014, 20:13:43 (UTC+0200)

mais la différence de temps je ne vois pas comment la sortir
la différence est de : 294812
moi$ date +"%d jours %H heures %M minutes %S secondes" -d @294812
04 jours 10 heures 53 minutes 32 secondes

Ya un jour de trop. C'est normal la différence est toujours une date et
le calendrier ne démarre pas au 0 Janvier :-)

Il y a aussi une heure de trop en raison du décalage entre l'heure
française et l'heure UTC puisque date, sans l'option -u, te donne
l'heure locale…

Question con : est -il possible de calculer le temps entre 2 epoch sans
bidouille ?

C'est quoi une bidouille ?

(calcul du nombre de jours, enlever nb jours*(60*60/24) pour trouver le
nombre d'heures, etc)

Ça c'est pas une bidouille mais un calcul…

Merci pour toute proposition.
C Hiebel

Et bien, si tu veux tout faire en bash, il suffit de le calculer. Voici
donc une proposition de calcul (ou de bidouille, si tu préfères ;-) ) :
s)4812
echo "$(($s/60/60/24)) jours $(($s/60/60%24)) heures $(($s/60%60))
minutes $(($s%60)) secondes"
→ 3 jours 9 heures 53 minutes 32 secondes

Et ça devrait marcher même si tu dépasses les 31 jours (mais il faut
peut-être adapter pour afficher correctement les durées de moins d'un
jour ou de moins d'une heure).

A+
Jean-Jacques

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/53DB4F46.5000305@doti.fr

S

01/08/2014 à 10:50

Bonjour,

Le vendredi 01 août 2014 à 7:28, moi-meme a écrit :

Le Fri, 01 Aug 2014 08:40:02 +0200, Sylvain L. Sauvage a écrit :

> ou encore
> /usr/local/bin/script.pl <arguments>
> dans un script (ba)sh me semble plus propre, plus économique et plus
> portable qu’une série de manipulations bashiennes foireuses non
> portables ou d’appels à 36 commandes (donc processus) prétendues
> simples.
pas de problème de ressource : c'est appelé quand j'en ai besoin (2 fois/
semaine)

>
> Le shell, ça va bien un peu mais ça devient vite difficile à
> maintenir et très gourmand en processus inutiles. Il faut savoir
> utiliser les bons outils.
c'est ce que je recherche

J'y intégrerais un bout de Perl moi aussi.

Le module Date::Calc (paquet libdate-calc-perl) est bien pratique pour ce genre
de calculs.

Seb

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Yves Rutschle

01/08/2014 à 11:40

On Fri, Aug 01, 2014 at 07:28:47AM +0000, moi-meme wrote:

> Le shell, ça va bien un peu mais ça devient vite difficile à
> maintenir et très gourmand en processus inutiles. Il faut savoir
> utiliser les bons outils.
c'est ce que je recherche

Je seconde Sylvain: la gestion de date, c'est toujours plus
compliqué que l'on ne croit, et extrèmement difficile à
tester correctement. Un jour, j'écrivis un script bash en
février, qui travaillait sur des dates. Tout se passa bien.
Des mois plus tard, tout se mit à foirer lamentablement. Hé
oui, en octobre, le numéro du mois passe à 2 chiffres, et
mes bidouilles ne le supportaient pas.

Moi, je te conseillerais Time::Duration de Perl, que j'avais
utilisé dans ce petit script pour calculer le nombre de
jours entre 2 dates:

#! /usr/bin/perl -w
# Usage: diffdate 30JUL2005 01AUG2014
# -> 9 years and 4 days

use strict;
use Time::ParseDate;
use Time::Duration;

my $i1 = shift;
my $i2 = shift;

# Turn my date format (02SEP) to ParseDate (02 SEP)
$i1 =~ s/(d+)([a-z]+)(d*)$/$1 $2 $3/i;
$i2 =~ s/(d+)([a-z]+)(d*)$/$1 $2 $3/i;

my $t1 = parsedate($i1, UK => 1, PREFER_FUTURE => 0);
my $t2 = parsedate($i2, UK => 1, PREFER_FUTURE => 0);

my $d = duration($t2 - $t1);

print "$dn";

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Francois Lafont

01/08/2014 à 12:10

Le 01/08/2014 08:34, Sylvain L. Sauvage a écrit :

En même temps, lancer date, concalc, ou Perl (ou autre langage
de script), c’est toujours lancer un processus de plus dans le
(ba)sh. Donc mon avis, c’est d’utiliser :
— le programme que l’on comprend le mieux ;
(ou qui est le plus testé ou facilement compréhensible par
d’autres ou facilement (re)trouvable)
— et qui est disponible partout.

Avoir
perl -e 'mini script'
ou
perl <<EOF
script plus long
EOF
ou encore
/usr/local/bin/script.pl <arguments>
dans un script (ba)sh me semble plus propre, plus économique et
plus portable qu’une série de manipulations bashiennes foireuses
non portables ou d’appels à 36 commandes (donc processus)
prétendues simples.

Je suis globalement d'accord à tout ça. Je voulais
juste faire remarquer qu'on peut tout de même faire
un peu d'arithmétique (additions, multiplications,
divisions etc.) en shell et cela de manière relativement
portable (en restant dans du shell POSIX en tout cas).

Par exemple :

a96459867
b06879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.

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, et sur ce point
en général le shell est assez loin devant, en particulier
le shell /bin/sh sous Wheezy par exemple qui est différent
du bash, alors qu'à l'inverse le temps de chargement de
l'interpréteur Perl (*et* des éventuels modules nécessaires)
est nettement plus long et peut représenter une part non
négligeable dans le temps global de l'exécution du script.

Dans le cas présent, si on se limite *juste* au problème du
PO (ie étant données 2 dates, on calcule la différence en
jours, heures, minutes et secondes), je suis sûr que ça ira
plus vite en shell qu'en Perl (par contre, effectivement, au
niveau lisibilité du code etc. y'aura pas photo).

Voilà, c'est juste un petit bémol car sinon je suis d'accord
qu'il est toujours préférable d'utiliser un langage de script
adapté et qu'il faut privilégier la lisibilité du code plutôt
que les perfs (dont perso je n'ai rien à faire dans 99,9% de
mes scripts).

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/lrfosi$p19$

Le 01/08/2014 08:34, Sylvain L. Sauvage a écrit :

En même temps, lancer date, concalc, ou Perl (ou autre langage
de script), c’est toujours lancer un processus de plus dans le
(ba)sh. Donc mon avis, c’est d’utiliser :
— le programme que l’on comprend le mieux ;
(ou qui est le plus testé ou facilement compréhensible par
d’autres ou facilement (re)trouvable)
— et qui est disponible partout.

Avoir
perl -e 'mini script'
ou
perl <<EOF
script plus long
EOF
ou encore
/usr/local/bin/script.pl <arguments>
dans un script (ba)sh me semble plus propre, plus économique et
plus portable qu’une série de manipulations bashiennes foireuses
non portables ou d’appels à 36 commandes (donc processus)
prétendues simples.

Je suis globalement d'accord à tout ça. Je voulais
juste faire remarquer qu'on peut tout de même faire
un peu d'arithmétique (additions, multiplications,
divisions etc.) en shell et cela de manière relativement
portable (en restant dans du shell POSIX en tout cas).

Par exemple :

a96459867
b06879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.

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, et sur ce point
en général le shell est assez loin devant, en particulier
le shell /bin/sh sous Wheezy par exemple qui est différent
du bash, alors qu'à l'inverse le temps de chargement de
l'interpréteur Perl (*et* des éventuels modules nécessaires)
est nettement plus long et peut représenter une part non
négligeable dans le temps global de l'exécution du script.

Dans le cas présent, si on se limite *juste* au problème du
PO (ie étant données 2 dates, on calcule la différence en
jours, heures, minutes et secondes), je suis sûr que ça ira
plus vite en shell qu'en Perl (par contre, effectivement, au
niveau lisibilité du code etc. y'aura pas photo).

Voilà, c'est juste un petit bémol car sinon je suis d'accord
qu'il est toujours préférable d'utiliser un langage de script
adapté et qu'il faut privilégier la lisibilité du code plutôt
que les perfs (dont perso je n'ai rien à faire dans 99,9% de
mes scripts).

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/lrfosi$p19$1@ger.gmane.org

Vous avez filtré cet utilisateur ! Consultez son message

Le 01/08/2014 08:34, Sylvain L. Sauvage a écrit :

En même temps, lancer date, concalc, ou Perl (ou autre langage
de script), c’est toujours lancer un processus de plus dans le
(ba)sh. Donc mon avis, c’est d’utiliser :
— le programme que l’on comprend le mieux ;
(ou qui est le plus testé ou facilement compréhensible par
d’autres ou facilement (re)trouvable)
— et qui est disponible partout.

Avoir
perl -e 'mini script'
ou
perl <<EOF
script plus long
EOF
ou encore
/usr/local/bin/script.pl <arguments>
dans un script (ba)sh me semble plus propre, plus économique et
plus portable qu’une série de manipulations bashiennes foireuses
non portables ou d’appels à 36 commandes (donc processus)
prétendues simples.

Je suis globalement d'accord à tout ça. Je voulais
juste faire remarquer qu'on peut tout de même faire
un peu d'arithmétique (additions, multiplications,
divisions etc.) en shell et cela de manière relativement
portable (en restant dans du shell POSIX en tout cas).

Par exemple :

a96459867
b06879835
diff=$(( b - a ))
days=$(( diff / 86400 ))
# etc.

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, et sur ce point
en général le shell est assez loin devant, en particulier
le shell /bin/sh sous Wheezy par exemple qui est différent
du bash, alors qu'à l'inverse le temps de chargement de
l'interpréteur Perl (*et* des éventuels modules nécessaires)
est nettement plus long et peut représenter une part non
négligeable dans le temps global de l'exécution du script.

Dans le cas présent, si on se limite *juste* au problème du
PO (ie étant données 2 dates, on calcule la différence en
jours, heures, minutes et secondes), je suis sûr que ça ira
plus vite en shell qu'en Perl (par contre, effectivement, au
niveau lisibilité du code etc. y'aura pas photo).

Voilà, c'est juste un petit bémol car sinon je suis d'accord
qu'il est toujours préférable d'utiliser un langage de script
adapté et qu'il faut privilégier la lisibilité du code plutôt
que les perfs (dont perso je n'ai rien à faire dans 99,9% de
mes scripts).

--
François Lafont

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/lrfosi$p19$

Stéphane GARGOLY

01/08/2014 à 12:20

Bonjour Ã tous les utilisateurs et dÃ©veloppeurs de Debian :

Le vendredi 1 aoÃ»t 2014 Ã 08:26, "Jean-Jacques Doti" r> a Ã©crit :

Le 31/07/2014 22:09, moi-meme a Ã©crit :
> Jeopeux avoir leur valeur vraie par
> moi$ date -d @1406779635
> jeudi 31 juillet 2014, 06:07:15 (UTC+0200)
> et
> moi$ date -d @1406484823
> dimanche 27 juillet 2014, 20:13:43 (UTC+0200)
>
> mais la diffÃ©rence de temps je ne vois pas comment la sortir
> la diffÃ©rence est de : 294812
> moi$ date +"%d jours %H heures %M minutes %S secondes" -d @294812
> 04 jours 10 heures 53 minutes 32 secondes
>
> Ya un jour de trop. C'est normal la diffÃ©rence est toujours une da te et
> le calendrier ne dÃ©marre pas au 0 Janvier :-)

Il y a aussi une heure de trop en raison du dÃ©calage entre l'heure
franÃ§aise et l'heure UTC puisque date, sans l'option -u, te donne
l'heure localeâ¦

Attention, aussi, au passage de l'heure d'hiver Ã l'heure d'Ã©tÃ © (et vice
versa).

Cordialement et Ã bientÃ´t,

StÃ©phane.

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

Sylvain L. Sauvage

01/08/2014 à 13:40

[â¦]
Par exemple :

a96459867
b06879835
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 d e
secondes.

Car moi-meme semble bien seulement vouloir un programme
simple pour faire Ã§a, soit avec `date`, soit avec un autre
programme.

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âun e
durÃ©e câest diffÃ©rent dâune date. Et ce quelq ue chose, câest une
bibliothÃ¨que, pour Perl, C, ou autre. DâoÃ¹ le fait qu e moi-meme
nâa trouvÃ© que des rÃ©fÃ©rences Ã Perl, C, Ja vaâ¦ 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â¦

> Le shell, Ã§a va bien un peu mais Ã§a devient vite diffic ile
> Ã 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 Â». Ma conclusion
gÃ©nÃ©ralisait : le shell, câest trÃ¨s bien comme g lu (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 manque s
du shell alors quâun seul processus interprÃ¨te suffirait e t
serait beaucoup plus clair (parfois un simple awk). (Sans parler
des UUOC ;o)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

[â¦]
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 d e
secondes.

Car moi-meme semble bien seulement vouloir un programme
simple pour faire Ã§a, soit avec `date`, soit avec un autre
programme.

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âun e
durÃ©e câest diffÃ©rent dâune date. Et ce quelq ue chose, câest une
bibliothÃ¨que, pour Perl, C, ou autre. DâoÃ¹ le fait qu e moi-meme
nâa trouvÃ© que des rÃ©fÃ©rences Ã Perl, C, Ja vaâ¦ 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â¦

> Le shell, Ã§a va bien un peu mais Ã§a devient vite diffic ile
> Ã 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 Â». Ma conclusion
gÃ©nÃ©ralisait : le shell, câest trÃ¨s bien comme g lu (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 manque s
du shell alors quâun seul processus interprÃ¨te suffirait e t
serait beaucoup plus clair (parfois un simple awk). (Sans parler
des UUOC ;o)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers debian-user-french-REQUEST@lists.debian.org
En cas de soucis, contactez EN ANGLAIS listmaster@lists.debian.org
Archive: https://lists.debian.org/2278442.03mTHGOCGy@earendil

Vous avez filtré cet utilisateur ! Consultez son message

[â¦]
Par exemple :

a96459867
b06879835
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 d e
secondes.

Car moi-meme semble bien seulement vouloir un programme
simple pour faire Ã§a, soit avec `date`, soit avec un autre
programme.

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âun e
durÃ©e câest diffÃ©rent dâune date. Et ce quelq ue chose, câest une
bibliothÃ¨que, pour Perl, C, ou autre. DâoÃ¹ le fait qu e moi-meme
nâa trouvÃ© que des rÃ©fÃ©rences Ã Perl, C, Ja vaâ¦ 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â¦

> Le shell, Ã§a va bien un peu mais Ã§a devient vite diffic ile
> Ã 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 Â». Ma conclusion
gÃ©nÃ©ralisait : le shell, câest trÃ¨s bien comme g lu (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 manque s
du shell alors quâun seul processus interprÃ¨te suffirait e t
serait beaucoup plus clair (parfois un simple awk). (Sans parler
des UUOC ;o)

--
Sylvain Sauvage

--
Lisez la FAQ de la liste avant de poser une question :
http://wiki.debian.org/fr/FrenchLists

Pour vous DESABONNER, envoyez un message avec comme objet "unsubscribe"
vers
En cas de soucis, contactez EN ANGLAIS
Archive: https://lists.debian.org/

calcul de temps

10 réponses

Veuillez sélectionner un problème