Comment supprimer des fichiers uniquement, mais conserver la structure du répertoire?

16

Je voudrais supprimer tous les fichiers, mais conserver la structure des dossiers. Y a-t-il un moyen?

REMARQUE: (j'utilise GNU bash 4.1.5).

bash bash-script

— Tom Brito
source

1

Comment voulez-vous exactement «exclure»? Utilisez-vous une commande quelconque? Si oui, veuillez mettre à jour votre question pour l'inclure.

— slm

stackoverflow.com/questions/4073969/…

— rphv

Je pense que vous voulez dire supprimer tous les fichiers.

— slm

1

@slm J'ai mis à jour la commande que j'utilise habituellement pour exclure des fichiers.

— Tom Brito

Non, vous ne l'avez pas :-) Ou, si vous l'avez fait, vous l'avez retiré à nouveau

— Mawg dit de rétablir Monica

17

Essaye ça:

find . ! -type d -exec rm '{}' \;

Cela supprimera chaque fichier, à l'exception des répertoires, sous le répertoire de travail actuel. Soyez extrêmement prudent avec cette commande.

Si la version de findsur votre machine le prend en charge, vous pouvez également utiliser

find . ! -type d -delete

@slm: Je ne sais pas à quel point c'est portable. Je l'ai ajouté comme option secondaire. Je viens de réaliser que mon montage a rendu ma réponse pratiquement identique à la vôtre. Désolé pour ça; ce n'était pas mon intention.

Le '{}' protège-t-il contre les espaces dans les fichiers? Je vois que vous utilisez tout le temps et je ne pense pas l'avoir jamais utilisé avant de vous voir publier des solutions avec.

— slm

A partir de la page de manuel GNU find: "Notez que les accolades sont placées entre guillemets simples pour les protéger de l'interprétation en tant que ponctuation de script shell." Je ne sais pas quand c'est nécessaire. Je le fais surtout par habitude. La findcommande ne voit jamais les guillemets. Il voit simplement le {}marqueur comme un argument.

Je le vois sur l'exemple, mais les modèles le montrent, " -exec command {} +" & this " -exec command ;". J'ai utilisé le \;passé dans le passé, jamais le '{}'.

— slm

@slm: Les modèles ne montrent pas non plus l'échappement du point-virgule, ce qui est généralement nécessaire lors de l'exécution d'un shell find. Je pense que les modèles sont destinés à montrer les arguments dont la findcommande a besoin et ne se soucient de rien lié au shell.

7

Vous pouvez utiliser la commande findpour localiser chaque fichier mais conserver la structure du répertoire:

$ find /some/dir -type f -exec rm {} +

Selon ce Q&A Unix et Linux intitulé: gnu trouver et masquer le {} pour certains shells - lequel? , échapper au {}avec des ticks simples ( ') ne semble plus nécessaire avec les shells modernes tels que Bash.

— slm
source

1

Le moyen facile de supprimer récursivement tous les fichiers normaux du répertoire et des sous-répertoires actuels:

zsh -c 'rm **/*(.)'

Seul zsh a des qualificatifs de globalisation pour faire correspondre les fichiers par type. Cependant, la rmcommande ne fonctionne pas sur les répertoires, donc en bash, vous pouvez utiliser

shopt -s globstar
rm **/*

Cela ne fonctionne pas pour les commandes autres que rmsi. En général, vous pouvez utiliser find:

find . -type f -delete

ou si votre findne prend pas en charge -delete:

find . -type f -exec rm {} +

— Gilles 'SO- arrête d'être méchant'
source

-2

J'avais une exigence similaire de supprimer des fichiers d'un chemin et de ses sous-répertoires (filtrage par le temps) sans supprimer la structure du répertoire.

Et j'ai utilisé le format ci-dessous qui a fonctionné pour moi.

find / test123 / home / test_file_hip / data / nfs -mtime +6 -type f -exec rm {} \;

Syntex: find (chemin du fichier) -mtime (supérieur ou inférieur à jours) -type f -exec rm {} \;

-type: mentionner le type de fichier "f" pour le répertoire "d" -exec: exécuter la commande rm: supprimer {}: sortie de la commande find

Remarque: testez-le avant de l'utiliser. N'hésitez pas à corriger ou à mettre à jour si j'ai raté quelque chose.

— rohit
source

1

étant donné qu'il s'agit d'une exigence supplémentaire qui n'a pas été mentionnée par le PO et que la find ... rmstructure de base a déjà été couverte, je ne suis pas sûr que ce soit une contribution précieuse en tant que nouvelle réponse à cette question.

— Jeff Schaller