df : taille variable de la partition

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.

Citation:

---

Envoyé par N_BaH

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

---

Comme ça ?

Code:

---

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

---

Ça fonctionne :

Code:

---

1 2	$ echo $nbDisks 3

---

:ccool:
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à !

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) ???

Citation:

---

Envoyé par 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) ???

---

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, :aie:
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...

Citation:

---

Envoyé par Jipété

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 :aie:

Citation:

---

Envoyé par Jipété

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")

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:

---

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:

---

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, :ptdr:) :

Code:

---

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...

Citation:

---

Envoyé par Jipété

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

Code:

---

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]}" ] ?

Citation:

---

Envoyé par jack-ft

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:

---

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 :mrgreen:)

par exemple :

Code:

---

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

---

mais attention :

Code:

---

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

---

alors que

Code:

---

test 8 -eq 08

---

ne se plaint pas et fait correctement la comparaison.

Citation:

---

Envoyé par N_BaH

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

---

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

Code:

---

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

---

:lahola: :ccool:

Citation:

---

Envoyé par jack-ft

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

---

Tiens, ça va te changer la vie, :plusser:

Citation:

---

Envoyé par Jipété

Tiens, ça va te changer la vie, :plusser:

---

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

Citation:

---

Envoyé par N_BaH

mais attention :

Code:

---

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:

---

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")

---

Citation:

---

Envoyé par disedorgue

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

Code:

---

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:

---

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

---

:ptdr:

Citation:

---

Envoyé par Sve@r

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:

---

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

---

:ptdr:

---

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

pourquoi ?

Code:

---

1 2 3

echo $((14#08)) 8 $

---

Citation:

---

Envoyé par disedorgue

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 :ptdr:


Ok

Code:

---

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 :ave:
:chin: