Ce fil a accroché mon attention dominicale (un peu tardivement, il est vrai) - en me posant deux questions :
pourquoi ? et
comment ?
C'est à
Logan (le créateur de ce fil)
que je pose candidement la question :
pourquoi ?
S'il s'agit bien de cacher l'icône du
Wi-Fi (le "menulet" Apple) qui apparaît dans la barre supérieure de menus du Finder (sans bien sûr désactiver la connexion
Wi-Fi) - pourquoi ce souhait (on va me trouver bien curieux : l'oisivité du dimanche) ? Personnellement, je trouve cet affichage bien pratique, en ce qu'un coup d'œil direct permet d'être sûr, à l'ouverture de session, ou au réveil du Mac après mise en veille, que la connexion
Wi-Fi est bien établie.
Serait-ce parce que trop d'icônes encombrent la partie droite de la barre de menus du Finder - des applications tierces ayant ajouté leurs menulets à ceux d'Apple ? S'il s'agissait d'une question de place - pourquoi alors ne pas utiliser une application comme «
Bartender» qui permet de masquer des menulets ou de les déplacer dans une barre de menus subalterne à celle du Finder et masquée par défaut ?
En l'absence d'un logiciel comme «
Bartender» - pourquoi encore souhaiter une
commande pour cacher l'icône du
Wi-Fi dans la barre de menus du Finder, alors que le panneau des
Préférences Systèmes >
Réseau >
Wi-Fi offre une case : "
Afficher l'état Wi-Fi dans la barre des menus" qu'on peut cocher vs décocher, avec un effet immédiat d'apparition vs disparition du menulet
Wi-Fi dans la barre des menus du Finder ? Bref : pourquoi vouloir une action en ligne de commande, quand une action graphique est à la disposition de l'utilisateur ?
♤
En laissant entre parenthèses ce «
pourquoi ? » (qui m'échappe) > j'ai trouvé la question «
comment ? » intéressante - ce qui me permet d'engager une conversation avec
bompi sur le plan technique.
Comme tu le signales :
- décocher la case "Afficher l'état Wi-Fi dans la barre des menus" du panneau des Préférences Systèmes > Réseau > Wi-Fi => affecte directement le fichier ~/Library/Preferences/com.apple.systemuiserver.plist en supprimant la chaîne : <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le tableau de la clé menuExtras.
- cocher la case "Afficher l'état Wi-Fi dans la barre des menus" dans le même panneau => recrée directement la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le tableau de la clé menuExtras du fichier plist.
--------------------
Ce constat m'a fait me demander : pourquoi la présence ou l'absence du menulet
Wi-Fi dans la barre de menus du Finder est-elle liée à une valeur (présente ou absente) dans ce fichier précisément : le
com.apple.systemuiserver.plist ? Il existe à la localisation
/System/Library/CoreServices une application
SystemUIServer.app qui n'est pas lançable ponctuellement en affichant une interface graphique ; mais qui, d'après le «
Moniteur d'activité», se trouve lancée avec le Système et dont le processus opère en toile de fond en continu.
Une petite recherche m'apprend que : «
The SystemUIServer is a background process that controls several aspects of the Mac OS X user interface, and is one of the applications that are constantly running, when viewed with the Activity Monitor. Specifically, it controls the right hand side of the Menu bar, where the Menu Extras live. The SystemUIServer is owned by the logged in user (as opposed to root) and automatically restarts if it crashes or is force quit. ».
J'en tire alors l'idée du mécanisme logique suivant : le processus
SystemUIServer doit consulter le fichier de préférence éponyme de la Bibliothèque de l'utilisateur connecté et, selon qu'il y a présence ou absence de la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le tableau de la clé
menuExtras > affiche ou masque le menulet
Wi-Fi dans la barre de menus supérieure du Finder.
--------------------
Le problème technique devient alors : par quel type de commande dans le «
Terminal» est-il possible soit de supprimer, soit de recréer la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le tableau
menuExtras du fichier
~/Library/Preferences/com.apple.systemuiserver.plist ?
La question m'intéresse, par son petit (très petit) côté "rétro-ingéniérie" : essayer de remonter de l'action graphique constatée (cocher / décocher la case dans le panneau
Wi-Fi des Préférences Système) à la commande en mode texte qui se trouve déclenchée par elle et qui a été implémentée par les ingénieurs de la .
De ce point de vue, je m'accorde avec ton constat :
ce qui complique un peu est que la la clef concernée, menuExtras, est de type tableau (array). On peut aisément lui ajouter une valeur mais pas lui en enlever une.
En cogitant un peu ce matin et en me livrant à diverses manipulations, si l'option "
Afficher l'état Wi-Fi dans la barre des menus" du panneau des
Préférences Systèmes >
Réseau >
Wi-Fi est décochée > donc la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> absente dans le tableau
menuExtras du fichier
~/Library/Preferences/com.apple.systemuiserver.plist > donc le menulet
Wi-Fi absent de la barre de menus du Finder => alors la commande :
Bloc de code:
defaults write com.apple.systemuiserver menuExtras -array-add "/System/Library/CoreServices/Menu Extras/AirPort.menu" ; killall SystemUIServer
recrée correctement la chaîne absente dans le fichier
plist et relance le processus
SystemUIServer > en conséquence de quoi la case "
Afficher l'état Wi-Fi dans la barre des menus" du panneau des
Préférences Systèmes >
Réseau >
Wi-Fi apparaît
re-cochée et le menulet
Wi-Fi se trouve
affiché dans la barre de menus du Finder.
La commande
defaults (comme tu l'avais prévu) permet bien de recréer la chaîne absente. Le malheur, c'est aussi comme tu l'as remarqué qu'elle ne comporte pas une option inverse de l'option
-array-add qui serait une
-array-delete (je me demande d'ailleurs bien pourquoi). Or la demande dans ce fil, ce n'est pas une commande de
création de la chaîne, mais de
suppression de cette chaîne supposée présente dans le fichier
plist.
--------------------
Il m'est alors revenu qu'il existe un petit utilitaire capable d'éditer des valeurs dans des
plist : le
/usr/libexec/PlistBuddy.
Alors, la commande :
Bloc de code:
/usr/libexec/PlistBuddy -c 'Delete :menuExtras: string "/System/Library/CoreServices/Menu Extras/AirPort.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist
opère directement et spécifiquement la suppression de la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le tableau du fichier
plist, sans rien déranger par ailleurs (et sans que j'ai à me précoccuper de savoir quel est le numéro de rang occupé par la chaîne dans le tableau).
Mais c'est là que je tombe sur une nouvelle difficulté. Si j'ajoute la commande de relance du processus
SystemUIServer >
killall SystemUIServer, ce qui me donne la commande globale :
Bloc de code:
/usr/libexec/PlistBuddy -c 'Delete :menuExtras: string "/System/Library/CoreServices/Menu Extras/AirPort.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist ; killall SystemUIServer
> le menulet
Wi-Fi ne disparaît pas de la barre des menus du Finder, pas plus que la case "
Afficher l'état Wi-Fi dans la barre des menus" du panneau des
Préférences Systèmes >
Réseau >
Wi-Fi ne se trouve corrélativement décochée.
Et pourtant, la chaîne :
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> a bien disparu du fichier
plist et le processus
SystemUIServer a bien été relancé.
--------------------
Quelque chose me déconcerte, ici : c'est l'
asymétrie de l'effet des commandes d'édition du tableau de la clé
menuExtras dans le fichier
plist => si j'ajoute la chaîne absente
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> par la commande :
Bloc de code:
defaults write com.apple.systemuiserver menuExtras -array-add "/System/Library/CoreServices/Menu Extras/AirPort.menu" ; killall SystemUIServer
qui relance aussi le processus du
SystemUIServer > j'obtiens en effet immédiat l'apparitition du menulet
Wi-Fi et le cochage de la case du panneau des
Préférences Système ; inversement, si je supprime la chaîne présente
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> par la commande :
Bloc de code:
/usr/libexec/PlistBuddy -c 'Delete :menuExtras: string "/System/Library/CoreServices/Menu Extras/AirPort.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist ; killall SystemUIServer
qui relance aussi le processus du
SystemUIServer > je n'obtiens ni disparition du menulet
Wi-Fi dans la barre de menus du Finer, ni décochage de la case du panneau des
Préférences Système.
Je fais alors un test croisé > je passe une commande
PlistBuddy pour
rajouter en première position la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le tableau du fichier
plist :
Bloc de code:
/usr/libexec/PlistBuddy -c 'Add :menuExtras:0 string "/System/Library/CoreServices/Menu Extras/AirPort.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist ; killall SystemUIServer
> résultat : le tableau du fichier
plist est correctement édité, avec une chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> recréée en première position > mais le menulet
Wi-Fi ne ré-apparaît pas dans la barre de menus du Finder et dans le panneau
Wi-Fi des
Préférences Système la case "
Afficher l'état Wi-Fi dans la barre des menus"
n'apparaît pas recochée.
J'en conclus que l'utilitaire
PlistBuddy édite aussi bien que l'utilitaire
defaults le fichier
plist (mieux même, car il possède une option
Delete appliquée à une chaîne dans un tableau que ne possède pas l'utilitaire
defaults) > mais les éditions de
PlistBuddy ne sont
pas suivies d'effet pour le
SystemUIServer à la différence des éditions de
defaults qui, elles, le sont.
=> quelque chose m'échappe complètement ici - mais je ne sais pas mettre le doigt dessus.
--------------------
En désespoir de cause, je me suis avisé qu'il existe un procédé radical en ligne de commande pour
désafficher /
réafficher instantanément l'icône du
Wi-Fi de la barre des menus du Finder (mais j'avoue : je rougis quelque peu
d'avoir eu l'idée de l'envisager) > la commande :
Bloc de code:
sudo chmod 000 /System/Library/CoreServices/Menu\ Extras/AirPort.menu ; killall SystemUIServer
produit un effet foudroyant en
masquant instantanément le menulet
Wi-Fi et en
décochant la case "
Afficher l'état Wi-Fi dans la barre des menus" du panneau des
Préférences Système sans éditer en rien le tableau du fichier
plist où la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> reste présente (si cette option était en place).
Car ? Car cette commande brutale interdit de permissions en
lecture / écriture /exécution le bundle
AirPort.menu at:
/System/Library/CoreServices/Menu\ Extras > en conséquence, le processus de toile de fond
SystemUIServer se voit instantanément
coupé l'accès à l'exécutable de ce bundle et par suite coupe son affichage.
[Noter que des valeurs octales comme : 600, ou 640, ou encore 644 etc. bref tout ce qui supprime l'executable_bit sur le bundle, fonctionnent aussi bien, sans qu'il soit besoin d'une option récursive, car l'absence de l'executable_bit interdit l'entrée à l'espace du répertoire Contents du bundle et, par suite, tout autre espèce de possibilité opératoire sur ses éléments qui restent hors accès.
Mais - personnellement - je trouve que, quitte à utiliser ce procédé brutal, un 000 induit un effet de signalisation graphique : l'affichage d'un sens interdit ⛔︎ sur le bundle > ce qui est susceptible de rappeler qu'il y a eu instauration d'une interdiction d'accès sur le AirPort.menu ; alors que les autres modifications de permissions en ne se signalant pas graphiquement risquent de se laisser oublier...]
Inversement, la commande :
Bloc de code:
sudo chmod 755 /System/Library/CoreServices/Menu\ Extras/AirPort.menu ; killall SystemUIServer
produit un effet tout aussi foudroyant en
ré-affichant instantanément le menulet
Wi-Fi et en
recochant la case "
Afficher l'état Wi-Fi dans la barre des menus" du panneau des
Préférences Système sans éditer en rien le tableau du fichier
plist où la chaîne
<string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> reste présente.
Car ? Car cette commande tout aussi brutale que la première restaure en
755 les permissions de
lecture / écriture /exécution sur le bundle
AirPort.menu at:
/System/Library/CoreServices/Menu\ Extras > en conséquence, le processus de toile de fond
SystemUIServer se voit instantanément
rétabli l'accès à l'exécutable de ce bundle et par suite reprend son affichage.
Dans l'OS «
El Capitan» où le
SIP instauré par défaut protège le répertoire
/System et ses dépendances > il faut donc
désactiver ce protocole afin que le procédé ci-dessus (parfaitement efficace mais grossier) s'exécute. Il faut noter qu'affectant le source-Système de l'affichage du menulet
Wi-Fi dans ses permissions > ce procédé prendra effet pour tous les utilisateurs de l'OS en cas de déloggement de session de l'utilisateur connecté et connexion d'un autre utilisateur.
♧