Je tente d'instaurer des sauvegardes de mes fichiers locaux à l'aide de
rsnapshot, le répertoire d'accueil étant dans une partition d'un disque
externe USB. Quand cette partition est montée, tout se passe bien mais,
justement, elle ne l'est pas toujours et j'ai pensé la faire monter par un
script que rsnapshot serait censé exécuter avant tout autre action. Dans
/etc/rsnapshot.conf j'ai donc placé à l'endroit prévu cette ligne :
cmd_preexec /root/scripts/presnap.sh (avec une tabulation et sans espace) et
j'ai écrit ce script rudimentaire :
# cat /root/scripts/presnap.sh
#!/bin/bash
mount /dev/sdf1 /media/sauvegardes
sleep 3
et j'ai vérifié que l'exécution de ce script a bien pour effet de monter la
partition :
# mount | grep sdf1
/dev/sdf1 on /media/sauvegardes type ext3 (rw)
Maintenant, je la démonte et je lance rsnapshot :
# rsnapshot -v daily
31924: priorité précédente 0, nouvelle priorité 19
----------------------------------------------------------------------------
rsnapshot encountered an error! The program was invoked with these options:
/usr/bin/rsnapshot -v daily
----------------------------------------------------------------------------
ERROR: /media/sauvegardes/sauv does not exist.
ERROR: rsnapshot refuses to create snapshot_root when no_create_root is enabled
La commande mountpoint est plus adaptée. Sans compter que ton grep est largement sujet à erreur.
Désolé si je détourne un peu le fil (ceci étant il me semble que la question du PO est réglée), mais dans la continuité du problème, je me suis souvent demandé comment récupérer dans un script la liste des répertoires montés sur un système.
Jusqu'à présent j'utilise mount avec un petit cut comme dans :
mount | cut -d ' ' -f 3
mais c'est loin d'être satisfaisant puisque ça va planter avec des répertoires de montage possédant des espaces dans leur nom et il y a sûrement d'autres cas où ça plante. Bref, connaissez vous un moyen fiable d'avoir en sortie la liste des répertoires de montage d'un système (un nom de répertoire par ligne) ?
-- François Lafont
Le 13/03/2012 14:19, Nicolas George a écrit :
tst=$( mount | grep '/media/sauvegardes' )
La commande mountpoint est plus adaptée. Sans compter que ton grep est
largement sujet à erreur.
Désolé si je détourne un peu le fil (ceci étant il me semble que la
question du PO est réglée), mais dans la continuité du problème, je me
suis souvent demandé comment récupérer dans un script la liste des
répertoires montés sur un système.
Jusqu'à présent j'utilise mount avec un petit cut comme dans :
mount | cut -d ' ' -f 3
mais c'est loin d'être satisfaisant puisque ça va planter avec des
répertoires de montage possédant des espaces dans leur nom et il y a
sûrement d'autres cas où ça plante. Bref, connaissez vous un moyen
fiable d'avoir en sortie la liste des répertoires de montage d'un
système (un nom de répertoire par ligne) ?
La commande mountpoint est plus adaptée. Sans compter que ton grep est largement sujet à erreur.
Désolé si je détourne un peu le fil (ceci étant il me semble que la question du PO est réglée), mais dans la continuité du problème, je me suis souvent demandé comment récupérer dans un script la liste des répertoires montés sur un système.
Jusqu'à présent j'utilise mount avec un petit cut comme dans :
mount | cut -d ' ' -f 3
mais c'est loin d'être satisfaisant puisque ça va planter avec des répertoires de montage possédant des espaces dans leur nom et il y a sûrement d'autres cas où ça plante. Bref, connaissez vous un moyen fiable d'avoir en sortie la liste des répertoires de montage d'un système (un nom de répertoire par ligne) ?
-- François Lafont
Nicolas George
gerbier , dans le message <jjnl05$g3l$, a écrit :
mountpoint /media/sauvegardes if [ $? -eq 0 ]
On ne teste jamais si $? vaut 0, on teste la commande elle-même.
gerbier , dans le message <jjnl05$g3l$1@sxcom1.cnrm.meteo.fr>, a écrit :
mountpoint /media/sauvegardes
if [ $? -eq 0 ]
On ne teste jamais si $? vaut 0, on teste la commande elle-même.
On ne teste jamais si $? vaut 0, on teste la commande elle-même.
Francois Lafont
Le 13/03/2012 17:03, Nicolas George a écrit :
gerbier , dans le message <jjnl05$g3l$, a écrit :
mountpoint /media/sauvegardes if [ $? -eq 0 ]
On ne teste jamais si $? vaut 0, on teste la commande elle-même.
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la différence (à part au niveau du style bien sûr).
-- François Lafont
Le 13/03/2012 17:03, Nicolas George a écrit :
gerbier , dans le message <jjnl05$g3l$1@sxcom1.cnrm.meteo.fr>, a écrit :
mountpoint /media/sauvegardes
if [ $? -eq 0 ]
On ne teste jamais si $? vaut 0, on teste la commande elle-même.
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça
m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la
différence (à part au niveau du style bien sûr).
On ne teste jamais si $? vaut 0, on teste la commande elle-même.
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la différence (à part au niveau du style bien sûr).
-- François Lafont
Nicolas George
Francois Lafont , dans le message <4f5f6b78$0$5161$, a écrit :
Jusqu'à présent j'utilise mount avec un petit cut comme dans :
mount | cut -d ' ' -f 3
mais c'est loin d'être satisfaisant puisque ça va planter avec des répertoires de montage possédant des espaces dans leur nom et il y a sûrement d'autres cas où ça plante. Bref, connaissez vous un moyen fiable d'avoir en sortie la liste des répertoires de montage d'un système (un nom de répertoire par ligne) ?
/proc/mounts échappe les caractères spéciaux dans les noms de fichiers, il suffit de les déséchapper.
En revanche, sous Linux, la notion de liste des répertoires de montage du système est une notion assez floue, avec les namespaces.
Francois Lafont , dans le message
<4f5f6b78$0$5161$426a74cc@news.free.fr>, a écrit :
Jusqu'à présent j'utilise mount avec un petit cut comme dans :
mount | cut -d ' ' -f 3
mais c'est loin d'être satisfaisant puisque ça va planter avec des
répertoires de montage possédant des espaces dans leur nom et il y a
sûrement d'autres cas où ça plante. Bref, connaissez vous un moyen
fiable d'avoir en sortie la liste des répertoires de montage d'un
système (un nom de répertoire par ligne) ?
/proc/mounts échappe les caractères spéciaux dans les noms de fichiers, il
suffit de les déséchapper.
En revanche, sous Linux, la notion de liste des répertoires de montage du
système est une notion assez floue, avec les namespaces.
Francois Lafont , dans le message <4f5f6b78$0$5161$, a écrit :
Jusqu'à présent j'utilise mount avec un petit cut comme dans :
mount | cut -d ' ' -f 3
mais c'est loin d'être satisfaisant puisque ça va planter avec des répertoires de montage possédant des espaces dans leur nom et il y a sûrement d'autres cas où ça plante. Bref, connaissez vous un moyen fiable d'avoir en sortie la liste des répertoires de montage d'un système (un nom de répertoire par ligne) ?
/proc/mounts échappe les caractères spéciaux dans les noms de fichiers, il suffit de les déséchapper.
En revanche, sous Linux, la notion de liste des répertoires de montage du système est une notion assez floue, avec les namespaces.
Nicolas George
Francois Lafont , dans le message <4f5f7189$0$16656$, a écrit :
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la différence (à part au niveau du style bien sûr).
C'est théoriquement équivalent : tester une commande, c'est tester si sa valeur de retour est 0, et la valeur de retour est stockée dans $?. Mais la syntaxe en deux lignes séparées a deux défauts :
- Sur certains shell, [ peut être une commande externe ; d'ailleurs, tu as probablement un /usr/bin/[ sur ton système. Dans ces conditions, faire la comparaison est un gaspillage important. D'ailleurs, même si [ est un builtin, faire la comparaison explicitement coûte du temps, même si très peu.
- L'écriture est fragile : il est facile de se retrouver à déplacer une ligne sans l'autre, ou ajouter quelque chose entre les deux, et ça casse tout.
Francois Lafont , dans le message
<4f5f7189$0$16656$426a74cc@news.free.fr>, a écrit :
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça
m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la
différence (à part au niveau du style bien sûr).
C'est théoriquement équivalent : tester une commande, c'est tester si sa
valeur de retour est 0, et la valeur de retour est stockée dans $?. Mais la
syntaxe en deux lignes séparées a deux défauts :
- Sur certains shell, [ peut être une commande externe ; d'ailleurs, tu as
probablement un /usr/bin/[ sur ton système. Dans ces conditions, faire la
comparaison est un gaspillage important. D'ailleurs, même si [ est un
builtin, faire la comparaison explicitement coûte du temps, même si très
peu.
- L'écriture est fragile : il est facile de se retrouver à déplacer une
ligne sans l'autre, ou ajouter quelque chose entre les deux, et ça casse
tout.
Francois Lafont , dans le message <4f5f7189$0$16656$, a écrit :
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la différence (à part au niveau du style bien sûr).
C'est théoriquement équivalent : tester une commande, c'est tester si sa valeur de retour est 0, et la valeur de retour est stockée dans $?. Mais la syntaxe en deux lignes séparées a deux défauts :
- Sur certains shell, [ peut être une commande externe ; d'ailleurs, tu as probablement un /usr/bin/[ sur ton système. Dans ces conditions, faire la comparaison est un gaspillage important. D'ailleurs, même si [ est un builtin, faire la comparaison explicitement coûte du temps, même si très peu.
- L'écriture est fragile : il est facile de se retrouver à déplacer une ligne sans l'autre, ou ajouter quelque chose entre les deux, et ça casse tout.
Francois Lafont
Le 13/03/2012 17:14, Nicolas George a écrit :
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la différence (à part au niveau du style bien sûr).
C'est théoriquement équivalent : tester une commande, c'est tester si sa valeur de retour est 0, et la valeur de retour est stockée dans $?. Mais la syntaxe en deux lignes séparées a deux défauts :
- Sur certains shell, [ peut être une commande externe ; d'ailleurs, tu as probablement un /usr/bin/[ sur ton système. Dans ces conditions, faire la comparaison est un gaspillage important. D'ailleurs, même si [ est un builtin, faire la comparaison explicitement coûte du temps, même si très peu.
Ok. Effectivement sur mon bash, [ est builtin mais j'ai bien un fichier /usr/bin/[. Je ne pensais pas qu'un tel fichier existait. J'imaginais que [ était toujours builtin, voire un mot clé du shell.
- L'écriture est fragile : il est facile de se retrouver à déplacer une ligne sans l'autre, ou ajouter quelque chose entre les deux, et ça casse tout.
Ah oui, c'est un argument que je trouve convainquant. Merci bien pour les explications.
-- François Lafont
Le 13/03/2012 17:14, Nicolas George a écrit :
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça
m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la
différence (à part au niveau du style bien sûr).
C'est théoriquement équivalent : tester une commande, c'est tester si sa
valeur de retour est 0, et la valeur de retour est stockée dans $?. Mais la
syntaxe en deux lignes séparées a deux défauts :
- Sur certains shell, [ peut être une commande externe ; d'ailleurs, tu as
probablement un /usr/bin/[ sur ton système. Dans ces conditions, faire la
comparaison est un gaspillage important. D'ailleurs, même si [ est un
builtin, faire la comparaison explicitement coûte du temps, même si très
peu.
Ok. Effectivement sur mon bash, [ est builtin mais j'ai bien un fichier
/usr/bin/[. Je ne pensais pas qu'un tel fichier existait. J'imaginais
que [ était toujours builtin, voire un mot clé du shell.
- L'écriture est fragile : il est facile de se retrouver à déplacer une
ligne sans l'autre, ou ajouter quelque chose entre les deux, et ça casse
tout.
Ah oui, c'est un argument que je trouve convainquant.
Merci bien pour les explications.
Est-ce que tu pourrais donner quelques explications sur ce point ? Ça m'intéresse. En pratique, je ne vois pas trop (voire pas du tout) la différence (à part au niveau du style bien sûr).
C'est théoriquement équivalent : tester une commande, c'est tester si sa valeur de retour est 0, et la valeur de retour est stockée dans $?. Mais la syntaxe en deux lignes séparées a deux défauts :
- Sur certains shell, [ peut être une commande externe ; d'ailleurs, tu as probablement un /usr/bin/[ sur ton système. Dans ces conditions, faire la comparaison est un gaspillage important. D'ailleurs, même si [ est un builtin, faire la comparaison explicitement coûte du temps, même si très peu.
Ok. Effectivement sur mon bash, [ est builtin mais j'ai bien un fichier /usr/bin/[. Je ne pensais pas qu'un tel fichier existait. J'imaginais que [ était toujours builtin, voire un mot clé du shell.
- L'écriture est fragile : il est facile de se retrouver à déplacer une ligne sans l'autre, ou ajouter quelque chose entre les deux, et ça casse tout.
Ah oui, c'est un argument que je trouve convainquant. Merci bien pour les explications.
-- François Lafont
Francois Lafont
Le 13/03/2012 17:10, Nicolas George a écrit :
/proc/mounts échappe les caractères spéciaux dans les noms de fichiers, il suffit de les déséchapper.
Comment faire pour retrouver le nom de départ du répertoire ? Par exemple, si j'ai un répertoire monté, alors concernant son nom :
- un espace devient 40 dans le fichier /proc/mounts - le caractère devient 134 dans le fichier /proc/mounts - etc.
J'ignore d'où viennent ces valeurs et comment faire la « traduction ».
-- François Lafont
Le 13/03/2012 17:10, Nicolas George a écrit :
/proc/mounts échappe les caractères spéciaux dans les noms de fichiers, il
suffit de les déséchapper.
Comment faire pour retrouver le nom de départ du répertoire ? Par
exemple, si j'ai un répertoire monté, alors concernant son nom :
- un espace devient 40 dans le fichier /proc/mounts
- le caractère devient 134 dans le fichier /proc/mounts
- etc.
J'ignore d'où viennent ces valeurs et comment faire la « traduction ».
- un espace devient 40 dans le fichier /proc/mounts - le caractère devient 134 dans le fichier /proc/mounts
C'est le code ascii en octal.
Ok. Mais comment traduire simplement des noms comme 'a 40b' en 'a b' etc. ?
-- François Lafont
Emmanuel Florac
Le Tue, 13 Mar 2012 14:44:56 +0100, geo cherchetout a écrit:
Pas grave, je peux aussi regarder dans /etc/mtab.
Surtout pas, ça n'est pas fiable du tout. Par contre /proc/mounts l'est.
-- Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. Alan Kay
Le Tue, 13 Mar 2012 14:44:56 +0100, geo cherchetout a écrit:
Pas grave, je peux aussi regarder dans /etc/mtab.
Surtout pas, ça n'est pas fiable du tout. Par contre /proc/mounts l'est.
--
Most software today is very much like an Egyptian pyramid with millions
of bricks piled on top of each other, with no structural integrity, but
just done by brute force and thousands of slaves.
Alan Kay
Le Tue, 13 Mar 2012 14:44:56 +0100, geo cherchetout a écrit:
Pas grave, je peux aussi regarder dans /etc/mtab.
Surtout pas, ça n'est pas fiable du tout. Par contre /proc/mounts l'est.
-- Most software today is very much like an Egyptian pyramid with millions of bricks piled on top of each other, with no structural integrity, but just done by brute force and thousands of slaves. Alan Kay
