Variable pour commande dans script en vrac après 1re utilisation

Bonsoir,

je suis sur la mise au point d'un petit script de sauvegarde perso, basé sur bash et l'ami rsync, et je tombe sur un os :aie:

Soit la variable rsync_cmd="rsync -vrRlpEogthq --delete --progress" définie au début du script.

Je l'utilise une 1re fois pour faire une sauvegarde interne de certains dossiers vers une partoche d'un autre DD interne à la machine, comme ça dans le script :

Code:

---

$rsync_cmd "$source" "$cible"

---

et tout va bien.

L'idée, c'est de sauvegarder aussi sur un DD externe (usb), à la suite de ce qui vient d'être fait, automatiquement si le DD est présent (détection ok).

Je vous mets juste la partie concernée, comme ça vous voyez que je teste bien la présence de mes source et cible :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12

if [ $cptr_media = "1" ]; then cible_ext="$champ"/"$cible_folder" if [ -d "$source" ] && [ -d "$cible_ext" ]; then echo "Script de sauvegarde :" "$champ" "détecté !" echo "Script de sauvegarde : archivage de "$source" sur" "$cible_ext""..." echo "$rsync_cmd" "$source" "$cible_ext" #rsync... (ligne 176) $rsync_cmd "$source" "$cible_ext" echo $? #127 avec ou sans /usr/bin/ fi fi

---

et voilà les résultats :

Citation:

---

Script de sauvegarde : /media/MyPassport détecté !
Script de sauvegarde : archivage de /media/sdb3/save_debian sur /media/MyPassport/save_debox...
rsync -vrRlpEogthq --delete --progress /media/sdb3/save_debian /media/MyPassport/save_debox
./backup.sh: ligne176: rsync -vrRlpEogthq --delete --progress : commande introuvable
127

---

8O
Du coup je rajoute "/usr/bin/" dans $rsync_cmd, je relance et re-paf !

Citation:

---

{2 lignes identiques omises pour clarté}
/usr/bin/rsync -vrRlpEogthq --delete --progress /media/sdb3/save_debian /media/MyPassport/save_debox
./backup.sh: ligne176: /usr/bin/rsync -vrRlpEogthq --delete --progress: Aucun fichier ou dossier de ce type
127

---

:calim2:

Et pourtant, c'est la même commande que lors du premier passage, pour la sauvegarde interne... :|
Je ne comprends pas... :marteau:

Le seul truc que je note, c'est typographique... La 1re erreur apparaît ainsi :
--progress :
quand la 2de s'affiche :
--progress:
Sans espace avant le ":"
Est-ce une piste ?

Et 127 ça veut dire, en Bash, command not found :koi:

Je suis sec, là, alors si quelqu'un a une idée, je le bénis :zoubi:

Bonjour,

utilise un alias, en activant auparavant l'option shell expand_aliases, ou alors utilise une fonction, parce qu'avec une commande "complexe" dans une variable en général ça coince, en effet.

Citation:

---

Envoyé par N_BaH

(...) parce qu'avec une commande "complexe" dans une variable en général ça coince, en effet.

---

Euh, je ne vois pas en quoi

Code:

---

$rsync_cmd "$source" "$cible_ext"

---

qui ne fonctionne pas, serait plus "complexe" que

Code:

---

$rsync_cmd "$source" "$cible"

---

qui fonctionne.
:koi:

Citation:

---

Envoyé par N_BaH

utilise un alias, en activant auparavant l'option shell expand_aliases,

---

Comment ?
Connais pas, là, maintenant (pas cherché).
Exemple ?

Citation:

---

Envoyé par N_BaH

ou alors utilise une fonction

---

Dans ma boucle if au lieu d'appeler $rync_cmd... j'appelle une fonction qui contiendra juste $rsync_cmd... ?
(juste pour être sûr, parce que ce comportement me perturbe 8O)

Merci de tes retours,

soit :

Code:

---

1 2 3 4 5

#!/bin/bash   shopt -s expand_aliases alias rsync_cmd='rsync -vrRlpEogthq --delete --progress' #etc

---

soit :

Code:

---

1 2 3

#!/bin/bash   rsync_cmd(){ rsync -vrRlpEogthq --delete --progress "$1" "$2";}

---

et tu appelles l'un ou l'autre comme une commande normale.

j'appelle "commande complexe" une commande composée de plusieurs mots.
des fois ça marche, des fois ça marche pas
...
?
dans le doute, je m'abstiens, et utilise de préférence une fonction.

Yep !

J'ai pris l'option 2 et bingo ! :ccool:

Citation:

---

Envoyé par N_BaH

(...) des fois ça marche, des fois ça marche pas

---

Hallucinant :wow:

Un grand merci à toi, j'aurais jamais trouvé tout seul (vais plus avoir confiance en l'informatique, moi...) :zoubi: :mouarf:

Salut,

Citation:

---

Envoyé par Jipété

Et pourtant, c'est la même commande que lors du premier passage, pour la sauvegarde interne... :|
Je ne comprends pas... :marteau:

---

Ne modifierais-tu pas la variable IFS entre les 2 commandes ??
Exemple :

Code:

---

1 2 3 4 5 6

# cmd='ls -l' # $cmd total 0 # IFS= # $cmd bash: ls -l: command not found

---

Yep !

Citation:

---

Envoyé par Postmortem

Salut,


Ne modifierais-tu pas la variable IFS entre les 2 commandes ??
Exemple :

Code:

---

1 2 3 4 5 6

# cmd='ls -l' # $cmd total 0 # IFS= # $cmd bash: ls -l: command not found

---

---

Je ne sais pas d'où tu sors (je n'ai pas souvent vu ton pseudo par ici ;)) mais en tout cas je te dis chapeau !

Oui, j'utilise et modifie et restaure IFS !
Comment as-tu trouvé cela ? Tu lis dans mes pensées à longue distance :mrgreen:

J'ai bien noté, en relisant attentivement mon script avant de poster et aussi pendant la discussion avec N_BaH, que cette utilisation était la seule chose qui changeait (mis à part l'assignation triviale de valeurs aux variables) entre la sauvegarde interne et la sauvegarde externe.

Mais j'ai eu la flemme, une fois une solution trouvée, de revenir en arrière pour faire d'autres tests.

Voilà mon utilisation :

Code:

---

1 2 3 4

saved_ifs=$IFS IFS=$'\n\r' for ligne in $devlist; do detect_an_external_media_in_df-output $ligne; done IFS=$saved_ifs

---

Si je commente la 2e ligne, la fonction ne détecte plus de media externe. Et dans son corps j'assigne IFS=$' ' à chaque tour : c'est peut-être pas bon ? Pas trouvé comment faire autrement.

Bon, la 4e ligne est quand même censée restaurer l'état d'origine, non ?

J'ai dû m'embrouiller quelque part (bien caché :mrgreen:), j'y retournerai ces jours-ci !

Merci de m'avoir remonté ce truc, et dans l'attente,si tu as d'autres idées ne te gène pas :ccool:

Citation:

---

la 4e ligne est quand même censée restaurer l'état d'origine, non ?

---

non, pas sans guillemets autour.

Yep !

Citation:

---

Envoyé par N_BaH

non, pas sans guillemets autour.

---

Effectivement.

Et ça, c'est un truc que je n'ai toujours pas capté... Des fois il faut les mettre, des fois c'est pas nécessaire, c'est à y perdre son latin :aie:

Bref, au final j'ai même plus besoin de l'option 2 (cf. mon post du 5/1) et ça fonctionne, :yaisse: !

Salut,

Citation:

---

Envoyé par N_BaH

non, pas sans guillemets autour.

---

Il me semble que dans le cas d'une affectation en bash, tata=$toto fait exactement la même chose que tata="$toto" même si l'expansion de $toto contient espaces ou autres caractères.

En tout cas, la restauration de l'IFS comme fait par Jipété le remet exactement comme il était :

Code:

---

1 2 3 4 5 6 7 8 9

# sed -n l <<< "$IFS" \t$ $ # saved_ifs=$IFS # IFS=$'\n\r' # IFS=$saved_ifs # sed -n l <<< "$IFS" \t$ $

---

Citation:

---

Envoyé par Jipété

Oui, j'utilise et modifie et restaure IFS !
Comment as-tu trouvé cela ? Tu lis dans mes pensées à longue distance :mrgreen:

---

J'ai vu ça grâce au message d'erreur, il prenait toute la commande et ses arguments comme un seul mot donc je me suis dit que le découpage en mots suite à l'expansion ne se faisait pas... Et donc qu'il y avait des chances que ça vienne de l'IFS.

Par contre, si ça ne fonctionne toujours pas même après la restauration de l'IFS, ben là je vois pas.
Puis, comme l'a proposé N_BaH, la solution de l'alias ou de la fonction est bien mieux dans ce genre de cas.

Citation:

---

Envoyé par Jipété

Je ne sais pas d'où tu sors (je n'ai pas souvent vu ton pseudo par ici ;)) mais en tout cas je te dis chapeau !

---

Merci !
En fait, ça fait très longtemps que je consulte ce forum mais je m'étais pas inscrit.
Les messages de N_BaH et plusieurs autres membres m'ont souvent bcp aidé ! Et tout le site developpez.com en général ; je pense notamment à un client chez lequel j'avais du mettre en place une réplication de BDD MYSQL et heureusement que j'avais trouvé le tuto ici parce qu'on ne peut pas dire que les DBAs de mon client m'avaient bcp aidé !
Enfin bref, si je peux aider en retour, c'est la moindre des choses ! Donc quand j'ai un peu de temps j'essaie de filer un coup de main (mais je suis souvent devancé par N_BaH entre autres, donc j'ai pas encore mis bcp de messages ! )

Yep !

Citation:

---

Envoyé par Postmortem

Il me semble que dans le cas d'une affectation en bash, tata=$toto fait exactement la même chose que tata="$toto" même si l'expansion de $toto contient espaces ou autres caractères.

---

Ah ça c'est une joyeuse misère pour moi : ça fait un bail que je code en Pascal (Delphi3/6/7, Lazarus), un peu de VB, un peu de C, ie je suis habitué aux variables typées et une fois la syntaxe du langage intégrée, y a plus à y revenir.
En Bash je ne sais jamais s'il les faut ou pas, ces foutues doubles quotes (parce qu'il y a les simples, aussi, et les inverses :aie:), me semble avoir lu un jour que dans le doute valait mieux toujours les mettre et basta, mais ça ne me satisfait pas, intellectuellement parlant.

Citation:

---

Envoyé par Postmortem

Par contre, si ça ne fonctionne toujours pas même après la restauration de l'IFS, ben là je vois pas.
Puis, comme l'a proposé N_BaH, la solution de l'alias ou de la fonction est bien mieux dans ce genre de cas.

---

Si si, ça fonctionne maintenant (relis bien mon post du 8 à 10h14), et j'ai gardé dans un coin la fonction (je la préfère à l'alias : une seule ligne à taper, ça fait moins de risques d'erreurs :mouarf:) de N_BaH, ça servira sûrement un jour ;)

Citation:

---

Envoyé par Postmortem

Donc quand j'ai un peu de temps j'essaie de filer un coup de main (mais je suis souvent devancé par N_BaH entre autres, donc j'ai pas encore mis bcp de messages ! )

---

C'est pas le nombre qui compte, c'est la qualité !
La preuve, tu débarques ici 2 jours plus tard (limite j'avais zappé puisque N_BaH m'avait fourni une solution) et tu mets le doigt juste là où ça fait mal :ccool:

À pluche ;)