Bienvenue sur PEBKAC.fr, le site qui recense les anecdotes où l’on se moque des utilisateurs ne maîtrisant pas l’outil informatique. PEBKAC est un acronyme signifiant « Problem Exists Between Keyboard And Chair ».
Le problème se situe entre la chaise et le clavier : soumettez vos histoires, donnez votre avis !
Ce site n'est pas le site original pebkac.fr. Je publie ici la liste des PEBKAC que j'ai pu sauvegarder avant que le site original ne soit mis hors ligne.
Connecté en SSH à un serveur distant, je recherchais du texte dans un répertoire de façon récursive avec "grep" et l'option "-r".
Constatant qu'il y avait trop de résultats pour pouvoir les lire directement en console, je relance la même commande en dirigeant sa sortie vers un fichier... du répertoire dans lequel je cherchais, ce qui a eu pour effet de provoquer une jolie boucle infinie sur le serveur. PEBKAC.
PEBKAC #5507 proposé par neemzy le 15/09/2012 | 27 commentaires | 👍🏽 👎🏽 +213
Unix proprio ? C'est surtout un PEBKAC pour le développeur des findutils car sous Linux avec les findutils GNU ça fonctionne correctement.

grep -r test > test
grep: input file "test" is also the output
Commentaire #58751 écrit par jajajaj le 15/09/2012 à 15h57 | 👍🏽 👎🏽
Est-ce que ça peut être une question d'alias ? S'il existe une option pour prévenir, peut-être que sous Linux, la commande grep est redéfinie pour avoir l'option par défaut (si c'est p, on aurait alias grep='grep -p' dans un fichier système) alors que sous l'OS auquel se connecte neemzy, la commande agirait normalement ? Ça peut aussi être l'inverse (option pour ne pas prévenir).
Commentaire #58761 écrit par TD le 15/09/2012 à 17h41 | 👍🏽 👎🏽
@jajajaj :
"grep -r test > test"
euh... manque un truc dans ta commande, là tu recherches dans le fichier "test", mais tu recherches quoi ? Ou alors, tu recherches "test", mais où ?

Essai plutôt un truc du genre : grep -r "a" dossier > dossier/resultat
Si "dossier" contient plein de fichiers qui contiennent "a", alors tu verras que ton fichier "resultat" va vite faire plusieurs Go.
Commentaire #58779 écrit par juu le 15/09/2012 à 20h23 | 👍🏽 👎🏽
@juu Ben je confirme que ça ce comporte toujours normalement (pas de boucle).

Dans ma commande originale j'était dans mon home, je cherchait donc test (qui apparaît dans des dizaines de fichiers de config de programmes) de façon récursive (-r) dans le répertoire courant (implicite) et redirigeait la sortie dans le fichier "test" du même répertoire.

Maintenant je fait ce que tu propose, je me place à la racine et cherche "host" dans /etc (où il apparaît dans des dizaines de fichiers) et redirige la sortie dans /etc/grep_result:

[root@frost:pts/1] [/] # grep -r host etc > /etc/grep_result
grep: input file "etc/grep_result" is also the output

À noter que la commande n'échoue pas bêtement, /etc/grep_result contient bien le résultat de la "recherche", sauf bien sûr les références à lui-même.
Commentaire #58786 écrit par jajajaj le 15/09/2012 à 23h34 | 👍🏽 👎🏽
J'ai oublié de préciser :

grep -V
grep (GNU grep) 2.14
Copyright (c) 2012 Free Software Foundation, Inc.
Licence GPLv3+: GNU GPL version 3 ou ultérieure <http://gnu.org/licenses/gpl.html>.
Logiciel libre : vous êtes libre de le modifier ou de le redistribuer.
Il n'y a AUCUNE GARANTIE, dans les limites autorisées par la loi.

Conçu par Mike Haertel et pour les autres, voir <http://git.sv.gnu.org/cgit/grep.git/tree/AUTHORS>.
Commentaire #58787 écrit par jajajaj le 15/09/2012 à 23h36 | 👍🏽 👎🏽
Ctrl c... Ca ne vaut pas un pebkac...
Commentaire #58793 écrit par Ctrl c le 16/09/2012 à 00h55 | 👍🏽 👎🏽
Ben en fait, c'est bizarre... Aujourd'hui, même un bon vieux "rm -rf /" en root, ça ne fonctionne pas...

Toutes les commandes sous Linux sont maintenant protégés contre la maladresse de certains admins, et du coup, faire des boucles infinis aussi simplement que ça... C'est plus possible. (sous RedHat/Fedora/CentOS en tout cas... Je ne me suis pas amusé avec les autres distribs depuis très longtemps, et j'avoue que ça ne m'intéresse pas plus que ça... )

Ceci dit, je ne connais pas du tout BSD, la dernière fois que j'ai bossé sous UNIX, c'était sur du DEC ALPHA et des stations SUN (Ultra Spark) ... Autant dire que ça remonte à très très loin... Et que le truc sous windows où il y a un shell (oui ça existe avec la version Ultimate je crois...), je l'ai installé, mais jamais testé... Donc je ne peux pas en parler...


Mais dans tous les cas, comme l'a si bien dit @Jajaja, la faute incombe surtout aux développeurs...
Commentaire #58801 écrit par Arafel le 16/09/2012 à 09h12 | 👍🏽 👎🏽
Pour le "rm -rf /" en root ça bloque jusque parce que "/" n'est pas un vrai répertoire ?
Un "rm -rf /*" ça fonctionne ?
(Note pour noob : ne pas tester sauf si vous être sûr à 100% que sur votre distrib ça ne fera rien ou que vous êtes dans une machine virtuelle juste créée pour ça).
Commentaire #58819 écrit par Macaque le 16/09/2012 à 11h29 | 👍🏽 👎🏽
Note inutile, la sélection naturelle a aussi lieu en informatique x)
Commentaire #58820 écrit par mini le 16/09/2012 à 11h56 | 👍🏽 👎🏽
<supprimé>
Commentaire #58821 écrit par BSK le 16/09/2012 à 11h57 | 👍🏽 👎🏽
Ce n'est pas que « / » n'est pas un vrai répertoire, c'est qu'il y a une protection dans « rm » (on peut l'enlever avec l'option « --no-preserve-root »). « rm -rf /* » fonctionne par contre, mais ça présente moins de risques, le principal danger de « rm -rf / » étant que l'on peut mettre un espace en trop dans un chemin absolu (du genre « rm -rf / home/... »).
Commentaire #58822 écrit par BSK le 16/09/2012 à 11h59 | 👍🏽 👎🏽
Qui est-ce qui a fait rm sur le commentaire de BSK?!
Commentaire #58832 écrit par ROB le 16/09/2012 à 17h30 | 👍🏽 👎🏽
rm -rf /BSK/*
Commentaire #58833 écrit par Arafel le 16/09/2012 à 17h48 | 👍🏽 👎🏽
Donc il y a bien différence, la même commande a bouclé sur avec mon grep version 2.6.3
Si je ne dis pas de bêtise, ça doit détecter dans la version 2.10
Commentaire #58836 écrit par juu le 16/09/2012 à 19h58 | 👍🏽 👎🏽
find : "Assassin !!"
Commentaire #58837 écrit par mini le 16/09/2012 à 20h48 | 👍🏽 👎🏽
C'est moi qui ai effacé mon propre post car il n'était pas au bon endroit. C'est pour ça qu'il y en a un autre de moi juste au dessus écrit deux minutes plus tard.

@Arafel : « cp -Tr /BSK.2012-09-15.bak /BSK »
Commentaire #58838 écrit par BSK le 16/09/2012 à 21h08 | 👍🏽 👎🏽
Il y a pourtant un (gros) risque avec « rm -rf /* ».

Je connais quelqu'un qui a effacé entièrement un serveur (de test, heureusement) de cette manière il n'y a pas si longtemps. Il voulait faire « rm -rf ./* » (pour sa presque-défense, il travaillait à l'époque presque exclusivement sur Windows...)
Commentaire #58848 écrit par Morrock le 17/09/2012 à 00h47 | 👍🏽 👎🏽
Sparc!
Commentaire #58851 écrit par Spark? le 17/09/2012 à 07h30 | 👍🏽 👎🏽
Alors, pour les sceptiques, le serveur en question tourne sur une Release OVH 2 (double PEBKAC, j'ai pas choisi), en d'autres termes une vieille Gentoo plutôt dépassée : ceci explique probablement cela.

La commande exacte était grep -rl "ma recherche" . > test ;-)
Commentaire #58855 écrit par neemzy le 17/09/2012 à 09h14 | 👍🏽 👎🏽
J'était pas sceptique je demandait si c'était un Unix proprio, mais OVH Gentoo est une réponse tout à fait acceptable beurk.

Pour info j'ai fait mes tests sur une Gentoo normale.
Commentaire #58861 écrit par jajajaj le 17/09/2012 à 11h54 | 👍🏽 👎🏽
Oui oui, je voulais pas dire sceptique dans le sens "puisque vous me traitez de mythomanes, bande de moules, voici l'explication" (et pas dans le sens de la fosse non plus, oeuf corse). Justement, je dois dire que j'ai jamais fait la même bourde ailleurs, donc j'ignorais totalement qu'elle n'est pas censée être réalisable. En fait, j'ai mal choisi mon terme. Diantre.

Je plussoie le "beurk", j'aime bien OVH mais là... ce serait trop long et trop peu discret de détailler toutes les embrouilles liées à ce serveur, mais disons simplement que plus de trente minutes pour réussir à installer Git ou SVN ça frise le ridicule (et encore, je suis gentil, non ?)
Commentaire #58875 écrit par neemzy le 17/09/2012 à 16h53 | 👍🏽 👎🏽
Essayé à l'instant sous Debian stable (GNU grep 2.6.3) dans mon répertoire home : "grep -r test . > essai"
Le processus ne s'arrête pas et le fichier "essai" grossit en permanence.
Commentaire #58890 écrit par Nono le 17/09/2012 à 18h00 | 👍🏽 👎🏽
Une recherche, c'est normal que ça prenne longtemps. Surtout quand tu vois pas la progression (vu que tout passe dans le fichier). Du coup le temps que tu te rendes comptes qu'il y a vraiment un problème, t'auras quand même bien mobilisé ton serveur.
Commentaire #58927 écrit par Loki le 17/09/2012 à 22h09 | 👍🏽 👎🏽
mini si tu es sous bash avec l'expansion des ! tu risques de te retrouver avec une belle erreur ;)
Commentaire #58944 écrit par Noraa le 18/09/2012 à 00h53 | 👍🏽 👎🏽
Bon en même temps avec les ':' j'aurais pu me douter que ce n'était pas une commande... Ou alors une syntaxe que je ne connais pas? En tout cas je penserais à réfléchir avant de commenter la prochaine fois :-/
Commentaire #58945 écrit par Noraa le 18/09/2012 à 00h56 | 👍🏽 👎🏽
loin d'être un PEBKAC, je ne vois pas comment tu peux arriver sur une boucle infinie... le fichier de sortie n'est pas reparsé à chaque fois qu'il est modifié !! non mais
Commentaire #58999 écrit par Carbon le 18/09/2012 à 13h37 | 👍🏽 👎🏽
Et pourtant... @Nono comme moi avons bel et bien rencontré ce cas de figure :p
Commentaire #59111 écrit par neemzy le 19/09/2012 à 13h55 | 👍🏽 👎🏽