10.11 El Capitan Script désactiver wifi status

[Logan_24]

Bonjour,

Je recherche un script qui me permet de désactiver le status du wifi dans le menu bar (en haut à droite) mais en ligne de commande. J'ai effectué quelques recherches et essayé en vain certaines solutions mais je n'ai rien trouvé de concluant.

Je suis sur MacBook Air El Capitan (10.11)

Merci

 

[bompi]

Petite précision, histoire d'être certain d'avoir bien compris : tu veux pouvoir enlever l'icône du ouifi de la barre de menu, à l'aide d'un script ? (on pourrait éventuellement comprendre aussi que tu voudrais pouvoir désactiver le ouifi avec un script).

Et, par script/CLI, tu entends bien un script de type bash (ou tout autre shell), pas AppleScript ni Automator.

En faisant un petit test, il semble que la présence ou l'absence de l'icône du ouifi se configure dans le fichier :
~/Library/Preferences/com.apple.systemuiserver.plist ; quand l'icône est dans la barre de menu de ma session, le fichier est comme suit :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<........>
        <key>menuExtras</key>
        <array>
                <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/VPN.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/Bluetooth.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/TimeMachine.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/Volume.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/TextInput.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/Clock.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/User.menu</string>
        </array>
</dict>
</plist>

Sinon :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<........>
        <key>menuExtras</key>
        <array>
                <string>/System/Library/CoreServices/Menu Extras/VPN.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/Bluetooth.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/TimeMachine.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/Volume.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/TextInput.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/Clock.menu</string>
                <string>/System/Library/CoreServices/Menu Extras/User.menu</string>
        </array>
</dict>
</plist>

Seule la ligne comprenant "AirPort.menu" est présente ou absente. C'est donc sans doute là que cela se passe.

 

[bompi]

Pour modifier ce fichier par des commandes en mode texte, on utilise la commande defaults.
Là, 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.

Donc je conseillerais de récupérer d'abord la valeur courante de la clef puis, selon ce qu'on veut faire, supprimer ou ajouter des éléments puis réinjecter le résultat.

Pour récupérer la valeur courante :

defaults read com.apple.systemuiserver menuExtras

 

[Membre supprimé 1060554]

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 :

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 :

/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 :

/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 :

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 :

/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 :

/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 :

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 :

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.

♧​

 

[JRial95]

Bonsoir tout le monde !

Je travaille avec Logan et je me suis donc aussi penché sur cette problématique. Après divers essais et observations, j'ai finalement réussi a créer un script shell qui permet de cacher l'icône wifi de la bar de menu et ce pour tout les utilisateurs et sans se hurter aux limitations causé par le SIP.

--------------------------​

Avant de vous expliquer comment je m'y suis pris, j'en profite pour répondre aux questions de macomaniac :

Pourquoi ?
Logan et moi travaillons à la mise à jours d'un parc informatique dans une école. Ce parc comprend des iMac, MacMini, Macbook, Macbook Air et Macbook Pro. Contrairement à ce que laisse penser la question de mon collègue, nous ne voulons pas cacher l'icône du wifi sur les Macbook Air mais sur les iMac et les MacMini qui sont eux de toutes manières connectés par Ethernet. Nous voulons faire ceci car comme ils sont reliés par Ethernet, nous désactivons le service wifi ce qui laisse apparaître dans la bar de menu l'icône du wifi avec une croix à l'intérieur. Ceci a engendré l'année passée de nombreux cas de support d'étudiants qui ont déploré ne pas avoir de wifi (bien qu'ils étaient connectés par câble). C'est donc pour cela que nous voulons cacher cette icône.

Pourquoi souhaiter une commande ?
Tout simplement car ceci permet de l'effectuer à grande échelle (car nous avons beaucoup de machines) et de manière transparente pour l'utilisateur.

--------------------------​

Nous voilà arrivé au : comment ?

Comme vous avez aussi pu le remarquer, le fichier ~/Library/Preferences/com.apple.systemuiserver.plist  est particulièrement intéressant car il contient le fameux tableau menuExtras qui contient ou pas la ligne "/System/Library/CoreServices/Menu Extras/AirPort.menu" selon si l'icône est affichée ou pas.

J'ai donc entrepris l'écriture d'un script permettant la suppression de cette ligne. Une fois le script terminé et testé avec succès sur ma machine, je l'ai essayé sur une autre machine fraîchement mise à jour et là... il ne fonctionnait pas . Il ne trouvait pas le tableau menuExtras dans la plist.

Effectivement après vérification, il ne contenait pas le tableau menuExtras. J'ai donc dû chercher ailleurs. Après de nombreuses recherches et observations, j'ai remarqué la création d'un fichier dans le dossier ~/Library/Preferences/ByHost/ et dont le nom est construit de la manière suivante : com.apple.systemuiserver.<uuid>.plist. En ouvrant ce fichier grâce à la commande defaults, voici ce que j'ai découvert :

{
    dontAutoLoad =     (
        "/System/Library/CoreServices/Menu Extras/AirPort.menu"
    );
}

Il contient donc les menu extras à ne pas charger automatiquement.

Fort de cette observation, j'ai créé un script qui en plus de vérifier si le fichier com.apple.systemuiserver.plist contient la ligne "/System/Library/CoreServices/Menu Extras/AirPort.menu" et de la supprimer dans le cas échéant, crée un fichier ~/Library/Preferences/ByHost/com.apple.systemuiserver.<uuid>.plist qui dit de ne pas charger automatiquement le menu extra concernant le AirPort. Après l'avoir testé sur plusieurs machines, il s'avère que mon script fonctionne maintenant dans tous les cas .

Pour qu'il soit exécuté à chaque login et pour chaque utilisateur, je l'ai mis dans un répertoire partagé entre chaque utilisateur et créé une plist que j'ai placé dans le répertoire /Library/LaunchAgents/ et qui se charge de lancer le script à chaque login.

--------------------------
​

Je vous remercie tous pour votre aide et je vous prie de m'excuser pour mon manque de réactivité sur cette discussion mais le weekend a été ensoleillé par chez nous et j'en ai profité .

Bonne semaine à tous

 

[Membre supprimé 1060554]

JRial

J'aurais dû me douter que quelqu'un à la recherche d'un script avait à gérer un problème de l'ordre de la quantité (ici : de nombreux utilisateurs connectés sur de nombreuses bécanes)

Malin ton plist dans les LaunchAgents.

Moi qui ne me posais la question de masquer le menulet Wi-Fi dans la barre de menus du Finder que pour un seul utilisateur connecté (moi) sur un seul Mac > je me heurte toujours expérimentalement à la même difficulté : la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> supprimée du tableau de la clé menuExtras dans mon fichier ~/Library/Preferences/com.apple.systemuiserver.plist  par l'effet de la commande :

/usr/libexec/PlistBuddy -c 'Delete :menuExtras: string "/System/Library/CoreServices/Menu Extras/AirPort.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist

et le fichier ~/Library/Preferences/ByHost/com.apple.systemuiserver.[UUID].plist (qui m'avait complètement échappé) comportant bien le paramétrage :

<dict>
    <key>dontAutoLoad</key>
    <array>
        <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>
    </array>
</dict>

=> aucune relance du processus SystemUIServer par un killall SystemUIServer ne produit le moindre effet sur l'affichage du menulet Wi-Fi qui s'avère résilient dans les 2 conditions suivantes :

- a) la commande est intervenue après ma connexion d'utilisateur et l'ouverture de ma session, sans déloggement de ma part.

- b) la commande est intervenue après ma connexion d'utilisateur et l'ouverture de ma session, et malgré un déloggement suivi d'un reloggement de ma part​

Par contre, si je re-démarre mon Mac > alors l'absence de la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le plist ~/Library/Preferences/com.apple.systemuiserver.plist prend effet dès l'ouverture de ma session > le menulet Wi-Fi n'est pas affiché.

Je suppose alors que, si tu as loggé un plist dans les LaunchAgents de la /Library > cette instruction est chargée avec le Système par launchd et ce, avant toute ouverture de session d'utilisateur > ce qui fait qu'elle a valeur exécutive pour tout utilisateur qui ouvre sa session.

Or, lorsque je manipule, ma session ouverte, la case des Préférences Système > Réseau > Wi-Fi : "Afficher l'état Wi-Fi dans la barre des menus" en la décochant > c'est immédiatement que le menulet Wi-Fi se trouve masqué > j'en déduis que cette action graphique exécute plus qu'une commande de suppression de la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le plist ~/Library/Preferences/com.apple.systemuiserver.plist et qu'une relance du SystemUIServer > mais je suis toujours en train de me demander quoi exactement qui se trouve prendre effet immédiat sans re-démarrage du Mac.

 

[Logan_24]

Bonjour Macomaniac,

Il est vrai que j'aurai dû développer un peu plus notre problème et décrire en quoi ce script nous aurait été utile ainsi que son contexte d'utilisation. Mon collègue JRial a passé un certains nombres d'heures à la résolution de cet problématique et nous pouvons confirmer que notre problème résolu.

Concernant votre question, nous ne comprenons pas pourquoi vos commandes ne prennent pas effet immédiatement après le killall SystemUIServer.

Dans notre cas la création du fichier ~/Library/Preferences/ByHost/com.apple.systemuiserver.[UUID].plist suivie de la commande killAll suffit à masquer immédiatement l'icône de la barre de menus. Evidemment ceci ne fonctionne que si le fichier ~/Library/Preferences/com.apple.systemuiserver.plist ne contient pas la ligne /System/Library/CoreServices/Menu Extras/AirPort.menu.

Merci à tous pour votre aide.

 

[Membre supprimé 1060554]

Logan

Tant mieux que ce soit résolu pour vous deux.

Concernant votre question, nous ne comprenons pas pourquoi vos commandes ne prennent pas effet immédiatement après le killall SystemUIServer.

Eh oui ! C'est le problème que je rencontre depuis le départ => la combinaison :

● absence de chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> dans le plist ~/Library/Preferences/com.apple.systemuiserver.plist

● existence du fichier ~/Library/Preferences/ByHost/com.apple.systemuiserver.[UUID].plist avec la mention de ne pas charger automatiquement le /System/Library/CoreServices/Menu Extras/AirPort.menu

● relance du SystemUIServer
​

=> ne produit aucun effet direct de disparition du menulet Wi-Fi. Non plus que quitter / relancer ma session. Seul un re-démarrage est efficace.

Évidemment, c'est une question toute théorique en ce qui me concerne. Comme j'ai énormément de processus qui se lancent à l'ouverture de ma session > j'en viens à me demander s'il n'y a pas quelque chose qui bloque de ce côté-là.​

 

[JRial95]

macomaniac

Évidemment, c'est une question toute théorique en ce qui me concerne. Comme j'ai énormément de processus qui se lancent à l'ouverture de ma session > j'en viens à me demander s'il n'y a pas quelque chose qui bloque de ce côté-là.

Je doute que cela vienne du fait que tu as beaucoup de processus qui se lancent à l'ouverture de la session et je ne sais vraiment pas pourquoi ça ne marche pas pour toi car nous avons lancé le script sur une vingtaine de postes fraîchement mis à jour et ça a marché à tous les coups.

Pour caché l'icône nous utilisons les commandes suivantes (dans l'ordre) :

Création du fichier com.apple.systemuiserver.<uuid>.plist :

defaults write <chemin_vers_le_fichier> dontAutoLoad -array "/System/Library/CoreServices/Menu\ Extras/AirPort.menu"

Suppression de la ligne /System/Library/CoreServices/Menu Extras/AirPort.menu dans le fichier ~/Library/Preferences/com.apple.systemuiserver.plist :

defaults write ~/Library/Preferences/com.apple.systemuiserver.plist menuExtras -array <menu_extras_a_garder>

Relance du SystemUIServer

killall SystemUIServer

J'espère qu'avec ses commandes tu arriveras à atteindre ton but

 

[Membre supprimé 1060554]

La situation dans ce fil s'est subtilement inversée : au départ, vous (Logan & JRial) posiez un problème et je faisais partie de ceux qui tentaient d'apporter une réponse ; à présent, c'est moi qui pose un problème et vous voilà en position d'apporter une réponse.

Avec cette différence (de « taille ») que j'utilise mon Mac de façon solitaire et n'administre donc qu'une singularité ; tandis que vous gérez un parc d'ordinateurs et de nombreux utilisateurs.

Je n'ai donc pas de problème au sens pratique du terme avec le menulet Wi-Fi (puisque je le veux affiché et sinon, que je peux décocher la case ad-hoc des Préférences Système, ou verrouiller le bundle /System/Library/CoreServices/Menu\ Extras/AirPort.menu par un 000 si je veux directement désafficher le menulet - le SIP ne me précoccupant pas puisque je l'ai désactivé).

Mais je m'intéresse au problème d'un point de vue théorique et je pense apercevoir le facteur qui fait diverger nos expérimentations.

--------------------
​

Alors voici l'état des lieux rebrossé.

Je vais supposer comme conditions expérimentales communes : la case des Préférences Système > Réseau > Wi-Fi : "Afficher l'état Wi-Fi dans la barre des menus" cochée a priori > un état suivant du fichier ~/Library/Preferences/com.apple.systemuiserver.plist :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>__NSEnableTSMDocumentWindowLevel</key>
    <true/>
    <key>last-messagetrace-stamp</key>
    <real>490095510.19525898</real>
    <key>menuExtras</key>
    <array>
        <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Volume.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Battery.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/TextInput.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Clock.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/User.menu</string>
    </array>
</dict>
</plist>

où l'on voit que la première chaîne (0) du tableau de la clé menuExtras est : <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> ; enfin, un fichier bien présent (chez moi, il a toujours été présent au départ) :
~/Library/Preferences/ByHost/com.apple.systemuiserver.XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX.plist dont voici le contenu :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>dontAutoLoad</key>
    <array>
        <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>
    </array>
</dict>
</plist>

Étant donné ces conditions théoriques de départ supposées communes, le menulet Wi-Fi est affiché dans la partie droite de la barre de menus du Finder. Étant donné encore l'existence supposée commune du fichier ByHost/--- , on mettra entre parenthèse ce facteur ici pour se concentrer sur l'édition en ligne de commande du seul fichier ~/Library/Preferences/com.apple.systemuiserver.plist suivi d'une relance de l'application SystemUIServer.

--------------------
​

Votre commande est la suivante (reconstruite par moi dans le cas de figure du fichier à 6 chaînes dans le tableau ci-dessus) :

defaults write com.apple.systemuiserver menuExtras -array "/System/Library/CoreServices/Menu Extras/Volume.menu" "/System/Library/CoreServices/Menu Extras/Battery.menu" "/System/Library/CoreServices/Menu Extras/TextInput.menu" "/System/Library/CoreServices/Menu Extras/Clock.menu" "/System/Library/CoreServices/Menu Extras/User.menu" ; killall SystemUIServer

Cette commande a pour effet l'édition du fichier ~/Library/Preferences/com.apple.systemuiserver.plist qui devient :

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>__NSEnableTSMDocumentWindowLevel</key>
    <true/>
    <key>last-messagetrace-stamp</key>
    <real>490095510.19525898</real>
    <key>menuExtras</key>
    <array>
        <string>/System/Library/CoreServices/Menu Extras/Volume.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Battery.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/TextInput.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Clock.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/User.menu</string>
    </array>
</dict>
</plist>

(disparition donc de la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>) => la case du panneau Préférences Système > Réseau > WI-FI est décochée > le menulet Wi-Fi a disparu.

=> je vous confirme que l'exécution de cette commande fonctionne chez moi aussi bien que chez vous.

Je vous vois triompher... D'un point de vue pratique, certes, mais le problème théorique est intact.

Car voici à présent l'expérimentation que je vous propose de faire sur un de vos ordinateurs portables (OS : «El Capitan 10.11.5»), une fois que vous aurez a la mano remis l'affichage du menulet Wi-Fi par le panneau des Préférences Système, de manière à avoir un fichier ~/Library/Preferences/com.apple.systemuiserver.plist comportant bien la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>.

C'est la commande (toute différente de la vôtre) que j'avais personnellement utilisée et décrite dans mon message de dimanche :

/usr/libexec/PlistBuddy -c 'Delete :menuExtras: string "/System/Library/CoreServices/Menu Extras/AirPort.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist ; killall SystemUIServer

Voici le résultat de cette commande en ce qui concerne le fichier ~/Library/Preferences/com.apple.systemuiserver.plist :

<?xml version="1.0" encoding="UTF-8"?
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>__NSEnableTSMDocumentWindowLevel</key>
    <true/>
    <key>last-messagetrace-stamp</key>
    <real>490095510.19525898</real>
    <key>menuExtras</key>
    <array>
        <string>/System/Library/CoreServices/Menu Extras/Volume.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Battery.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/TextInput.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/Clock.menu</string>
        <string>/System/Library/CoreServices/Menu Extras/User.menu</string>
    </array>
</dict>
</plist>

=> bon : c'est simple > la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> a disparu également dans le fichier, qui est exactement identique en écriture à son état résultant de votre commande.

Sauf que : le menulet Wi-Fi est toujours présent et la case "Afficher l'état Wi-Fi dans la barre des menus" toujours cochée. Je n'ai pas vottre retour d'expérience, mais je vais supposer (spéculativement parlant) qu'elle corrobore la mienne.

--------------------
​

Le problème devient : pourquoi une même cause (l'état identique du fichier du disque) ne produit-elle pas un même effet, mais 2 effets divergents : désaffichage du menulet WI-Fi par votre méthode d'édition du fichier vs préservation de l'affichage par ma méthode ?

Je ne conçois qu'un facteur médiateur possible entre l'état d'un fichier au disque et le comportement d'une application dont il est un fichier plist de préférences : c'est l'interposition d'un cache de l'application.

Depuis «Mavericks 10.9», les moutures d'OS X ont toujours davantage mis l'accent sur le fonctionnement en mode cache. Même le démarrage de l'OS s'opère sur cache (kernelcache, puis prelinkedkernel) et non à partir des fichiers paradigmes (comme le kernel original).

Si j'introduis ce facteur cache de l'application > voici ce qui se laisse concevoir : votre commande ne se contente pas d'éditer le fichier résident au disque, mais charge l'édition dans le cache courant de l'application > la relance du SystemUIServer (que je suppose encore relancer son processus en référence au cache actif) --> fait que la disparition de la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> est chargée et le menulet WI-Fi désaffiché.

Par contre, ma commande a tout l'air de ne faire qu'éditer le fichier résident du disque, sans charger cette édition dans le cache de l'application --> la relance du SystemUIServer re-charge les valeurs du cache actif et, la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string> y étant toujours présente --> le menulet WI-Fi reste affiché. Un simple déloggement de session > reloggement --> ne modifie pas le cache --> Wi-Fi toujours affiché. Un re-démarrage recharge le cache de l'application à partir du paradigme du disque et ce coup-ci le Wi-Fi n'est plus affiché.

[NB. Il est impossible de supposer que la relance de l'application SystemUIServer équivaut à lui faire lire directement le paradigme du fichier du disque, sinon, ma commande qui aboutit à la même édition textuelle du fichier (suppression de la chaîne <string>/System/Library/CoreServices/Menu Extras/AirPort.menu</string>) devrait conduire à cette lecture par l'application et dans ce cas-là aussi le menulet Wi-Fi devrait ne plus être affiché. Ce qui n'est pas le cas.

Je ne peux pas non plus supposer que cette relance recharge le cache d'après le fichier du disque, puis reparamètre l'application d'après le cache rafraîchi, car alors ça devrait fonctionner quelle que soit la méthode utilisée pour éditer le fichier paradigme.

La relance de l'application, en conséquence, doit rafraîchir sa référence au cache actif tel quel.]

Joli, non ?

--------------------​

Le problème devient : pourquoi votre commande defaults recharge-t-elle le cache de l'application à partir du fichier édité du disque, et pourquoi ma commande PlistBuddy ne recharge-t-elle pas le cache de l'application à partir du fichier du disque édité à l'identique ?

Je n'ai aperçu que 2 réponses possibles :

- a) votre commande agit en mode remplacement global d'écritures (elle écrase le contenu du tableau par un nouveau contenu de tableau), ou encore + qui remplace + ; alors que ma commande agit en mode défalcation locale d'écriture (elle soustrait une ligne dans le tableau en préservant le reste), ou encore par - ôté de +

=> j'ai cru un moment à cette solution fantastique, en me mettant à rêver d'un processus récurrent de lecture du contenu du fichier par une espèce de daemon dans lequel serait implémenté un critère de "sensibilité à un seuil de différence" dans les écritures. Ainsi, votre édition du fichier changeant en tout 6 lignes dans le fichier > le seul critique serait dépassé > déclenchement d'un rechargement du cache de l'application à partir du fichier paradigme du disque.

Afin de tester cette conjecture fantastique, j'ai utilisé d'abord ma commande négative :

/usr/libexec/PlistBuddy -c 'Delete :menuExtras: string "/System/Library/CoreServices/Menu Extras/----.menu"'
"/System/Library/CoreServices/Menu Extras/Battery.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist ; killall SystemUIServer

sur autant de chaînes du tableau <array> pour le vider complètement, puis la commande positive inverse :

/usr/libexec/PlistBuddy -c 'Add
:menuExtras: string "/System/Library/CoreServices/Menu Extras/----.menu"'
"/System/Library/CoreServices/Menu Extras/Battery.menu"' ~/Library/Preferences/com.apple.systemuiserver.plist ; killall SystemUIServer

en introduisant successivement les valeurs de chaînes permettant de recréer le tableau moins la chaîne AirPort et en relançant chaque fois l'application => je voulais voir si ma "conjecture" d'un seuil de différence conduisant à recharger le cache de l'application était valide => résultat : zéro pointé > le tableau est rechargé à la fin, comme avec votre commande, sans la chaîne AirPort et le menulet Wi-Fi continue d'être affiché.

- b) la commande defaults fait plus que la commande PlistBuddy. L'utilitaire PlistBuddy appelé par la commande éponyme doit être un programme simple, adressant une édition au fichier du disque. L'utilitaire defaults appelé par la commande éponyme doit être un "wrapper" : un enveloppeur de commandes, impliquant plusieurs opérations > outre l'édition simple du fichier paradigme du disque, il doit déclencher une opération de rechargement du cache de l'application à partir du fichier du disque > par suite, la relance de l'application lui fait récupérer une référence à un cache réfraîchi.

Si cette conjecture est valide : la commande PlistBuddy n'aurait jamais d'impact direct, mais demanderait un re-démarrage pour recharger le cache de l'application d'après le fichier paradigme du disque ; la commande defaults aurait toujours un impact direct, parce qu'elle envelopperait une rechargement du cache de l'application après édition du fichier paradigme du disque => une relance de l'application lui passerait donc la nouvelle valeur mise-en-cache.

(j'ai fait un contre-test simple à partir d'une situation où le menulet Wi-Fi n'est pas affiché et où la chaîne AirPort manque dans le fichier plist, en créant une variation : si j'ajoute la chaîne par PlistBuddy => rien ne se passe malgré la relance du SystemUIServer : menulet Wi-Fi toujours absent ; si j'ajoute la chaîne par defaults => à la relance de SystemUIServer > le menulet Wi-Fi est affiché directement. - Noter que l'édition ici ne porte que sur une ligne seule > ma conjecture a) d'un "seuil critique de changements dans un fichier" semble réfutée.)​

=> j'aurais esthétiquement préféré que ma conjecture a) soit vraie, mais j'ai l'impression qu'elle est fausse (ainsi donc aussi la déclaration de Platon : « Le Beau est la splendeur du Vrai » serait fausse > c'est la conception de Descartes qui serait vraie : l'esthétique n'a aucun rapport à la Vérité, mais n'est qu'une flatterie des sens et de tout ce qui en dérive). Je dois donc me rabattre sur la conjecture b) jusqu'à plus ample informé : l'exception de la commande defaults par rapport à la commande PlistBuddy.

--------------------​

 

[Logan_24]

Bonjour Macomaniac

Je suis assez impressionné par la rigueur dont vous faites preuve pour régler un problème qui à la base était le notre et j'en profite pour vous remercier encore une fois. Vous méritez votre statut de vétéran

Toutefois, nous vous avons donné les lignes de code que nous avons utilisé et celle ci fonctionnent parfaitement avec notre infrastructure.

Après réflexion, nous ne pouvons vous donner d'avantages d'informations afin de résoudre votre problème et nous en sommes désolé car nous ne pouvons dépenser plus de temps sur ce sujet du moins, nous avons sûrement moins de temps libre à disposition pour nous pencher d'avantage sur ce post.

Bonne soirée

 

[Membre supprimé 1060554]

Salut Logan

Comme disait Aristote : « Anankè sténaï » - "il est nécessaire de savoir s'arrêter" (il le disait à propos de la régression intellectuelle à l'infini dans la série des causes premières - mais on peut le dire aussi bien dans la considération de détails de plus en plus infimes)

Tu as trouvé de ton côté une solution qui marche au problème qui faisait l'objet de ce fil créé par ton collègue.

De mon côté, j'ai appris grâce à vous deux choses concernant la commande defaults dont je vous remercie :

- un procédé de « négation » par remplacement d'ensemble (d'un tableau) plutôt que par soustraction locale (d'une chaîne) qui ne m'était pas venu à l'esprit et qui me donne à penser.

- la prise d'effet directe de cette commande, après relancement de l'application impliquée par le fichier plist édité (présumablement grâce à un rechargement du cache de l'application).​

 

[litobar71]

Lorsque je lis (parcours) de la prose macomaniacienne à certains horaires je me dois de ne pas oublier de lancer mon minuteur (celui avec l'œuf sur le plat) pour ne pas arriver en retard au boulot.

En tout cas cela change les idées un petit moment.



Merci de ta contribution quotidienne à toutes heures.

 

[rparent]

Bonjour à tous,
J'utilise un laboratoire munis de mac os 10.11.6.
Je veux faire disparaitre icône du wi-fi dans la classe pour tous les utilisateurs. Ils sont déjà branchés ethernet. Le branchement wi-fi permet de contourner certaines règles qui ne sont nécessaire pour le cours.
Je ne suis pas un érudit des scripts. J'aimerais avoir la série d'étapes qui faut suivre pour y arriver. J'aimerais que cette règle s'applique pour tous les usagers. Je souhaite aussi pouvoir l'appliquer avec Apple Remote Desktop.
Merci de votre aide à l'avance!
RParent

 

[Membre supprimé 1060554]

Salut rparent

Hé ! hé ! tu remontes un fil dans lequel j'avais dépensé beaucoup attention pour scruter un curieux petit problème (qui n'avait eu l'air de n'intéresser que mézigue)

Tu pourrais peut-être décrire en détails ton cas de figure -->

• il s'agit d'une seule classe ? - chaque utilisateur se sert d'un Mac de bureau ? - combien en tout ?
• quel est le statut-type de l'utilisateur --> admin ? standard ? contrôlé ?
• as-tu accès en ouverture à la session de chacun ? ou bien est-elle privée (mot-de-passe personnel) ?

Je te pose ces questions > parce que ton souhait de masquer le menulet Wi-Fi dans la barre de menus du Finder > quoique visant un résultat apparemment analogue à celui recherché au départ par Logan, le créateur de ce fil > ne provient pas du tout des mêmes raisons -->

• Logan > et son collègue jRial qui était intervenu dans ce fil > voulaient masquer l'icône du Wi-Fi pour la raison suivante :

  Nous voulons faire ceci car comme ils sont reliés par Ethernet, nous désactivons le service wifi ce qui laisse apparaître dans la bar de menu l'icône du wifi avec une croix à l'intérieur. Ceci a engendré l'année passée de nombreux cas de support d'étudiants qui ont déploré ne pas avoir de wifi (bien qu'ils étaient connectés par câble). C'est donc pour cela que nous voulons cacher cette icône.

• Toi, par contre, tu veux la masquer sur des Macs de Bureau connectés par Ethernet pour la raison suivante :

  Je veux faire disparaitre icône du wi-fi dans la classe pour tous les utilisateurs. Ils sont déjà branchés ethernet. Le branchement wi-fi permet de contourner certaines règles qui ne sont nécessaire pour le cours.

Tu souhaites donc carrément empêcher qu'un utilisateur ne puisse utiliser le menulet Wi-Fi de la barre de menus du Finder pour activer le Wi-Fi. Tu vois déjà la question qui se pose : le menulet du Wi-Fi, outre l'affichage de l'état de la connexion Wi-Fi, est un raccourci permettant d'ouvrir le panneau des Préférences Système = Réseau => qu'est-ce qui va empêcher un utilisateur d'aller au Menu  > Préférences Système > et d'ouvrir le panneau Réseau  manuellement ?

Même un utilisateur Standard a le droit d'ouvrir ce panneau des Préférences Système qui ne comporte pas de cadenas. As-tu instauré un contrôle parental pour chaque compte d'utilisateur > tel que l'accès aux Préférences Système soit interdit ?

Étant donné ta problèmatique qui porte sur l'usage du panneau Réseau des Préférences Système (donc le menulet Wi-Fi de la barre de menus du Finder n'est qu'un raccourci commode) > tu comprendras que la solution de Logan & jRial qui ne visait qu'à masquer l'affichage de l'icône Wi-Fi pour ne pas désorienter des étudiants ne vaut pas pour toi. Car les commandes auxquelles ils recouraient n'avaient aucun effet sur l'accès au panneau Réseau.

=> à toi donc de donner davantage de précisions sur la situation que tu as à gérer.

 

[rparent]

Tu pourrais peut-être décrire en détails ton cas de figure -->

• il s'agit d'une seule classe ? - chaque utilisateur se sert d'un Mac de bureau ? - combien en tout ?
• quel est le statut-type de l'utilisateur --> admin ? standard ? contrôlé ?
• as-tu accès en ouverture à la session de chacun ? ou bien est-elle privée (mot-de-passe personnel) ?

Merci de me répondre.
Il s'agit d'une seule classe munie de 18 postes de bureau.
Ce sont des utilisateurs contrôlés en partie par un serveur Apple Ils n'ont pas accès à tous les outils des préférences systèmes puisque le serveur détermine ce à quoi ils ont droit. Ce faisant, la fenêtre qui permet de décocher l'affichage du wi-fi n'est pas accessible.
Les mots de passes sont imposés et j'y ai accès.

J'ai trouvé une solution temporaire un peu fastidieuse. J'aimerais un script qui me permette de le faire d'un coup. Pour tous les utilisateurs.

 

[Membre supprimé 1060554]

J'ai trouvé une solution temporaire un peu fastidieuse

Peux-tu décrire en quoi elle consiste ? - et pourquoi tu la qualifies à la fois de "fastidieuse" et de "temporaire" ?

--------------------

J'aimerais un script qui me permette de le faire d'un coup. Pour tous les utilisateurs.

En ce qui me concerne > je n'ai jamais utilisé de réseau > je ne me représente donc pas adéquatement quelles sortes d'actions un administrateur de réseau a à sa disposition pour agir sur le chargement d'OS d'ordinateurs particuliers ou sur les ouvertures de sessions d'utilisateurs particuliers. Cette remarque > pour te dire que je ne vois pas exactement comment t'aider à régler la question "d'un coup pour tous". Si c'est ton attente exclusive > je passe la main à qui s'y connaît dans le domaine "admnistration de parc informatique".

S'il s'agissait par contre d'une intervention "au coup par coup" > càd. de démarrer successivement chaque ordinateur de la série des 18 pour apporter à chaque fois un correctif en ligne de commande proscrivant l'affichage du menulet Wi-Fi dans la barre du Finder > aucun problème en ce qui me concerne dans ce cas de figure > étant donné l'examen du problème que j'avais fait antérieurement dans ce fil.

Je me suis amusé à créer un exécutable dans le volume d'une clé USB > qu'il suffit d'appeler dans un «Terminal» > et l'affichage de l'icône du WI-FI est absolument proscrite de la barre de menus du Finder. Cela peut valoir pour tous les volumes-Systèmes montés > s'ils sont adressables ensemble à un instant T. L'activation ou non du SIP étant un facteur indifférent.