LidRun CLI : garder un Mac éveillé depuis le terminal

Ce qu'est réellement la CLI lidrun

lidrun n'est pas un programme séparé avec sa propre logique — c'est un petit script wrapper, installé dans ~/.local/bin/lidrun ou /usr/local/bin/lidrun, qui exécute le même binaire LidRun.app que vous avez déjà, appelé avec un flag --cli plutôt que lancé en double-cliquant dessus. Déplacer l'app plus tard, de Downloads vers Applications, ne casse pas le wrapper, car il est généré pour pointer vers l'emplacement réel du bundle de l'app au moment de l'installation.

En dessous, cela se scinde en deux comportements réellement différents, et les confondre est le meilleur moyen de mal comprendre ce que fait une commande. lidrun -- <command> est autonome : elle ouvre sa propre assertion d'alimentation de courte durée pour le processus enfant et la libère dès que ce processus se termine, sans avoir besoin que l'app LidRun soit ouverte. Toutes les autres commandes — status, start, stop, autowatch, watch, unwatch, patterns, timer, notify — dépendent du démon : elles ouvrent une connexion socket Unix locale vers l'app en cours d'exécution et lui demandent de changer d'état. Si l'app n'est pas ouverte, ces commandes échouent franchement avec une erreur, et non silencieusement sans rien faire.

Cette distinction compte pour ce que « régi par la sécurité » signifie vraiment plus loin dans cet article — ce n'est pas la même chose pour chaque commande, et prétendre le contraire est le genre d'affirmation qui tient... jusqu'au jour où le Mac de quelqu'un vide sa batterie au fond d'un sac.

La méthode gratuite : caffeinate et pmset

Avant de chercher un outil quel qu'il soit, macOS propose déjà deux façons de faire ça depuis un terminal, et autant être honnête à leur sujet — ce sont de vrais outils capables, pas des contournements. caffeinate -i your-command, ou caffeinate -i laissé tourner seul dans un onglet de réserve, maintient une assertion anti-veille idle pendant toute la durée d'exécution de l'utilitaire. Aucune installation, rien à qui faire confiance, et ça fait partie de macOS depuis plus d'une décennie — beaucoup de gens qui ont déjà fait ça l'ont dans les doigts.

Spécifiquement pour une utilisation couvercle fermé, pmset disablesleep 1 dit à macOS d'ignorer les déclencheurs de mise en veille à l'échelle du système, y compris le capteur du couvercle — exactement le mécanisme qu'utilise en dessous le mode Closed-Lid de LidRun lui-même, ce qui explique pourquoi LidRun prend soin de toujours associer un disablesleep 1 à un disablesleep 0 correspondant à la fin d'une session clamshell : à l'arrêt, à la fermeture de l'app, et de nouveau au lancement au cas où la session précédente n'aurait pas nettoyé derrière elle. Fait à la main, c'est un vrai one-liner pour des builds couvercle fermé, sans rien installer.

Pour une seule commande devant laquelle vous êtes assis, caffeinate -i npm run build est franchement aussi bon que tout le reste ici, LidRun compris.

Là où caffeinate et pmset atteignent leurs limites

L'écart apparaît quand plus personne ne surveille la session. Aucun des deux outils ne connaît le pourcentage de batterie ni la température du Mac — ils maintiennent exactement ce qu'on leur a demandé de maintenir, aussi longtemps qu'on le leur a demandé, point final.

disablesleep est la version la plus aiguë de ce risque, parce que c'est un réglage global, pas limité à un onglet de terminal. Si le script qui a lancé pmset disablesleep 1 plante, est tué avant d'atteindre le 0 correspondant, ou qu'une session SSH se coupe en plein milieu, le Mac se retrouve à refuser de dormir — couvercle fermé, sans surveillance, quelle que soit sa température — jusqu'à ce que quelqu'un s'en aperçoive et le corrige à la main. C'est exactement ce mode de défaillance qui explique pourquoi l'usage que fait LidRun de disablesleep est sécurisé à trois endroits distincts plutôt qu'un seul.

La version du risque côté caffeinate est plus discrète mais tout aussi réelle : un caffeinate -i en arrière-plan lancé il y a trois déploiements, toujours vivant dans un onglet de terminal que personne n'a fermé, en train de vider la batterie d'un laptop dans un sac sans que rien ne surveille la situation. Aucun des deux outils n'a tort de fonctionner ainsi — caffeinate fait un travail, proprement, par conception. Ce n'est simplement pas un plancher batterie ou thermique, et ça n'a jamais cherché à en être un.

Installer la CLI lidrun

La CLI n'est pas un téléchargement séparé. Ouvrez LidRun, allez dans Réglages, puis Ligne de commande, et cliquez sur Install lidrun CLI… — cela écrit le script wrapper décrit plus haut et propose un choix de portée.

Installer dans ~/.local/bin/lidrun ne nécessite aucun mot de passe admin ; il se peut que vous deviez ajouter ~/.local/bin à votre PATH une seule fois si ce n'est pas déjà fait — la boîte de dialogue de l'installateur le dit d'ailleurs clairement. Installer dans /usr/local/bin/lidrun place lidrun dans le PATH pour tous les shells sans cette étape supplémentaire, mais demande un mot de passe admin une seule fois, puisqu'écrire à cet endroit nécessite les droits root.

lidrun --version confirme quel build est réellement en cours d'exécution — il lit le même numéro de version que l'app elle-même, donc la CLI ne peut pas silencieusement se désynchroniser du GUI — et lidrun help affiche la liste complète des commandes sans quitter le terminal.

Toutes les commandes que propose réellement la CLI lidrun

lidrun status mérite d'être lancée en premier, et le plus souvent. À froid, elle affiche Mode: Awake Off, Assertion: inactive, Clamshell: off ; relancez-la après lidrun start et Mode affiche Awake On avec Assertion active — elle ajoute aussi des lignes Battery et Thermal chaque fois que le Mac a une batterie et un état thermique qui vaut la peine d'être affiché. lidrun start et lidrun stop forment la paire explicite marche/arrêt, et lidrun -- <command> est le wrapper, qui maintient l'anti-veille pendant exactement la durée de vie de ce seul processus et vous rend son vrai code de sortie une fois terminé — vérifiez $? ensuite et vous lisez le résultat propre à la commande enveloppée, pas celui de lidrun.

Une précision à faire clairement : il n'existe pas de lidrun on, lidrun off ou lidrun toggle tout seuls. Ces mots n'existent que comme argument d'autowatch — lidrun autowatch on, off ou toggle active ou désactive Auto Mode, le mode qui maintient l'anti-veille seulement tant qu'un nom de processus surveillé tourne réellement, et qui se relâche de lui-même dès que ce n'est plus le cas. lidrun watch <pattern> et lidrun unwatch <pattern> ajoutent ou retirent un nom de cette liste de surveillance, et lidrun patterns liste ce qui s'y trouve actuellement.

Deux commandes de plus complètent le tableau : lidrun timer 3600 maintient l'anti-veille pendant un nombre fixe de secondes et se libère d'elle-même une fois le compte à rebours écoulé, et lidrun notify "Build done" "exit 0" déclenche une notification locale et push via le même canal que les alertes propres à l'app — une dernière ligne raisonnable à ajouter dans un script enveloppé.

Deux façons de la scripter, et un piège avec les guillemets

Pour un script complet avec plus d'une étape, encadrez-le : lidrun start en haut, lidrun stop en bas, et tout le reste s'exécute entre les deux exactement comme si LidRun n'était pas impliqué. Comme les deux sont des commandes du démon qui reviennent immédiatement, peu importe que le script tourne dans un terminal au premier plan ou en mode headless via SSH — c'est l'app qui détient l'état réel.

Le vrai risque avec l'encadrement est le même que pour caffeinate et disablesleep : si une étape antérieure échoue et que le script se termine avant d'atteindre lidrun stop, le Mac reste sous un maintien permanent que personne ne va penser à lever. La correction standard est un trap d'une ligne en haut du script — trap 'lidrun stop' EXIT — qui exécute lidrun stop quelle que soit la façon dont le script se termine, plantage compris.

Pour une seule étape, la forme wrapper évite complètement le trap : lidrun -- ./build.sh maintient l'assertion pendant exactement la durée de vie de ce seul processus et la libère dès qu'il se termine, réussite ou échec — la même logique que caffeinate ./build.sh.

Un détail à connaître avant qu'il ne vous surprenne : lidrun -- fait passer les arguments joints par un vrai login shell, donc les opérateurs shell à l'intérieur d'une seule chaîne entre guillemets fonctionnent comme attendu. lidrun -- "npm run build && npm test" maintient un seul anti-veille sur les deux étapes. Retirez les guillemets et écrivez plutôt lidrun -- npm run build && npm test, et c'est votre shell externe qui interprète le && en premier — seul npm run build est transmis à lidrun, et npm test s'exécute ensuite, sans enveloppe, une fois que lidrun s'est déjà terminé. Comme cela passe par un login shell, les entrées PATH de Homebrew, pyenv ou nvm se résolvent aussi de la même façon que dans un terminal interactif, ce qui évite un piège courant avec les outils qui lancent un shell directement.

Ce que couvrent réellement les garde-fous de sécurité de LidRun dans une session CLI

C'est la partie où il vaut la peine d'être précis, parce que la réponse honnête dépend de la commande utilisée, pas de « la CLI » prise comme un tout. La protection batterie et thermique de LidRun vit dans le suivi d'état de l'app elle-même en cours d'exécution, pas dans une simple assertion d'alimentation brute — donc ce que reçoit une session lidrun dépend de si l'app surveille ou non cette assertion en particulier.

lidrun start, timer et autowatch maintiennent une assertion que l'app suit activement. Par défaut, si la batterie descend sous 20 % pendant que l'une de ces commandes est active, l'app libère le maintien d'elle-même — la même chose que ferait lidrun stop — pour que le Mac puisse s'endormir normalement avant que la situation ne devienne urgente. C'est le même plancher souple que reçoit le bouton Always On de la barre de menus, parce qu'en dessous, c'est le même état suivi.

lidrun -- <command> ne bénéficie pas de ce plancher souple, parce que son assertion vit dans le processus propre de courte durée de la CLI, en dehors de tout ce que l'app suit — il n'y a aucun état que l'app pourrait libérer par anticipation. Si l'app LidRun se trouve ouverte en même temps, ce qui est fréquent puisque c'est un utilitaire de barre de menus, son propre plancher d'urgence dur s'applique quand même à l'échelle du système : autour de 4 % de batterie par défaut (configurable entre 4 % et 8 %), LidRun appelle directement pmset sleepnow, ce qui force tout le Mac à s'endormir peu importe qui détient une assertion, y compris celle de la commande enveloppée. Si l'app ne tourne pas du tout, rien n'intervient, et lidrun -- <command> se comporte exactement comme un simple maintien caffeinate -i <command> : aucun plancher batterie, aucun contrôle thermique, juste la prévention de la mise en veille idle pendant toute la durée du processus.

En pratique, c'est un compromis tout à fait acceptable pour un build ou un test devant lequel vous êtes assis — c'est vous, le contrôle de sécurité. Pour une exécution nocturne réellement sans surveillance, où le plancher batterie doit compter du début à la fin, lidrun start associé à lidrun stop, ou Auto Mode, avec l'app ouverte, est la version surveillée en continu — pas seulement rattrapée si les choses tournent mal.

CI sur laptop, exécutions sans surveillance, et la place de la CLI parmi le reste

La vraie raison de se tourner vers tout ça, c'est un runner auto-hébergé ou un job nocturne sur un Mac posé quelque part sur un bureau — le genre de machine sans surveillance qui s'endort d'elle-même par inactivité, contrairement à une VM CI cloud éphémère. Envelopper le job avec lidrun -- ./nightly.sh, ou l'encadrer avec start et stop, empêche le Mac de s'endormir en plein milieu de l'exécution.

La CLI n'est qu'une pièce parmi un petit ensemble d'outils qui se recoupent volontairement. Auto Mode (lidrun autowatch on) garde le Mac éveillé seulement tant qu'un nom de processus surveillé tourne réellement, sans rien à se souvenir d'équilibrer ensuite. La vue Exécuter une commande du GUI fait le même travail que lidrun -- <command>, depuis une fenêtre plutôt qu'un terminal, et affiche le code de sortie et la durée d'exécution une fois terminé — la même information que $? donne à la CLI. Le choix entre les deux dépend surtout d'où démarre le job : un script se tourne vers la CLI, un geste ponctuel manuel se tourne vers le GUI.

Si le workflow tient entièrement dans un bouton de barre de menus plutôt que dans un script, Amphetamine, KeepingYouAwake, Lungo et Caffeine sont des outils établis, réellement capables, avec leurs propres règles de déclenchement — lancement d'une app, réseau Wi-Fi, heure de la journée. Ils ne sont pas construits en priorité autour d'un workflow terminal scriptable et conscient du code de sortie, comme le sont lidrun -- et caffeinate — donc si le job démarre dans un script ou un Makefile plutôt que d'un clic, les outils en ligne de commande sont mieux adaptés à ce job précis.

Les mêmes réserves s'appliquent ici que partout ailleurs : une surface dure et ventilée et une alimentation secteur sont la bonne configuration pour tout ce qui tourne longtemps, et la CLI aide à réduire la friction de garder un Mac éveillé depuis le terminal. Elle ne remplace pas le fait de vraiment revenir vérifier une machine à laquelle vous avez demandé de tourner sans surveillance toute la nuit.