Salut
Nailik.
Au risque que tu me trouves un tantinet verbeux dans ce billet, permets-moi d'essayer d'éclairer quelque peu ta lanterne sur la commande
rm et les erreurs que tu as commises dans son exécution.
La commande
rm dans le «
Terminal» lance l'utilitaire
UNIX éponyme
rm situé dans le répertoire
/bin de l'OS (répertoire invisible au
Finder recelant une série d'exécutables invocables en ligne de commande). L'intitulé de cet utilitaire
rm abrège le mot anglais
remove (supprimer) - ce qui décrit la fonction exclusive de cet exécutable : supprimer les objets logiques qu'on lui indique. De toutes les commandes qu'on peut passer dans le «
Terminal», c'est la plus risquée de par cette fonction suppressive de l'utilitaire invoqué.
Quand on invoque l'utilitaire
rm avec l'option double
-rf, cela signifie qu'on adjoint à sa fonction suppressive une modalité
récursive (
r), qui signifie : exercer la fonction suppressive sur toute la profondeur d'arborescence logique de la cible (exemple : si la cible est un dossier contenant des fichiers, alors la suppression affectera l'enveloppe du dossier avec tout son contenu inclus) ; et qu'on adjoint une modalité d'action
forcée (
f), qui signifie : exécuter la suppression sans demande de confirmation adressée à l'utilisateur quel que soit l'objet-cible (autant dire : exécution à l'aveugle).
sudo en tête de commande invoque l'utilitaire éponyme dont l'intitulé est l'abrégé de "
Substitute User DO" : Opérer en qualité d'utilisateur substitué. Cet utilitaire permet à un utilisateur d'emprunter une autre identité d'utilisateur que la sienne pour passer une commande. Lorsque aucun nom d'utilisateur précis n'est renseigné, c'est automatiquement le
Super-User root (
System Administrator) qui se trouve convoqué par défaut comme maître opérateur de la commande qui suit. Une authentification par mot-de-passe
admin est requise dans tous les cas de figure lorsque
sudo est invoqué en tête d'une commande.
Donc, inscrivant comme départ de ligne de commande :
tu te retrouves en train d'invoquer l'utilitaire de suppression
rm en droits
root, ce en mode
récursif et
forcé - autant dire que as entre les mains sans le savoir un sacré
bazooka chargé. Le tout est de savoir régler le tir à la cible, sinon ça peut être dévastateur.
Dans une commande
rm, la cible (l'objet de la suppression) consiste, logiquement parlant, dans ce qui est libellé à partir de la barre oblique
/ qui désigne le point-de-montage du système de fichiers démarré de l'OS (autant dire : le point racine de son organisation logique, constituée par une arborescence descendante de dossiers/sous-dossiers/fichiers). C'est ce qu'on appelle un "chemin logique". La règle
sine qua non est que, à partir de la mention initiale de la barre oblique
/ qui désigne donc le point de départ absolu du système de fichiers monté de l'OS, tout
libellé continu d'un chemin
sans espace libre est «
suivi » jusqu'au dernier terme, qui est interprété comme étant l'objet-cible ; mais, si un
espace-libre intervient qui casse la
continuité du libellé du chemin, alors l'objet mentionné juste
avant l'espace libre est interprété comme la cible n°1 de la commande ; et ce qui commence
à partir de l'espace libre est interprété comme chemin à une cible n°2 de la commande et etc. pour autant d'espaces libres qu'il en existe dans le libellé de chemin. Si les désignations de cibles dans un tel libellé morcelé par des espaces libres ne font pas sens (aucun objet trouvé correspondant), alors ces mentions sont "échappées" (à cause de l'option
-f : passage en force sans demande de confirmation ni arrêt en cas d'échec local) et la désignation suivante envisagée et exécutée si elle correspond à un objet trouvé.
--------------------
Tu dois me trouver bien bavard, mais c'est pour essayer de te faire comprendre le caractère désastreux des commandes que tu as passées, telles que tu les redonnes ci-dessus, à cause de l'intervention fatale d'
espaces libres qui n'auraient pas dû exister dans la désignation des cibles de la commande
sudo rm -rf. Je t'analyse la première commande que tu as passée (un véritable cauchemar logique pour ne serait-ce qu'un simple utilisateur avisé du «
Terminal») :
Bloc de code:
sudo rm -rf / Library / Application\ Support / Adobe
cette commande équivaut à avoir ciblé l'action suppressive de l'utilitaire
rm (exercée en droits
root) sur la série suivante de cibles (
séparées par des espaces libres) :
/ => tout ce qui suit le point de montage de l'OS, soit toute l'arborescence de ses dossiers et sous-dossiers ;
Library => comme tu es automatiquement loggé, en tant qu'opérateur dans le «Terminal», à la racine de ton dossier de compte d'utilisateur, Library désigne donc directement, sans chemin précurseur, ta Bibliothèque personnelle de compte que tu as ainsi désignée en 2è position à la suppression de rm ;
/ => la barre / remise entre entre 2 espaces libres désigne en 3è cible derechef tout ce qui suit le point de montage absolu du système de fichiers de l'OS démarré (reprise de la 1ère désignation de cible /) ;
Application => sans "s" à la fin n'est pas interprété comme un objet valide et est donc échappé ; idem pour Support entre 2 espaces libres ; idem pour Adobe
« Heureusement » pour toi (si l'on peut dire), le démarrage de l'OS «
El Capitan» est protégé a priori par un protocole de sécurité intitulé le
SIP (
System Integrity Protection), qui verrouille y compris
contre l'autorité de
root (le
System Administrator) les répertoires critiques suivants :
/System/Library (la
Bibliothèque-Système),
/bin (dossier d'utilitaires UNIX),
/sbin (idem),
/usr (idem). La commande
sudo rm -rf exécutée sur
/ (tout ce qui suit le point de montage du système de fichiers de l'OS) a donc
respecté les 4 répertoires susdits, dont la
Bibliothèque-Système recelant le cache de démarrage
prelinkedkernel de l'OS et les
extensions du noyau injectables dans le
kernel => une esquisse de démarrage s'exécute donc lorsque tu re-démarres ton Mac.
Par contre, les répertoires suivants n'étaient
pas protégés contre une suppression en droits
root :
/Applications (le répertoire des
applications) ;
/Library (la
Bibliothèque-Générale de l'OS) ;
/private (un super-répertoire invisible au
Finder contenant notamment les sous-dossiers
/etc et
/var absolument décisifs pour le chargement de l'OS) ;
/Users (le répertoire des
Utilisateurs contenant les dossiers de comptes des utilisateurs, dont le tien avec tes données et réglages).
La simple exécution de la commande
sudo rm -rf sur
/ isolé du reste par un
espace libre a donc suffi à dévaster le système de fichiers de ton OS de ses
applications,
bibliothèque-générale,
dossiers de comptes d'utilisateurs (dont le tien) et de tous les fichiers de
pilotages et de
bases-de-données du répertoire
/private. Tu pourrais certes restaurer ton OS à partir de la «
Recovery HD», mais sans pouvoir par là récupérer tes données d'utilisateur, puisque ton dossier de compte a été supprimé. Si tu veux récupérer tes données, en l'absence de sauvegarde, tu n'as pas d'autre solution que d'employer un logiciel de récupération de données.
Seule la commande bien tempérée :
Bloc de code:
sudo rm -rf /Library/Application\ Support/Adobe
aurait fait sens, car l'absence d'
espaces libres aurait permis au chemin
/Library/Application\ Support/ d'être suivi (parcouru) sans arrêt jusqu'à la seule cible = l'objet terminal
Adobe [NB. le dossier intitulé en 2 mots : Application Support se trouve rédigé : Application\ Support afin que l'espace libre séparant les 2 mots de l'intitulé ne casse pas le parcours du chemin, la barre oblique inverse \ ayant pour effet d'« échapper » l'espace libre qui la suit].
[Je n'analyse pas la série des autres commandes que tu as listées : si tu me passes une franchise un peu rude, la multiplication insensée des
espaces libres dans la désignation du chemin à l'objet-cible en fait un total « n'importe quoi » qui aurait été désastreux à son échelle, si le mal n'avait pas déjà été accompli par les inconséquences de la commande initiale...]
--------------------
Mais (par chance pour toi), lorsque la commande
rm s'exécute sur des objets logiques (càd. des suites d'écritures sur des séries continues de
blocs du disque), ce qui est supprimé, ce ne sont pas les "états" d'écriture correspondant à des fichiers et s'étalant sur une série continue de
n blocs chaque fois, mais seulement le
titre du fichier résidant chaque fois sur le
bloc de tête de la série. La suppression du titre du fichier étant interprétée comme une
libération des blocs qui suivent à fin de sur-écriture ultérieure. Donc : tant qu'il n'y a pas sur-écriture des
blocs qui ont perdu leur en-tête porteur du titre pour chaque fichier, un logiciel de scan des
blocs peut identifer des séquences continues d'écritures sans titre et les restituer en les interprétant.
Tu mis un SSD dans ton
MacBook Pro_2009 et tu as dû activer le
TRIM à destination de ce disque. Cette fonctionnalité ressemble à un passage d'éponge sur les écritures d'un tableau noir marquées comme "à effacer", ce qui serait le cas avec toutes les écritures de ton SSD qui, à la suite de la commande
rm, ont perdu leurs titres de fichiers (càd. notamment tout ce qui concerne tes anciennes données), si tu pouvais lancer lancer ton OS. Mais, comme ce n'est pas le cas, et comme le
TRIM n'est pas activé à partir de la «
Recovery HD» (par l'opération d'une extension, mais seulement par la fonctionnalité
garbage_collector du
firmware du SSD, laquelle n'intervient que dans les moments de démarrage sans activité d'utilisateur) - tu devrais donc être protégé contre cet effacement des écritures libres sur les cellules du SSD.
Pour que tu essayes de retrouver le maximum de données récupérables, le mieux serait donc que tu connectes un DDE USB à ton Mac, que tu démarres sur la «
Recovery HD», dans son «
Utilitaire de Disque» que tu sélectionnes le disque physique global du DDE et le menu "
Effacer" qui va écrire une
Table de Partition GUID au disque du DDE et exporter un volume principal au format "
Mac OS étendu (journalisé). Cela fait, tu quittes l'«
Utilitaire de Disque» et tu actives la fonctionnalité "
Ré-installer OS X" à destination du volume de ton DDE. 2H de téléchargement de ressources d'installation + 20' d'installation : à la fin, tu pourras ouvrir une session neuve dans l'OS de ton DDE (tu pourras re-démarrer dessus avec "
alt" ultérieurement).
Il te faudra alors acheter et installer un logiciel de récupération de données, genre : ☞
Stellar Phœnix Mac Data Recovery☜ ou ☞
Data Rescue 4☜ et le faire s'exécuter à destination de ton SSD (avec création d'un dossier de récupération dans le volume de ton DDE). Après quoi, en re-démarrant sur la «
Recovery HD» avec ⌘R, tu pourrais re-déclencher la fonctionnalité : "
Ré-installer OS X" à destination du volume de l'OS de ton SSD.
[Note : si jamais tu avais activé le Chiffrement du volume de ton OS via «FileVault», je crains qu'aucun scan du disque ne puisse récupérer la moindre séquence d'écriture interprétable comme « pourvue de sens », càd. comme constituant une « donnée »...]
--------------------
