Forum Programmation.shell [résolu] [RSYNC] Mes règles d'inclusion/exclusion ne fonctionnent pas

Posté par (site web personnel) . Licence CC By‐SA.
Étiquettes :
3
25
août
2026

EDIT : après plusieurs tests, il apparait que mon script fonctionne comme attendu lorsque je détaille les inclusions :

--include='Desktop/***' --include='Documents/***' --include='Downloads/***' --include='Music/***' --include='Pictures/***' --include='Videos/***' --include='Works/***'

Merci à toutes les réponses qui m’ont permis d’isoler le problème au fur et à mesure.


Bonjour tout le monde,

J’utilise rsync pour un petit script de sauvegarde de répertoires.

Je souhaite inclure uniquement certains répertoires du répertoire-source, mais c’est tout le contenu du répertoire-source qui est sauvegardé.

Merci d’avance pour vos éclaircissements.

#!/bin/bash
SOURCE="/home/muchos/"
DESTINATION="/media/muchos/muchos-bkp/backup/"
# Check for backup disk and interrupt script if necessary
if [ ! -e "$DESTINATION" ]
then
echo "Backup disk missing!"
exit
fi
# Making backups...
rsync -a --progress --stats --delete --include={'Desktop/***','Documents/***','Downloads/***','Music/***','Pictures/***','Videos/***','Works/***'} --exclude=* $SOURCE $DESTINATION
# Change date of the file
DATE=$(date -I)
touch $DESTINATION$DATE
exit
  • # --exclude-from= ?

    Posté par . Évalué à 2 (+1/-0).

    Pas le temps de chercher le pépin dans la version --exclude=.
    Je me suis battu avec ça aussi il y a un paquet d'année.
    J'ai mis au point mes scripts en utilisant --exclude-from= finalement.
    Le paramètre est un fichier contenant les chemins relatifs à exclure de la synchro.
    Mon fichier contient un chemin par ligne sous la forme chemin/à/exclure, sans /, sans *. Ah ben justement, c'est peut-être là que le bas blesse dans la version --exclude=.

  • # Interpretation Bash

    Posté par (Mastodon) . Évalué à 10 (+8/-0).

    Attention, ce truc --exclude=* va être interpété par Bash (il va étendre le * à tous les fichiers présents).

    Essaie avec --exclude='*' ça devrait aller mieux.

    En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

    • [^] # Re: Interpretation Bash

      Posté par . Évalué à 6 (+5/-0). Dernière modification le 25 août 2026 à 20:03.

      Dans le même genre de conseil, ajouter "echo" devant l'appel à rsync pour voir ce que ce dernier voit réellement comme arguments, et aussi --dry-run tant que le problème persiste (surtout avec --delete...)

      • [^] # Re: Interpretation Bash

        Posté par (site web personnel) . Évalué à 1 (+0/-0).

        Je supposais que echo se contenterait de répéter l’instruction ; je ne pensais pas qu’il allait l’expliciter. Merci pour cette information !

        Debug the Web together.

        • [^] # Re: Interpretation Bash

          Posté par (Mastodon) . Évalué à 3 (+0/-0).

          Justement il faut bien comprendre : echo ne fait rien. Si tu tapes echo ls * c'est le bash qui interpréter, et echo va recevoir une liste de fichiers en paramètres.

          En théorie, la théorie et la pratique c'est pareil. En pratique c'est pas vrai.

          • [^] # Re: Interpretation Bash

            Posté par (site web personnel) . Évalué à 3 (+0/-0). Dernière modification le 29 août 2026 à 18:11.

            Pour chipoter: le echo sans rien est une commande interne de bash, l'autre est un binaire fourni par GNU coreutils.

            $ echo --help
            --help
            $ /bin/echo --help
            (...)
            Aide en ligne de GNU coreutils : <https://www.gnu.org/software/coreutils/>
            $ builtin echo --help
            --help
            $ builtin /bin/echo --help
            bash: builtin: /bin/echo : ceci n'est pas une primitive du shell
            • [^] # Re: Interpretation Bash

              Posté par (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

              Il y a en fait un certain nombre de commandes comme ça que POSIX recommande de faire interne au shell, mais de toujours en fournir une version externe aussi... :o Je crois que ça devait permettre de faire fonctionner certains anciens script avec des interpréteurs non-POSIX courants à l’époque (sur les machines qui avaient encore du Thompson et non du Bourne, ou du Bourne d’avant la normalisation, et aussi les machines de Berkeley qui utilisaient du C...)

              "It is seldom that liberty of any kind is lost all at once." ― David Hume

          • [^] # Re: Interpretation Bash

            Posté par (site web personnel, Mastodon) . Évalué à 2 (+0/-0).

            Il a raison : echo ne répète que ses arguments... ; d’où son nom-nom-nom ;)
            Mais tu as presque raison : avant que la commande d’écho ne print as is ses arguments, l’interpréteur de commande a d’abord évalué la ligne avec tout ce que cela implique (les espaces sont concaténés et les méta-caractères développés et les variables évalués etc. sauf si on pense à protéger/échapper...) :)
            Ton exemple est presque bon ; j’utilise souvent l’écho pour lister les fichiers, mais ça c’est une autre histoire...

            "It is seldom that liberty of any kind is lost all at once." ― David Hume

    • [^] # Re: Interpretation Bash

      Posté par (site web personnel, Mastodon) . Évalué à 4 (+2/-0).

      Ou échapper si l’on veut s’entêter à ne pas quoter : --exclude=\*

      Pour poursuivre sur cette bonne lancée, c’est un peu la bonne fortune que ça fonctionne le $SOURCE $DESTINATION non ?

      "It is seldom that liberty of any kind is lost all at once." ― David Hume

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.