problème de séparateur

bonjour,
j'essaie comprendre ce qui est dit dans l'article ci-dessous
http://en.wikipedia.org/wiki/Xargs#cite_note-1

Notamment ceci

si on tape les commandes suivantes

Code:

---

1 2 3

touch important_file touch 'not important_file' find -name not\* | xargs rm

---

le comportement attendu (par les newbies) est l'effacement du fichier 'not important_file', MAIS le comportement REEL est l'effacement du fichier important_file (c'est quand même un comportement surprenant)

En fait la commande suivante apporte la solution (après avoir créé les fichiers en question par les commandes touch)

Code:

---

find -name not\* | tr \\n \\0 | xargs -0 rm

---

Donc, entre find et rm il y a conversion des \n en \0 dans le flux de sortie de find et ajout de l'option -0 dans xargs

Je vois bien que çà marche (encore une fois c'est surprenant), mais je ne sais pas EXACTEMENT pourquoi....le problème des séparateurs et (plus généralement) des commandes qui sont ou non orientées ligne me paraît complexe....je ne sais jamais quel est le caractère de fin de ligne
Pourriez vous me donner une explication sur l'exemple précédent ?
Merci d'avance

Code:

---

1 2 3 4 5 6 7 8 9 10

francois@trillian:~/tmp$ ls -lrth total 8,0K drwx------ 4 francois francois 4,0K 3 mai 20:35 myhello -rw-r--r-- 1 francois francois 968 3 mai 21:12 myhello.deb francois@trillian:~/tmp$ touch important_file francois@trillian:~/tmp$ touch 'not important_file' francois@trillian:~/tmp$ find -name "not\ *" -exec rm {} \; francois@trillian:~/tmp$ ls important_file myhello myhello.deb francois@trillian:~/tmp$

---

pourquoi ?

la protection de caractère "\\" en lien et place de "\" vient du fait qu'on traverse un tunnel "|" pour arriver à rm hors l'usage des "|" doit tjrs être réduit au minimum pour des raisons évidentes de temps de traitement, c'est pourquoi la vraie solution n'est absolument pas celle mentionnée mais bel et bien d'utiliser l'option exec de find comme je l'ai indiqué.

cependant cela ne m'explique pas pourquoi dans la solution non optimisée qui est proposée on change le caractère de fin de ligne \n en \0 avant d'exécuter la commande rm

Je pense que c'est parce que find ne protège pas ses résultats avec des guillemets, ce qui fait que la commande :

Code:

---

find -name not\* | xargs rm

---

équivaut en fait au final à :

Code:

---

rm not important_file

---

et non :

Code:

---

rm 'not important_file'

---

Ce qui supprime le fichier « not » et le fichier « important_file ». Comme le fichier « not » n'existe pas, seul « important_file » est supprimé. Ce qui montre les limites de find, et pourquoi il faut plutôt utiliser son option exec dans ce genre de cas.

Mais peut-être me trompé-je.

Pour les \n.

En fait la commande finale, que j'avais shématisée par :

Code:

---

rm not important_file

---

une fois interprétée serait plutôt quelque chose du genre :

Code:

---

1 2 3 4

rm <<EOF not important_file EOF

---

C'est imagé hein juste pour illustrer comment le shell passe les fichiers à rm. Le shell a par défaut comme séparateurs d'arguments l'espace la tabulation et le retour à la ligne. Il découpe donc le résultat de find, et convertit les espaces en retours à la ligne afin de délimiter ce qu'il donne à rm.

Donc le tr remet l'ensemble des arguments sur une seule ligne, puis xargs comvertit les \0 en espaces grâce à son option -0. Pour s'en convaincre :

Code:

---

1 2 3 4 5 6 7 8

> echo -e "foo\nbar" foo bar > echo -e "foo\nbar" | tr \\n \\0 foobar> > echo -e "foo\nbar" | tr \\n \\0 | xargs -0 echo foo bar >

---

Je ne suis pas tout à fait d'accord avec plusieurs infos des messages précédents, donc je vais donner mon point de vue ;) Et je vais également essayer de préciser certains points. A noter que dans tous les exemples ci-dessous, je ne présente pas à chaque fois la création des fichiers qui ont été éventuellement supprimés par une commande pour ne pas surcharger... mais je pars évidemment toujours de la même liste de fichiers (avec des fichiers en plus au dernier exemple).

1) Explication du non fonctionnement de find -name not\* | xargs rm.

Cette commande signifie comme vous le savez que la sortie standard de find est dirigée vers l'entrée standard de rm. Donc, cela revient à faire :

Code:

---

1 2	$ find -name not\* > test_rm $ xargs rm < test_rm

---

Or, si on fait ceci, qu'est ce qu'on constate ?

Code:

---

1 2 3 4 5

$ find -name not\* > test_rm $ cat test_rm ./not important_file $ xargs rm < test_rm rm: cannot remove `./not': No such file or directory

---

On constate que le fichier test_rm contient bien une seule ligne avec le nom du fichier qui nous intéresse.
Mais comme indiqué par FRUiT, ce nom comportant un espace, si on le passe tel quel à rm, cela revient à faire la commande suivante rm ./not important_file.
Dans ce cas, rm cherche effectivement à supprimer 2 fichier : "./not" et "important_file".


2) Que faire pour contourner le problème ?
1ère solution pour un cas simple, utiliser l'option de find -exec comme indiqué par frp31 !
2ème solution utile si exec ne permet pas de faire ce que l'on veut : utiliser proprement xargs ;)
Dans le cas de noms relativement simples comme ici, l'option -I{} de xargs permet de travailler proprement (anciennement option -i).

Citation:

---

-I replace-str
Replace occurrences of replace-str in the initial-arguments with names read from standard input. Also, unquoted blanks do not terminate input items; instead the separator is the newline character.
Implies -x and -L 1.

---

Cette option est intéressante à plus d'un titre : elle ne termine plus un argument avec un blanc qui ne serait pas protégé mais uniquement avec un saut à la ligne, et elle implique les options -x et -L1 qui signifie que xargs arrête son traitement si la taille de l'argument est trop important et que xargs utilise une seule ligne pour construire son argument à chaque fois.
Concrètement, voici une explication avec un exemple :

Code:

---

1 2 3 4 5 6 7 8 9

$ ll total 0 -rw-r--r-- 1 user users 0 May 19 09:24 important_file -rw-r--r-- 1 user users 0 May 19 09:29 not important_file -rw-r--r-- 1 user users 0 May 19 09:29 not very important $ find -name not\* > test_rm $ cat test_rm ./not very important ./not important_file

---

2.1) Premier cas avec xargs simple:

Code:

---

1 2 3 4 5 6 7 8 9 10

$ xargs rm < test_rm rm: cannot remove `./not': No such file or directory rm: cannot remove `very': No such file or directory rm: cannot remove `important': No such file or directory rm: cannot remove `./not': No such file or directory $ ll total 4 -rw-r--r-- 1 user users 0 May 19 09:29 not important_file -rw-r--r-- 1 user users 0 May 19 09:29 not very important -rw-r--r-- 1 user users 42 May 19 09:29 test_rm

---

On voit que les deux fichiers sont mis à la suite et que les espaces ne sont pas protégés > catastrophe !

2.2) Second cas avec l'option -I{}:

Code:

---

1 2 3 4 5

$ xargs -I{} rm {} < test_rm $ ll total 4 -rw-r--r-- 1 user users 0 May 19 09:39 important_file -rw-r--r-- 1 user users 42 May 19 09:29 test_rm

---

C'est bien mieux ;) les espaces ont été protégés et les fichiers correctement supprimés.

Mais il peut rester un problème avec cette option -I{} !

3) Le cas le plus compliqué qu'on verra ici : un nom de fichier comportant un saut de ligne ou des caractères spéciaux...

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

$ touch "not important_file at_all" $ touch "not important_file\\at_all" $ touch 'not "important"_file' $ ll total 4 -rw-r--r-- 1 user users 0 May 19 09:40 important_file -rw-r--r-- 1 user users 0 May 19 10:19 not "important"_file -rw-r--r-- 1 user users 0 May 19 10:21 not important_file\at_all -rw-r--r-- 1 user users 0 May 19 10:24 not important_file?at_all -rw-r--r-- 1 user users 72 May 19 10:21 test_rm $ find -name not\* > test_rm $ cat test_rm ./not important_file\at_all ./not important_file at_all ./not "important"_file $ xargs -I{} rm {} < test_rm rm: cannot remove `./not important_fileat_all': No such file or directory rm: cannot remove `./not important_file': No such file or directory rm: cannot remove `at_all': No such file or directory rm: cannot remove `./not important_file': No such file or directory

---

Voilà, on a encore le problème puisque cette fois-ci, xargs construit bien des arguments à partir de chaque ligne mais manque de pot, l'un des noms est sur deux lignes, un autre comporte des guillements qui vont passer à la trappe et même chose pour le backslash qui n'est pas échappé...
C'est là qu'intervient l'option -0 (c'est un zéro) de xargs :

Citation:

---

--null, -0
Input items are terminated by a null character instead of by whitespace, and the quotes and backslash are not special every character is taken literally). Disables the end of file string, which is treated like any other argument. Useful when input items might contain white space, quote marks, or backslashes. The GNU find -print0 option produces input suitable for this mode.

---

couplée généralement avec l'option -print0 de find :

Citation:

---

-print0
True; print the full file name on the standard output, followed by a null character (instead of the newline character that '-print' uses). This allows file names that contain newlines or other types of white space to be correctly interpreted by programs that process the find output. This option corresponds to the '-0' option of xargs.

---

En lisant, on voit clairement qu'elles ont été pensées l'une pour l'autre :ccool:

Ces deux options permettent, pour find, de séparer les différents noms trouvés par des caractères nulls plutôt que des sauts de ligne et pour xargs, de lire les arguments en découpant en suivant les caractères nulls au lieu des espaces (conséquence indirecte, les caractères spéciaux sont interprétés directement).

Code:

---

1 2 3 4 5 6 7 8 9 10

$ find -name not\* -print0 > test_rm $ cat test_rm ./not important_file\at_all./not important_file at_all./not "important"_file$# le shell reprend ici puisqu'il n'y a pas de saut de ligne à la fin du fichier mais un caractère null ! $ xargs -I{} -0 rm {} < test_rm $ ll total 4 -rw-r--r-- 1 user users 0 May 19 09:40 important_file -rw-r--r-- 1 user users 70 May 19 09:48 test_rm

---

Le comportement est bien celui attendu. Si on regarde le fichier intérmédiaire test_rm en détail:

Code:

---

1 2 3

$ cat test_rm | tr "\0" "|" ./not important_file\at_all|./not important_file at_all|./not "important"_file|

---

On voit clairement les 3 fichiers séparés ici par des "|" (j'ai utilisé tr pour bien mettre en évidence les caractères null en les remplaçant par des "|").
On voit également que le saut de ligne du fichier "not important_file at_all" est bien présent dans le fichier test_rm ! Et que c'est finalement le seul saut de ligne du fichier.

Et pour conclure, la solution suivante est à proscrire d'une manière générale :

Code:

---

1 2 3

$ find -name not\* | tr \\n \\0 | xargs -0 rm rm: cannot remove `at_all': No such file or directory rm: cannot remove `./not important_file': No such file or directory

---

En effet, elle va marcher quand les noms comportent uniquement des espaces (mais on a vu que l'option -I{} suffisait dans ce cas), mais pas quand le nom comporte un saut à la ligne ou d'autres caractères spéciaux puisque le tr va modifier le saut à la ligne du nom sans permettre de traiter les caractères spéciaux, et on va donc se retrouver exactement dans le même cas qu'avec l'utilisation de -I{} seul ;)
Il faut utiliser l'option -print0 de find qui fait le boulot correctement à la source.

Je ne sais pas si certains vont lire ça, mais j'espère que c'est clair :p

Oui mais la commande c'est un exemple didactique inventé par des professeurs que l'on croise dans plusieurs tutos de shell, c'est absolument pas une solution. Evidemment qu'en pratique personne ne ferait une chose pareille. C'est souvent le cas des exemples didactiques ils sont très shématiques et n'ont pas vocation à être utilisés réellement.

Syncope-nc veut juste une explication du comportement induit par cet exemple du tutoriel, pas une autre solution plus efficace pour pour supprimer un fichier avec espace, ce qu'à mon avis il sait faire. Enfin c'est que j'avais cru comprendre de son premier post.

Moi, en lisant son post, j'ai plutôt compris qu'il ne comprenait pas complètement ce qu'il se passait, et je pense que plutôt que de donner une explication avec un tr bancale au milieu, il vaudrait mieux donner une explication en détaillant précisément le comportement des différents programme, sans se restreindre en plus au cas particulier de l'espace :roll:

L'enchainement de commandes est la base même du fonctionnement des système Unix/Linux, donc c'est essentiel de comprendre parfaitement ce qui se passe !

D'où l'objet de mon message que j'ai voulu exhaustif.

J'aurais effectivement pu me contenter de répondre à sa question avec une réponse comme celle que je donne ci-dessous, mais je préfère l'explication complète qui, je le pense, apporte plus d'informations et est plus correcte.

Citation:

---

Envoyé par syncope_nc

cependant cela ne m'explique pas pourquoi dans la solution non optimisée qui est proposée on change le caractère de fin de ligne \n en \0 avant d'exécuter la commande rm

---

D'une part, on a un programme find qui retourne les résultats séparés par des sauts de lignes.
D'autre part, on a un programme xargs qui construit une liste d'argument séparés par des espaces (non protégés par des guillemets, des quotes ou des backslash) ou encore par des sauts à la ligne.

Citation:

---

xargs reads items from the standard input, delimited by blanks (which can be protected with double or single quotes or a backslash) or newlines

---

Donc si on a par exemple ces fichiers :

Code:

---

1 2 3 4 5

$ ll total 4 -rw-r--r-- 1 user users 0 May 19 09:40 important_file -rw-r--r-- 1 user users 0 May 19 11:20 not important_file -rw-r--r-- 1 user users 0 May 19 11:20 not important_file_at all

---

Un find peut renvoyer une liste sur 2 lignes:

Code:

---

1 2 3

$ find . -name not\* ./not important_file ./not important_file_at all

---

xargs va construire une liste d'argument séparés par des espaces ou des sauts de lignes, on peut le voir très clairement avec l'option -n :

Code:

---

1 2 3 4 5 6

$ find . -name not\* | xargs -n1 echo rm rm ./not rm important_file rm ./not rm important_file_at rm all

---

Cela montre bien que les espaces ne sont pas protégés et sont donc interprétés comme des séparateurs d'arguments.

En revanche, en utilisant l'option -0 de xargs combinée au tr, les noms retournés par find ne sont plus séparés par des sauts de lignes mais par des caractères nulls :

Code:

---

1 2	$ find . -name not\* | tr \\n \\0 ./not important_file./not important_file_at all

---

Ce qui permet d'utiliser xargs avec l'option -0 pour repérer les différents arguments par un caractère null uniquement :

Code:

---

1 2 3

$ find . -name not\* | tr \\n \\0 | xargs -n1 -0 echo rm rm ./not important_file rm ./not important_file_at all

---

On ne le voit pas ici à cause du echo, mais les espaces sont bien protégés dans ce cas, donc la même commande sans echo fera les rm demandés.

Citation:

---

Envoyé par Alek-C

Moi, en lisant son post, j'ai plutôt compris qu'il ne comprenait pas complètement ce qu'il se passait,

---

Ben oui, donc il faut lui expliquer ce qui se passe dans l'exemple et pas lui proposer une ou des solutions alternatives.

Citation:

---

Envoyé par Alek-C

et je pense que plutôt que de donner une explication avec un tr bancale au milieu,

---

Oui mais qu'importe, c'est dans l'exemple. As-tu lu son lien ? C'est un exemple célèbre en shell pour démontrer quelquechose aux newbies, et absolument pas une solution à prendre telle quelle. Peu importe que ce soit bancal ou qu'il y ait une meilleure solution au problème (tout aussi scabreux d'ailleurs mais encore une fois, peu importe)... Il faut faire un cours se basant sur cet exemple et pas autre chose.

Ceci dit je suis d'accord pour les détails et autres séparateurs.

Je pense que ton second message conviendra bien mieux à syncope, c'est d'ailleurs à peu de chose près ce que j'avais un peu plus maladroitement tenté d'expliquer aussi (plus schématiquement avec des foo et des bar).

Salut,

Citation:

---

Envoyé par syncope_nc

Je vois bien que çà marche (encore une fois c'est surprenant), mais je ne sais pas EXACTEMENT pourquoi....le problème des séparateurs et (plus généralement) des commandes qui sont ou non orientées ligne me paraît complexe....je ne sais jamais quel est le caractère de fin de ligne

Pourriez vous me donner une explication sur l'exemple précédent ?
Merci d'avance

---

Citation:

---

Envoyé par FRUiT

Syncope-nc veut juste une explication du comportement induit par cet exemple du tutoriel, pas une autre solution plus efficace pour pour supprimer un fichier avec espace, ce qu'à mon avis il sait faire. Enfin c'est que j'avais cru comprendre de son premier post.

---

Pour ma part je penserai comme Alek-C. Ce que je comprend c'est que syncope_nc veut comprendre le comportement induit par les différents caractères non-imprimables que sont entre autres les espaces, les fin de lignes et autres caractères séparateurs. Donc de ce point de vue, la réponse d'Alek-C me parait des plus pertinentes et riches en enseignements.

Je rajouterai juste pour ma part, une petite pirouette pour mieux interpréter visuellement et apprécier les exemples ci-dessous, notamment l'utilisation de "-print0" :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

$ ls important_file not important_file $ find . -type f -name "*" | cat -A ./not important_file$ ./important_file$ $ find . -type f -name "*" -print0 | cat -A ./not important_file^@./important_file^@$ $ find . -type f -name "*" | sed -n l ./not important_file$ ./important_file$ $ find . -type f -name "*" -print0 | sed -n l ./not important_file\000./important_file\000$

---

;)

Oui, j'aurais du utiliser cat -A dans mes exemples plutôt que cat, tu as parfaitement raison zipe31 ;)

Pour le reste, je laisse syncope_nc ou d'autres lire ce qu'ils veulent et en tirer les enseignements nécessaires.
Diffuser quelques bonnes pratiques n'ont jamais fait de mal :p surtout que je suis certain que nombreuses sont les personnes à ne pas connaitre ces détails de fonctionnement.

Citation:

---

Envoyé par Alek-C

Diffuser quelques bonnes pratiques n'ont jamais fait de mal :p surtout que je suis certain que nombreuses sont les personnes à ne pas connaitre ces détails de fonctionnement.

---

Ah mais j'ai jamais dit le contraire, j'ai même dit être d'accord avec ça.

Mais lui proposer l'option -exec (ou une autre solution viable) n'est pas ce qu'il attendait. En tout cas c'est mon avis et je le partage.

:)

Citation:

---

Envoyé par zipe31

Pour ma part je penserai comme Alek-C. Ce que je comprend c'est que syncope_nc veut comprendre le comportement induit par les différents caractères non-imprimables que sont entre autres les espaces, les fin de lignes et autres caractères séparateurs.

---

Moi ce que je comprends de ton message c'est que tu es d'accord avec moi, Syncope-nc ne cherche pas une autre solution mais une explication afin de mieux comprendre.

Citation:

---

Envoyé par zipe31

Donc de ce point de vue, la réponse d'Alek-C me parait des plus pertinentes et riches en enseignements.

---

Son premier message moi je le vois plus comme une proposition de solutions alternatives (fort bien expliquées du reste). Le deuxième en revanche est très bien oui.

je remercie notamment Alek-C pour ce cours très complet que j'ai lu ET RELU et que je conserverai pour le relire encore, après "décantation" dans mon esprit, dans quelques jours ou quelques semaines. Je remercie également tous les autres membres qui m'ont répondu et donné d'autres solutions: effectivement, ma démarche est de comprendre "sur le fond"; un newbie (même si je n'en suis plus tout à fait un) essaie toujours de demander aux autres le minimum sur un exemple précis pour ne pas "trop déranger", mais il espère à travers ce service minimum "gratuit" (donc inespéré) que la réponse sera la plus complète possible pour qu'il puisse avancer dans la compréhension des mécanismes subtils des commandes du shell.....donc évidemment, j'ai très apprécié toute cette discussion et les réponses très complètes qui me permettent de comprendre, et également tous les conseils sur les utilisations plus optimisées qu'il faut utiliser dans un contexte opérationnel....merci encore