Vacances de la déduction : petit exercice "holmésien"
Salut
Lutins.
Pour passer avec succès la commande :
sudo trimforce enable dans le «
Terminal» (de manière à activer le
TRIM sur un SSD tiers selon le nouveau procédé ©Apple), il faut que 2 ressources soient présentes
a priori dans l'OS :
-a) le binaire UNIX trimforce à l'adresse : /usr/bin/trimforce
- b) l'original de la nouvelle extension du noyau dédiée au TRIM sur SSD tiers à l'adresse : /System/Library/Filesystems/AppleDataSetManagement.kext
Je t'invite à faire cette vérification en mode graphique, en pressant dans le
Finder la combinaison de touches :
⌘⇧G (
cmd maj G) qui commande l'affichage du panneau "
Aller à..." pour coller dans le champ de saisie l'adresse :
et presse le bouton "
Aller" --> une fenêtre s'ouvre, affichant l'espace du dossier invisible
bin dans le répertoire
usr --> vérifie si, à la lettre
T, tu tombes bien sur l'icône rectangulaire anthracite (avec un petit
exec vert inscrit) du binaire :
trimforce.
Ferme la fenêtre et ressaisis la combinaison de touches
⌘⇧G pour coller dans le champ de saisie l'adresse :
Bloc de code:
/Système/Bibliothèque/Filesystems
et presse le bouton "
Aller" --> une fenêtre s'ouvre derechef, affichant l'espace du dossier
Filesystems relevant de la
Bibliothèque-Système de l'OS --> vérifie si tu vois bien l'objet :
AppleDataSetManagement.kext qui est l'original de l'extension, dont la commande :
sudo trimforce enable se borne à effectuer une copie conforme dans le dossier
/System/Library/Extensions afin qu'elle soit injectée dans le
kernel au démarrage et que le
TRIM soit donc pris en charge sur un SSD tiers.
--------------------
A priori, ton OS installé étant la version : «
Yosemite 10.10.5», les 2 ressources que je viens d'évoquer sont nécessairement présentes à leurs emplacements règlementaires (ce que tu as dû vérifier) et, par suite, la commande :
sudo trimforce enable devrait s'exécuter sans obstacle dans le «
Terminal», puisque son outil (le programme
trimforce) et son objet (l'original
AppleDataSetManagement.kext) existent dans l'OS.
Et pourtant ta commande achoppe, avec le message en retour :
Bloc de code:
sudo: trimforce: "command not found"
ce qui constitue un joli petit problème. Procédons par élimination : le blocage ne peut pas provenir de ce que tu n'aurais pas le droit de passer une commande
sudo, étant dans une session
standard, parce que dans ce cas tu obtiendrais le message en retour :
Bloc de code:
Sorry, user lutins14 [ton username] is not allowed to execute '/usr/bin/trimforce enable' as root on MacBook Pro.
Le blocage ne peut pas provenir de l'absence de l'objet de références (
/System/Library/Filesystems/AppleDataSetManagement.kext), parce que tu obtiendrais un message en retour du style :
Bloc de code:
/System/Library/Filesystems/AppleDataSetManagement.kext: No such file or directory
Reste un blocage concernant l'outil invoqué par la commande, ce que le message :
Bloc de code:
trimforce: "command not found"
paraît bien spécifiquement pointer : impossibilité d'exécuter la commande, car le programme invoqué
trimforce n'est pas trouvé. Or, étant sous «
Yosemite 10.10.5», le programme
trimforce doit forcément exister à son adresse de référence : /
usr/bin/trimforce ; et ta recherche dans le panneau "
Aller à..." du
Finder a dû te confirmer la présence de ce binaire à l'endroit attendu. Alors ?
--------------------
Alors je ne vois qu'une explication à tes déboires : ce qui permet à un utilisateur d'invoquer directement, en en-tête de commandes dans le «
Terminal», tel ou tel binaire
UNIX fourni nativement dans
OS X sans faire précéder cette citation du programme par son adresse dans tel ou tel autre "répertoire à binaires" du Système, c'est l'effet de raccourci produit par ce qu'on appelle la
variable d'environnement $PATH qui recèle la liste des adresses aux "dossiers à binaires", chacune séparée de la suivante par un "
:", constituant le domaine inclusif des programmes directement invocables par l'utilisateur sans adresse spécifique. Il suffit que le binaire invoqué soit présent dans un des dossiers référencés par la variable
$PATH pour qu'il soit trouvé et son action commandée.
Je conjecture que le répertoire à binaires
/usr/bin (pour une raison que j'ignore) ne fait pas partie de la liste d'adresses de référence de ta variable d'environnement
$PATH, ce qui fait que, quand tu l'invoques
ex abrupto dans le «
Terminal», il n'est pas trouvé. Première vérification de cette conjecture --> fais dans le «
Terminal» un copier-coller direct de la commande :
Bloc de code:
sudo /usr/bin/trimforce enable
et ↩︎ --> logiquement, le binaire
trimforce devant être présent à l'adresse indiquée («
Yosemite 10.10.5» oblige) et l'adresse absolue à ce programme étant mentionnée (
/usr/bin/trimforce), plus question de "
command not found" mais --> une demande de
password (commande
sudo) --> tape ton mot-de-passe
admin à l'aveugle - aucun caractère ne se montrant à la frappe - et derechef ↩︎ --> après re-démarrage de ta bécane, le
TRIM devrait être activé sur ton SSD (vérification dans les
Infos Système de "
À propos de ce Mac").
Contre-vérification : dans le «
Terminal», tu saisis ce coup-ci :
et ↩︎ --> cette commande demande l'affichage "en écho" de la liste d'adresses spécifique de ta
variable d'environnement $PATH. Voici par exemple la mienne :
Bloc de code:
/opt/local/bin:/opt/local/sbin:/usr/local/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/X11/bin:/Applications/Server.app/Contents/ServerRoot/usr/bin:/Applications/Server.app/Contents/ServerRoot/usr/sbin:/usr/texbin
--> tu noteras que l'agglutination des adresses à la
queue-leu-leu avec pour simple séparatif le "
:" ne rend pas la séquence très lisible. Mais focalise-toi à la lecture sur les "
:" comme marquant des séparateurs absolus, ce qui te permettra de "scander" ta lecture. Si tu inspectes la liste de ma
$PATH, tu noteras à la 4è place l'adresse
:/usr/bin: où se trouve précisément contenu le binaire
trimforce. Je n'ai par suite aucun problème à invoquer
trimforce en direct dans le «
Terminal», puisque le dossier qui contient ce binaire fait partie du domaine de référence de mes invocations possibles sans adresse obligée (ce qui est fort commode, tu le reconnaîtras : qui se souviendrait de toutes les adresses spéciales de tous les binaires invocables ?). Si tu inspectes la liste de ta
$PATH - eh bien ! tu ne devrais voir nulle part l'adresse :
:/usr/bin: ce qui expliquerait que le programme invoqué dans la commande ne soit pas trouvé "automatiquement" quand tu te bornes à l'énoncé simple de son nom.
Si ma conjecture est exacte, tu peux éditer ta
variable d'environnement $PATH de manière à inclure dans la liste de ses adresses de répertoires à binaires le :
/usr/bin. Il existe plusieurs procédés plus ou moins commodes pour cette édition --> je te propose le plus simple, qui consiste à créer un fichier mentionnant l'adresse
/usr/bin dans le dossier invisible :
/etc/path.d ce qui rendra l'adresse en question valide pour la variable
$PATH de tous les utilisateurs possibles de l'OS. Fais donc un copier-coller dans la fenêtre du «
Terminal» de :
Bloc de code:
sudo -s 'echo "/usr/bin" > /etc/paths.d/bin'
et ↩︎ -->
password à l'aveugle et ↩︎ -->
re-démarre impérativement ton Mac pour que la nouvelle ressource soit chargée par le Système et retourné dans ta session, si tu repasses dans le «
Terminal» un :
tu devrais ce coup-ci voir mentionné à un point donné de la chaîne d'adresses -->
:/usr/bin:
[NB. S'il s'avérait qu'une des 2 ressources précitées (trimforce ou AppleDataSetManagement.kext) manquât à l'adresse de référence de l'OS --> une application de la ☞OS X Yosemite 10.10.5 Combo Update☜ ou carrément une "Ré-installation d'OS X" à partir d'un démarrage sur la partition de récupération «Recovery HD» règlerait le problème en restaurant les ressources déficientes...]