[gull] Commande pour supprimer un espace final dans des noms de dossiers

[Guy Maurer]

Bonjour,

Avez-vous essayer les options -depth (qui process les contenu des dir
avant la dir) ou -prune ?

Guy Maurer

Le 10. 02. 16 10:47, Samuel Chenal a écrit :
> Hello !
>
> Nous sommes en phase de migration Mac > Windows chez un client. Le
> serveur Mac passe sous Debian et les postes clients Mac passent sous
> Windows.
>
> Le serveur de fichiers contient toute une arborescence. Nous avons
> remarqué que certains dossiers étaient "hachés" dans l'explorateur
> Windows alors que sous Mac (ou linux), on les voyait en clair :
>
> CAQKCF~K au lieu de CarneiroModesto_RME
>
> On s'est rendu compte que ces dossiers avaient un espace à la fin. Mac
> le cache, linux le montre mais le gère bien et Windows hache le nom du
> dossier...
>
> Le but était de trouver une commande pour virer ce dernier caractère. La
> commande :
>
> find . -type d -iname "* "
>
> ... m'a donné plusieurs centaines de dossiers dans ce cas.
>
> J'ai construit la commande suivante :
>
> find . -type d -iname "* " -exec rename -v 's/\ $//g' {} \;
>
> ... qui semble bien fonctionner. Il faut cependant la lancer plusieurs fois.
>
> En effet, j'ai l'impression que le find s'exécute pour toute
> l'arborescence et ensuite, il lance le -exec. Et comme certains dossiers
> sont modifiés par le rename, le -exec ne peut plus accéder aux
> sous-dossiers fautifs pour les renommer.
>
> C'est effectivement comme ça que fonctionne le find ? Y aurait-il un
> autre méthode plus efficace ?
>
> Merci d'avance pour vos avis.
>
> a+
>
> Samuel
>
>
>
> _______________________________________________
> gull mailing list
> gull at forum.linux-gull.ch
> http://forum.linux-gull.ch/mailman/listinfo/gull


-- 
MAURER DATA Sarl
Guy Maurer, Dr physicien
Ch. des Sapins 16  (Renumerotation de la rue)
CH-1170 Aubonne
Phone ++41 (0)21 831 0300, Fax (hors service)

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://forum.linux-gull.ch/pipermail/gull/attachments/20160210/eb09b3ab/attachment-0001.html>