@DonielF -r permet de supprimer récursivement les fichiers d'un répertoire. -f signifie "forcer", c'est-à-dire ne pas demander de confirmation, quelles que soient les autorisations d'un fichier donné. / est le répertoire racine du système de fichiers, ce qui signifie qu'il détruira tout et n'importe quoi, sauf peut-être certains fichiers spéciaux qui ne se comportent pas comme des fichiers ordinaires. De plus, vous aurez beaucoup de mal à trouver une commande brève qui fera planter votre système sans les autorisations Root / admin.

@GDP2 Ouch. [15]

Celle-ci est courante. Et rm va opter pour l'ordre alphabétique donc bin disparaîtra assez tôt, faisant échouer toute commande ultérieure. Notez également que $ sudo rm -rf * (effacer tout ce qui se trouve dans le répertoire courant) fera la même chose si vous avez fait auparavant cd / . Il est beaucoup plus fréquent d'échouer de cette façon, et de vider le contenu d'un répertoire que vous n'aviez pas l'intention de vider.

J'ai essayé rm -rf / il y a quelque temps, et rm dit que si vous voulez supprimer Root, alors utilisez tel ou tel drapeau. Aucune donnée n'a été perdue. Il semble qu'il y ait maintenant une protection de sécurité pour ne pas exécuter aveuglément rm -rf / .

D'après ce que j'ai compris, les versions modernes de MacOS sont "sans racine", ce qui permet d'éviter ce problème.

@alexy13 Cela ne se produit que sur les versions Linux de rm AFAIK. MacOS dispose de SIP qui (entre autres choses) vous empêche d'effacer le système d'exploitation par un utilisateur négligent. rm .

L'option --no-preserve-Root est requise depuis 2006 pour que le système fonctionne comme prévu.

La commande sudo rm -rf / a fait l'objet d'un message lorsque j'étais à l'université - il s'agissait d'un "nouveau" programme de chat..... Beaucoup se sont fait prendre... La plupart d'entre nous ont toujours fait une page de manuel pour vérifier les commandes avant de les mettre sur la ligne de commande.... apprendre rapidement !

-1 Ce que dit alexy13 : Cela ne fera PAS de dégâts aujourd'hui.

@DavidMulder votre commentaire n'est pas super clair mais je pense que je suis d'accord avec lui - que personne ne devrait dire que courir les rm ne fera pas de dommages irréversibles. C'est comme dire que c'est normal de pointer un pistolet chargé sur quelqu'un parce que la sécurité est enclenchée - c'est vrai que (le plus souvent) le pistolet ne tirera pas, mais l'intention de l'outil rm est de détruire ce qu'il pointe ; la sécurité étant dans le chemin, ce n'est pas une bonne idée de le pointer sur quelque chose d'important.

@Harv Personne ne parle d'utiliser réellement la commande, mais cette réponse est tout simplement incorrecte. La réponse fournit une commande qui ne fera rien d'autre qu'afficher une chaîne de caractères.

@DavidMulder oh je vois, vous dites que ma réponse ne montre qu'une chaîne de caractères. Ce n'est pas vrai sur tous les systèmes.

@Harv Sur quel système Mac OS cela n'est-il pas vrai ? Considérant que c'est l'Apple SE. Vous pourriez bien avoir raison, je ne suis pas un grand fan d'Apple.

@DavidMulder n'importe quel système avant l'introduction de SIP, qui je crois était 10.10 ou 10.11. Ces nouvelles fonctionnalités de protection des rm sont, à ma connaissance, les suivantes très nouveau, et donc dangereux pour les gens de penser que c'est sans danger de courir au hasard. Voir ici : support.apple.com/fr/HT204899

Ici Il y a un cas réel dans lequel cela s'est produit - un rm -rf vraiment similaire à un cas légal, qui a vraiment mal tourné :/

J'ai mal saisi les commandes 'find and remove' de sorte qu'elles trouvent tous les fichiers.

@mgarciaisaia et en voici un autre qui a fait l'objet d'une grande publicité à l'époque.

Je me souviens qu'il y avait un cas ici sur stackexchange avec une commande du genre rm -rf /${xyz} et par valeur accidentelle de $xyz était une chaîne vide - pas de chance car même le disque de sauvegarde était monté sur le système de fichiers local !

C'est très facile à faire par accident avec des variables indéfinies dans Bash. Quelque chose comme PROGDIR=/home/.local/removeme ; rm -rf ${PORGDIR}/* causera immense dommages très rapidement. Un exemple célèbre de cette situation est celui d'une société de logiciels bien connue : github.com/valvesoftware/steam-for-linux/issues/3671

Même avec SIP activé rm -rf / va encore essuyer /etc (et pratiquement tout ce qui se trouve en dessous /Users bien sûr). Le système ne tombera peut-être pas immédiatement en panne mais le prochain redémarrage sera sûrement intéressant...

@patrix rm -rf / est totalement inoffensif sous Linux et l'est depuis de nombreuses années. De plus, le Spécifications POSIX exigent que rm ne pas être capable d'effacer / de sorte que tous les systèmes compatibles POSIX le supporteront. Donc en fait, ce sont les versions BSD (et par extension MacOS) de rm avec lequel cela se produit et pas avec Linux.

@terdon Comme AD se concentre sur MacOS, etc., une discussion sur les fonctionnalités de la version Linux d'AD est nécessaire. rm semble plutôt étrange et peut donner aux utilisateurs l'impression qu'il est possible de jouer sans risque avec rm -rf / . Bien sûr, il ne supprimera pas / lui-même mais tout ce qui est supprimable en dessous (ce qui fera beaucoup de dégâts)

Vous pouvez utiliser rm -rf /* pour éviter --no-preserve-root avertissement.

@patrix Je suis tout à fait d'accord pour dire que ça semble étrange, mais bon, c'est toi qui as commencé ! :P Je répondais à ton commentaire qui prétendait faussement que rm -rf / est dangereux sous Linux. Bien sûr, ce n'est pas le lieu pour discuter de Linux, mais ce n'est pas une raison pour laisser traîner la désinformation.

La meilleure réponse jusqu'à présent, en affichant des commandes d'apparence légitime qui pourrait peuvent être le résultat d'une simple faute de frappe et peuvent pourtant entraîner des dommages importants.

"Maintenant j'ai le code assembleur dans mon programme.c" Non. Vous n'avez rien. La redirection a tronqué le fichier avant même que GCC ne l'ouvre.

C'est un exemple un peu artificiel. gcc -S program.c écrit l'asm dans program.s et non vers la sortie d'imprimante. (utiliser gcc a_function.c -O3 -S -o- | less si c'est ce que vous voulez). Comme le dit @nneonneo, le scénario le plus plausible est que vous voulez remplacer la fonction a.out nom par défaut de l'exécutable, et tabulation complète gcc program.c -o program.c . Mais lorsque cela se produit, il suffit de retourner dans votre éditeur et de réenregistrer le fichier, en supposant que vous l'ayez suspendu ou que vous ayez quitté l'éditeur au lieu de le quitter.

Avec gcc5.4, faire gcc program.c -o program.c donne gcc: fatal error: input file ‘program.c’ is the same as output file compilation terminated.

Oh mec, je suis vraiment heureux qu'ils aient ajouté cette amélioration de l'interface utilisateur dans GCC. Cela fait un moment que je n'ai pas fait de gaffe, mais c'est bien de voir que je serai un peu protégé la prochaine fois.

kernel_task n'est pas un processus normal. Il est immortel ; il ne peut pas être tué sauf par une erreur de sa part (et cela s'appellerait un KP et ferait tomber toute la machine). kernel_task Le PID de l'utilisateur est nominalement égal à 0, mais si vous fournissez cette valeur à la fonction kill(pid, sig) syscall, la page de manuel dit Si pid est égal à 0, alors sig est envoyé à chaque processus du groupe de processus du processus appelant. . Donc vous êtes tout simplement incapable d'envoyer kernel_task un signal.

@IwillnotexistIdonotexist Ouais, je me doutais que ce serait le cas ; merci pour l'info, cependant. C'est une bonne chose à garder à l'esprit.

Vous, de toutes les personnes, connaissez bien les dommages ln -sf peut faire... et comment s'en remettre :-)

@Josh : merci de le souligner. Et, dans le cas général, on devrait utiliser find -print0 | xargs -0 pour gérer en toute sécurité les caractères étranges dans les noms de fichiers.

Approuvé. Un autre conseil utile pour xargs : utiliser <whatever> | xargs echo <something> xargs est un excellent exemple de la raison pour laquelle le CLI est si puissant : vous pouvez opérer sur beaucoup, beaucoup d'éléments à la fois sans confirmation et sans avoir à vous débrouiller... assurez-vous simplement que vous lui dites de faire ce que vous voulez.