LidRun CLI: Mac'i terminalden uyanık tutmak

lidrun CLI aslında nedir

lidrun, kendine ait mantığı olan ayrı bir program değil — ~/.local/bin/lidrun veya /usr/local/bin/lidrun konumuna kurulan küçük bir sarmalayıcı (wrapper) betik. Bu betik, zaten sahip olduğunuz LidRun.app ikili dosyasını, çift tıklamak yerine --cli bayrağıyla çağırarak çalıştırır. Uygulamayı sonradan Downloads'tan Applications'a taşımak sarmalayıcıyı bozmaz, çünkü betik, kurulum anında uygulama paketinin gerçekte nerede bulunduğuna işaret edecek şekilde oluşturulur.

Altında, gerçekten birbirinden farklı iki davranışa ayrılır ve bu ikisini karıştırmak, bir komutun ne yaptığını yanlış okumanın en kolay yoludur. lidrun -- <command> kendi kendine yeterlidir: alt süreç için kendi kısa ömürlü power assertion'ını açar ve o süreç sona erer ermez serbest bırakır — LidRun uygulamasının açık olmasına hiç ihtiyaç duymadan. status, start, stop, autowatch, watch, unwatch, patterns, timer, notify dahil diğer tüm komutlar ise daemon üzerinden çalışır: çalışan uygulamaya yerel bir Unix socket bağlantısı açar ve durumu değiştirmesini ister. Uygulama açık değilse, bu komutlar sessizce hiçbir şey yapmaz — doğrudan bir hatayla başarısız olurlar.

Bu ayrım, yazının ilerleyen kısımlarında "güvenlik denetimli" ifadesinin gerçekte ne anlama geldiği açısından önemli — her komut için aynı şey geçerli değil, aksini iddia etmek, ancak birinin Mac'inin çanta içinde pili tükenene kadar ayakta duran türden bir iddia.

Ücretsiz yol: caffeinate ve pmset

Herhangi bir araca yönelmeden önce, macOS bunu terminalden yapmanın iki yolunu zaten sunuyor ve bu konuda dürüst olmakta fayda var — bunlar geçici çözüm değil, gerçekten yeterli araçlar. caffeinate -i your-command, ya da boş bir sekmede tek başına çalışan caffeinate -i, araç çalıştığı sürece bir idle-sleep assertion'ı tutar. Kurulum gerektirmez, güvenmeniz gereken hiçbir şey yoktur ve on yılı aşkın süredir macOS'un bir parçası — bunu daha önce yapmış birçok kişinin elinde zaten hazır.

Özellikle kapak kapalı kullanım için pmset disablesleep 1, macOS'a sistem genelinde uyku tetikleyicilerini yok saymasını söyler — kapak anahtarı dahil. Bu, LidRun'ın kendi Closed-Lid modunun altında kullandığı tam mekanizma; LidRun'ın bir clamshell oturumu bittiğinde disablesleep 1'i her zaman eşleşen bir disablesleep 0 ile eşleştirmeye özen göstermesinin nedeni de bu: durdurmada, çıkışta ve bir önceki çalışma temizlenmemişse başlatmada tekrar. Elle çalıştırıldığında, hiçbir şey kurmadan kapak-kapalı build'ler için gerçek bir tek satırlık çözüm.

Önünde oturduğunuz tek bir komut için caffeinate -i npm run build, dürüst olmak gerekirse LidRun dahil buradaki her şey kadar iyi.

caffeinate ve pmset'in yolun sonuna geldiği yer

Boşluk, oturumu artık kimsenin izlemediği noktada ortaya çıkıyor. Her iki araç da pil yüzdesini veya Mac'in ne kadar ısındığını bilmiyor — kendilerine söylenen şeyi, söylenen süre boyunca tutuyorlar, hepsi bu.

disablesleep, bu riskin daha keskin bir versiyonu, çünkü tek bir terminal sekmesine değil, global bir ayara bağlı. pmset disablesleep 1'i çalıştıran betik çökerse, eşleşen 0'a ulaşmadan sonlandırılırsa ya da bir SSH oturumu çalışma sırasında kopar ise, Mac uykuya geçmeyi reddeder halde kalır — kapak kapalı, kimsenin bakmadığı, ne kadar sıcak çalışıyor olursa olsun — ta ki biri fark edip elle temizleyene kadar. LidRun'ın kendi disablesleep kullanımının tek yerine değil üç ayrı yerde savunmacı biçimde eşleştirilmesinin nedeni tam olarak bu arıza senaryosu.

caffeinate'in riski daha sessiz ama aynı derecede gerçek: üç deploy önce başlatılmış, kimsenin kapatmadığı bir terminal sekmesinde hâlâ yaşayan arka plandaki bir caffeinate -i, hiçbir şeyin kontrol etmediği bir çantada dizüstü bilgisayarın pilini tüketmeye devam ediyor. Her iki aracın da bu şekilde çalışması yanlış değil — caffeinate, tasarımı gereği tek bir işi temiz biçimde yapıyor. Sadece bir pil veya termal tabanı değil, hiç öyle olmaya çalışmadı da zaten.

lidrun CLI'ı kurmak

CLI ayrı bir indirme değil. LidRun'ı açın, Settings'e, ardından Command Line'a gidin ve Install lidrun CLI…'a tıklayın — bu, yukarıda açıklanan sarmalayıcı betiği yazar ve bir kapsam seçimi sunar.

~/.local/bin/lidrun konumuna kurmak hiçbir admin şifresi gerektirmez; ~/.local/bin zaten PATH'inizde değilse bir kereliğine eklemeniz gerekebilir — bunu kurulum penceresinin kendisi de açıkça söylüyor. /usr/local/bin/lidrun konumuna kurmak, lidrun'u bu ekstra adım olmadan her kabuk için PATH'e ekler, ama oraya yazmak root gerektirdiğinden tek seferlik bir admin şifresi ister.

lidrun --version, gerçekte hangi build'in çalıştığını doğrular — uygulamanın kendisiyle aynı sürüm numarasını okur, yani CLI'ın GUI ile sessizce senkronizasyondan çıkması mümkün değildir — ve lidrun help, terminalden çıkmadan tam komut listesini yazdırır.

lidrun CLI'da gerçekte var olan her komut

lidrun status, önce ve en sık çalıştırmaya değer komut. Soğuk halde Mode: Awake Off, Assertion: inactive, Clamshell: off yazdırır; lidrun start'tan sonra tekrar çalıştırdığınızda Mode, Awake On olarak ve Assertion active olarak görünür — Mac'in bir pili ve gösterilmeye değer bir termal durumu olduğunda Battery ve Thermal satırları da eklenir. lidrun start ve lidrun stop, açık/kapalı çiftinin kendisidir, lidrun -- <command> ise sarmalayıcıdır: tam olarak o tek sürecin ömrü boyunca uyanık-tutma bloğunu tutar ve iş bittiğinde gerçek çıkış kodunu geri verir — sonrasında $? kontrol ettiğinizde, lidrun'un değil, sarmalanan komutun kendi sonucunu okursunuz.

Açıkça belirtilmesi gereken bir düzeltme: tek başına bir lidrun on, lidrun off veya lidrun toggle yoktur. Bu kelimeler yalnızca autowatch'a argüman olarak var olur — lidrun autowatch on, off veya toggle, Auto Mode'u açar veya kapatır; bu mod, yalnızca izlenen bir süreç adı gerçekten çalışırken uyanık-tutma bloğunu tutar ve çalışmadığı anda kendiliğinden bırakır. lidrun watch <pattern> ve lidrun unwatch <pattern>, bu izleme listesine bir ad ekler veya çıkarır; lidrun patterns ise şu anda listede olanları gösterir.

İki komut daha tabloyu tamamlıyor: lidrun timer 3600, sabit bir saniye sayısı boyunca uyanık-tutma bloğunu tutar ve süre dolduğunda kendini serbest bırakır; lidrun notify "Build done" "exit 0" ise, uygulamanın kendi uyarılarının kullandığı aynı kanaldan yerel ve push bildirimi gönderir — sarmalanmış bir betiğin son satırı için makul bir seçenek.

İki betikleme deseni ve bir tırnak-işareti tuzağı

Birden fazla adımı olan bir betiğin tamamı için, betiği çevreleyin: üstte lidrun start, altta lidrun stop, aradaki her şey LidRun hiç dahil olmasaymış gibi tam olarak çalışır. İkisi de anında dönen daemon komutları olduğundan, betiğin ön plandaki bir terminalde mi yoksa SSH üzerinden headless mi çalıştığı fark etmez — asıl durumu tutan uygulamanın kendisidir.

Bu çevreleme yönteminin asıl riski, caffeinate ve disablesleep'inkiyle aynı: önceki bir adım başarısız olur ve betik lidrun stop'a ulaşmadan çıkarsa, Mac hiç kimsenin temizlemeyi hatırlamayacağı sürekli-açık bir blok altında kalır. Standart çözüm, betiğin başına eklenen tek satırlık bir trap: trap 'lidrun stop' EXIT — bu, betik nasıl çıkarsa çıksın, çökme dahil, lidrun stop'u çalıştırır.

Tek bir adım için, sarmalayıcı biçimi trap ihtiyacını tamamen ortadan kaldırır: lidrun -- ./build.sh, assertion'ı tam olarak o tek sürecin ömrü boyunca tutar ve süreç başarılı ya da başarısız bitsin, çıktığı anda serbest bırakır — caffeinate ./build.sh ile aynı yapı.

Sizi şaşırtmadan önce bilinmesi gereken bir detay: lidrun --, birleştirilmiş argümanları gerçek bir login shell üzerinden çalıştırır, bu yüzden tek bir tırnaklı string içindeki kabuk operatörleri beklendiği gibi çalışır. lidrun -- "npm run build && npm test", her iki adım boyunca tek bir uyanık-tutma bloğu tutar. Tırnakları kaldırıp bunun yerine lidrun -- npm run build && npm test yazarsanız, dış kabuğunuz && işaretini önce ayrıştırır — lidrun'a yalnızca npm run build geçirilir, npm test ise sonrasında, lidrun zaten çıktıktan sonra, sarmalanmadan çalışır. Bir login shell üzerinden çalıştığı için, Homebrew, pyenv veya nvm'den gelen PATH girdileri de etkileşimli bir terminaldeki gibi çözümlenir; bu da doğrudan shell'e çıkan araçlarda sık görülen bir tuzağı bertaraf eder.

LidRun'ın güvenlik korumaları bir CLI oturumunda gerçekte neyi kapsıyor

Bu, kesin olunması gereken bir kısım, çünkü dürüst cevap tek bir şey olarak "CLI"a değil, hangi komutu kullandığınıza bağlı. LidRun'ın pil ve termal koruması, çalışan uygulamanın kendi durum takibinde yaşar, salt bir power assertion'ın içinde değil — yani bir lidrun oturumunun ne aldığı, uygulamanın o belirli assertion'ı izleyip izlemediğine bağlıdır.

lidrun start, timer ve autowatch, uygulamanın etkin biçimde izlediği bir assertion tutar. Varsayılan olarak, bunlardan biri etkinken pil %20'nin altına düşerse, uygulama bloğu kendiliğinden serbest bırakır — tıpkı lidrun stop'un yapacağı gibi — böylece bir şeyler acil hale gelmeden önce Mac normal biçimde uykuya geçebilir. Bu, menü çubuğundaki Always On anahtarının aldığı aynı yumuşak taban, çünkü altta yatan aynı izlenen durum.

lidrun -- <command> bu yumuşak tabanı almaz, çünkü onun assertion'ı, uygulamanın izlediği her şeyin dışında, CLI'ın kendi kısa ömürlü sürecinde yaşar — uygulamanın erken serbest bırakabileceği bir durum yoktur. Menü çubuğu aracı olduğu için sık rastlanan bir durum olan LidRun uygulamasının aynı anda açık olması halinde, kendi sert acil durum tabanı yine de sistem genelinde geçerlidir: varsayılan olarak pil yaklaşık %4'e yaklaştığında (%4 ile %8 arasında yapılandırılabilir), LidRun doğrudan pmset sleepnow çağırır; bu da, sarmalanmış komutunkiler dahil, kim assertion tutuyor olursa olsun tüm Mac'i uykuya zorlar. Uygulama hiç çalışmıyorsa, hiçbir şey devreye girmez ve lidrun -- <command>, tam olarak çıplak bir caffeinate -i <command> bloğu gibi davranır: pil tabanı yok, termal kontrol yok, yalnızca süreç çalıştığı sürece idle-sleep önleme.

Pratikte, önünde oturduğunuz bir build veya test için bu gayet makul bir takas — güvenlik kontrolü sizsiniz. Pil tabanının baştan sona önemli olduğu, gerçekten gözetimsiz bir gece boyu çalışma için, uygulama açıkken lidrun start'ı lidrun stop ile eşleştirmek, ya da Auto Mode kullanmak, sadece işler kritikleştiğinde devreye giren değil, sürekli izlenen versiyondur.

Dizüstünde CI, gözetimsiz çalıştırmalar ve CLI'ın diğer her şeyin yanındaki yeri

Bunların herhangi birine yönelmenin asıl nedeni, gerçekten bir masada duran bir Mac üzerindeki self-hosted runner ya da gece işidir — geçici bir bulut CI sanal makinesinin aksine, kendi kendine boşta kalıp uykuya geçen türden gözetimsiz bir makine. İşi lidrun -- ./nightly.sh ile sarmalamak, ya da start ve stop ile çevrelemek, Mac'in çalışma ortasında boşta kalıp uykuya dalmasını engeller.

CLI, kasıtlı olarak birbiriyle örtüşen küçük bir araç setinin bir dikişi. Auto Mode (lidrun autowatch on), Mac'i yalnızca izlenen bir süreç adı gerçekten çalışırken uyanık tutar, sonrasında dengelemeyi hatırlamanız gereken hiçbir şey kalmaz. GUI'nin Run Command görünümü, lidrun -- <command> ile aynı işi bir terminal yerine bir pencereden yapar ve bittiğinde çalıştırdığı şeyin çıkış kodunu ve süresini gösterir — CLI'da $?'nin verdiği aynı bilgi. Hangisinin kullanılacağı büyük ölçüde işin nereden başladığına bağlı: bir betik CLI'a yönelir, elle yapılan tek seferlik bir iş GUI'ye yönelir.

Eğer workflow tamamen bir betik yerine bir menü çubuğu anahtarında yaşıyorsa, Amphetamine, KeepingYouAwake, Lungo ve Caffeine, kendi tetikleyici kurallarına sahip — uygulama açılışı, Wi-Fi ağı, günün saati gibi — köklü, gerçekten yeterli araçlar. Bunlar, lidrun -- ve caffeinate'in olduğu gibi, öncelikle betiklenebilir, çıkış-koduna duyarlı bir terminal workflow'u etrafında kurulmamıştır; bu yüzden iş bir tıklama yerine bir betikte veya Makefile'da başlıyorsa, CLI araçları o iş için daha uygun seçimdir.

Aynı uyarılar burada da her yerdeki gibi geçerli: uzun süre çalışan her şey için doğru kurulum sert, havalandırmalı bir yüzey ve şebeke gücüdür; CLI ise Mac'i terminalden uyanık tutmanın sürtünmesini azaltmaya yardımcı olur. Gece boyu gözetimsiz çalışmasını istediğiniz bir makineyi fiilen kontrol etmenin yerini tutmaz.