Discussion :

[Jipété]

Bonjour,

En ce qui me concerne, je n'ai pas besoin de savoir s'il y a eu des différences dans le temps et quand, j'ai juste besoin d'être informé s'il y en a une entre maintenant et la dernière fois que le fichier a été enregistré, à charge pour moi d'initier une enquête et éventuellement de noter ça dans un autre fichier.

Enfin, sur ce point-là, chacun verra midi à sa porte.

Maintenant, si quelqu'un sait où trouver des détails parlants chez Debian, qu'il nous en informe, parce que là, même si la date de l'incident avait coïncidé tip-top avec le passage 11.3 --> 11.4 (comme je l'ai supposé), je ne sais pas quoi et où chercher pour confirmer.

mais ce serait une bonne idée de dynamiser l'assignation, puisque tu le dis toi-même, ça peut évoluer...

Comme ça ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

nbDisks=$(df -x tmpfs -x devtmpfs -x vboxsf | tail -n +2 | wc -l)

Ça fonctionne :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ echo $nbDisks
3

Plus qu'à attendre qu'un signalement sur différence se manifeste...

Ah, pas besoin de newline en début du fichier de log, donc date +'%c %Z' > "$logfile" et valà !

[Sve@r]

C'est mes yeux où il y avait là un nouveau post, post qui parlait d'un souci survenu hier de façon anarchique, et qui a disparu (le post, pas le souci) ???

[Jipété]

C'est mes yeux où il y avait là un nouveau post, post qui parlait d'un souci survenu hier de façon anarchique, et qui a disparu (le post, pas le souci) ???

Tu n'as pas rêvé, et moi j'ai été trop précipité pour poster : mon petit script n'es pas optimisé pour travailler avec des périph (clé uzbe) insérés avant que le script soit appelé, résultat, ce dernier se prend les pieds dans le tapis,
Et bien sûr je me suis rendu compte que mon post n'était pas nécessaire, après l'avoir posté, hé ouais.

Quand j'aurai 5 minutes, je verrai ce que je peux faire...

[Sve@r]

mon petit script n'est pas optimisé pour travailler avec des périph (clé uzbe)

Ok, ça rassure de voir que sous Linux, l'informatique n'est pas une science aléatoire

Quand j'aurai 5 minutes, je verrai ce que je peux faire...

A mon avis, un truc style df -x ... -x ... /dev/?d* devrait faire l'affaire (au début je pensais à /dev/sd puis j'ai pensé aux disques durs ancienne génération nommés "/dev/hd" donc j'ai simplifié en "/dev/?d")

[Jipété]

Allez, j'ai 5 minutes (et même 40, ça grave sur un vieux cd-rw en 4x, je veux tester une compil et apprendre à graver en ligne2commande puisque Brasero et k3b ne sont pas fichus de faire des cd's audio exotiques, dans le sens où au début je découpe 38 minutes en 5 morceaux enchainés, suivis par 4 morceaux indépendants, et ça patauge -- mais maintenant je comprends un peu mieux les fichiers .cue et .toc).

Donc ce matin à un moment j'ai inséré une clé et je me suis pris ça dans les dents, à l'ouverture d'une console :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
# /data/temp/scandisks.sh: ligne 20: ((: 3900768256=3900768256  : tentative d''affectation à une non-variable (le symbole erroné est « =3900768256 »)
# /data/temp/scandisks.sh: ligne 20: ((: 205286293504=205286293504  : tentative d''affectation à une non-variable (le symbole erroné est « =205286293504 »)
# /data/temp/scandisks.sh: ligne 20: ((: 1761439584256=1761439584256  : tentative d''affectation à une non-variable (le symbole erroné est « =1761439584256 »)
# /data/temp/scandisks.sh: ligne 20: ((: 1761439584256=1761439584256  : tentative d''affectation à une non-variable (le symbole erroné est « =1761439584256 »)

Là où je n'ai pas percuté, c'est qu'il y a 4 lignes (oui, une pour chaque périph. D'habitude je n'en ai que 3 quand l'outil est lancé et il semblerait que je ne l'aie jamais lancé après l'insertion d'une clé ou autre.)

Donc ce que j'ai montré c'est la fin du log d'erreur, et juste au-dessus il y avait ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
/                            /dev/sda1  ext4            rw,noatime
├─/data                      /dev/sdb1  ext4            rw,noatime
├─/dbck                      /dev/sdc1  ext4            rw,noatime
└─/media/usb                 /dev/sdd1  vfat            rw,relatime,fmask=0022,dmask=0022,codepage=850,iocharset=iso8859-1,shortname=mixed,errors=remount-ro
 
/dev/sda1 on /
/dev/sdb1 on /data
/dev/sdc1 on /dbck
/dev/sdd1 on /media/usb

2 fois 4 lignes qui sont les sorties normales de mon .bashrc où on trouve findmnt | grep '/sd' et mount | awk "/\/dev\/sd/ {print \$1,\$2,\$3}", sauf pour la 4^e ligne deux fois, qui n'y est jamais, d'habitude. Du coup j'ai essayé de comprendre ce qui se passait sans bien analyser.

La ligne 20, c'est la plus longue, la 6 ici (lacicici, ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
# comparaison des tailles disque par disque
for disk in "${!oldData[@]}"
do
    # ligne dessous à décommenter pour test du test
    #curData[$disk]=$((curData[$disk]+1))
    (( "${oldData[$disk]}" == "${curData[$disk]}" )) || echo "$disk: old=${oldData[$disk]}, new=${curData[$disk]}"
done | sort -k1,1 -t ':'

La première question que je me pose, c'est pourquoi la sortie des erreurs n'est-elle pas dans l'ordre des périph's ?
La première ligne correspond à la plus petite taille, c'est la clé sdd1, suivie du ssd sda1 puis difficile de dire si c'est sdb1 ou sdc1 car ils ont les mêmes tailles.

Ensuite on peut s'interroger sur la validité des 4 messages d'erreur, que je n'ai jamais vus quand il n'y a pas de clé et qu'il n'y a que 3 périph's.

Mais ma gravure vient de se terminer, faut que je teste tout ça...

[jack-ft]

La ligne 20, c'est la plus longue, la 6 ici (lacicici, ) :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
# comparaison des tailles disque par disque
for disk in "${!oldData[@]}"
do
    # ligne dessous à décommenter pour test du test
    #curData[$disk]=$((curData[$disk]+1))
    (( "${oldData[$disk]}" == "${curData[$disk]}" )) || echo "$disk: old=${oldData[$disk]}, new=${curData[$disk]}"
done | sort -k1,1 -t ':'

Je ne suis jamais très à l'aise avec les "(("...

Quel est l'intérêt (la différence) de faire (( "${oldData[$disk]}" == "${curData[$disk]}" )) plutôt que [ "${oldData[$disk]}" = "${curData[$disk]}" ] ?

[Sve@r]

Quel est l'intérêt (la différence) de faire (( "${oldData[$disk]}" == "${curData[$disk]}" )) plutôt que [ "${oldData[$disk]}" = "${curData[$disk]}" ] ?

C'est un test plus intelligent qui rattrape les conneries (rattrapables).

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ [ "5" = "05" ] && echo "ok" || echo "bad"
bad
$ (( "5" == "05" )) && echo "ok" || echo "bad"
ok

On aurait pu écrire [ ${oldData[$disk]} -eq ${curData[$disk]} ] (sans guillemets parce que des chiffres et donc avec "-eq" qui sait comparer "5" avec "05") mais les doubles parenthèses ont des avantages en plus que je n'ai malheureusement plus en tête (mais j'ai confiance, N_BaH et son oeil d'aigle va vite trouver ce post et venir me les rappeler )

[N_BaH]

par exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

((n=1, v=2-n, n==v))

mais attention :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(( 8 == 08 ))
bash: ((: 8 == 08 : valeur trop grande pour la base (le symbole erroné est «*08*»)

alors que

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

test 8 -eq 08

ne se plaint pas et fait correctement la comparaison.

[Sve@r]

par exemple : ((n=1, v=2-n, n==v))

Ah oui, ça c'est joli !!!

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ ((1+1 == 3-1)) && echo ok
ok

[Jipété]

Je ne suis jamais très à l'aise avec les "(("...

Tiens, ça va te changer la vie,

[Sve@r]

Tiens, ça va te changer la vie,

Je crois que ça va changer la vie de beaucoup de monde

[disedorgue]

mais attention :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(( 8 == 08 ))
bash: ((: 8 == 08 : valeur trop grande pour la base (le symbole erroné est «*08*»)

C'est aussi pour ça que si on veut être propre, on précisera la base dans laquelle on est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
$ (( 10#8 == 10#08 )) && echo ok
ok
$ (( 10#8 == 8#08 )) && echo ok
-bash: ((: 10#8 == 8#08: value too great for base (error token is "8#08")

[Sve@r]

C'est aussi pour ça que si on veut être propre, on précisera la base dans laquelle on est:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ (( 10#8 == 10#08 )) && echo ok
ok

C'est bien de vouloir être propre. Mais tu n'as pas l'impression que le premier "#8" met en commentaire tout le reste ???

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ (( 10#8 == 14#08 )) && echo ok
ok

[disedorgue]

C'est bien de vouloir être propre. Mais tu n'as pas l'impression que le premier "#8" met en commentaire tout le reste ???

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
$ (( 10#8 == 14#08 )) && echo ok
ok

En base 14 ou en base 10, 8 est bien égale à 8...

[N_BaH]

pourquoi ?

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
echo $((14#08))
8
$

[Sve@r]

En base 14 ou en base 10, 8 est bien égale à 8...

Parce que le nombre avant c'est la base !!! Je pensais que la base était après "#" et que avant c'était le nombre à comparer.
Et vu que "#" c'est une marque de commentaire, je pensais que la fin de la comparaison n'était pas évaluée


Ok

Code bash :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
(( 10#8 == 10#7 )) && echo ok || echo bad
bad

Remarque, si la fin de la comparaison n'avait pas été évaluée, ça aurait été à cause du commentaire qui aurait alors shunté tout le reste de la ligne y compris le "echo" final