JC, popüler komut satırı araçlarının çıktısını JSON’a dönüştürüyor

 (github.com/kellyjonbrazil)
2 puan yazan GN⁺ 2023-12-10 | 1 yorum | WhatsApp'ta paylaş
  • JC, çeşitli CLI araçlarının, dosya biçimlerinin ve düz metinlerin çıktısını JSON’a çevirerek betiklerde daha kolay ayrıştırılmasına yardımcı olan bir araçtır
  • Pipe üzerinden girdi alıp STDOUT’a JSON yazar; ayrıca jc dig example.com gibi komutun önüne eklenen magic syntax’ı da destekler
  • Varsayılan çıktı, parser’a özgü katı bir şema kullanır; sayıları, null değerlerini, boolean değerleri ve ek anlamsal alanları dönüştürür. -r veya raw=True ile ön işleme öncesi ham JSON’a erişilebilir
  • Python kütüphanesi olarak da kullanılabilir; JSON yerine Python sözlüğü, sözlük listesi veya lazy iterable biçiminde sonuç alınabilir
  • Büyük hacimli ve uzun süre çalışan pipeline’lar için JSON Lines/NDJSON üreten streaming parser, --slurp, --meta-out, yerel parser eklentileri ve platform uyumluluğu uyarılarını bastırma seçenekleri sunar

JC ne yapar

  • JC(JSON Convert), çeşitli CLI araçlarının, dosya biçimlerinin ve düz metinlerin çıktısını JSON’a dönüştürür
  • Dönüştürülen çıktı, ek işlem için jq veya jello gibi araçlara pipe ile bağlanabilir
  • Örnekte dig example.com | jc --dig, dig çıktısını bir JSON dizisine dönüştürür; ardından jq -r '.[].answer[].data' ile yalnızca IP adresleri çıkarılır
  • Aynı işlem jc dig example.com | jq -r '.[].answer[].data' şeklinde magic syntax ile de çalıştırılabilir

CLI ve Python kütüphanesi kullanım biçimi

  • Temel CLI kullanımı, pipe girdisini alıp JSON gösterimini yazdırma şeklindedir
    • COMMAND | jc [SLICE] [OPTIONS] PARSER
    • cat FILE | jc [SLICE] [OPTIONS] PARSER
    • echo STRING | jc [SLICE] [OPTIONS] PARSER
  • magic syntax, jc [SLICE] [OPTIONS] COMMAND veya jc [SLICE] [OPTIONS] /proc/<path-to-procfile> biçiminde komutun ya da /proc dosyasının önüne jc ekler
    • Komut alias’ları ve shell builtin’leri desteklenmez
  • Python’da jc.parse('dig', cmd_output) şeklinde çağrılır
    • Dönüş değeri bir JSON string’i değil; Python sözlüğü, sözlük listesi veya streaming parser’ın lazy iterable’ı olabilir
  • Python paket dokümantasyonu help('jc'), help('jc.lib') veya çevrimiçi dokümanlar üzerinden görülebilir

Çıktı gösterimi ve şema

  • Varsayılan gösterim, parser’a özgü katı bir şema kullanır
    • Bilinen sayılar JSON int veya float değerlerine dönüştürülür
    • Bilinen None değerleri JSON null değerine dönüştürülür
    • Bilinen boolean değerler de dönüştürülür
    • Bazı parser’lar ek anlamsal alanlar ekler
  • Ham ön işleme JSON’una CLI’daki -r seçeneği veya Python kütüphanesindeki parse(..., raw=True) ile erişilir
  • Her parser’ın şeması, parser listesinin yanındaki dokümantasyon bağlantısından görülebilir
  • JSON çıktısı varsayılan olarak compact biçimdedir; -p seçeneğiyle pretty format kullanılabilir
  • -y veya --yaml-out seçeneğiyle YAML çıktısı da mümkündür

Desteklenen parser’lar ve kullanım örnekleri

  • Desteklenenler CLI komutları, dosya biçimleri ve string parser’larından oluşur
  • README’deki parser listesinde dig, ls, ping, ps, netstat, ifconfig, csv, xml, yaml, /etc/hosts, /etc/passwd, /proc/, systemctl, git log, jwt, url, semver, x509 ile ilgili dosyalar ve benzerleri yer alır
  • Örnek çıktılar, çeşitli girdilerin JSON yapısına nasıl dönüştürüldüğünü gösterir
    • arp çıktısı adres, donanım tipi, MAC adresi ve arayüz alanlarına dönüştürülür
    • CSV dosyası, başlıkları anahtar olarak kullanan nesne dizisine dönüştürülür
    • /etc/hosts, IP ve hostname dizilerine dönüştürülür
    • ifconfig, arayüz adı, MTU, IPv4/IPv6 adresleri, paket ve bayt sayaçları gibi bilgileri içeren nesnelere dönüştürülür
    • ping, gönderilen/alınan paket sayısı, kayıp oranı, gidiş-dönüş süresi ve yanıt listesini içeren bir nesneye dönüştürülür
  • Ansible’da community.general koleksiyonunun filter plugin’i olarak kullanılabilir

Kurulum yöntemi

  • jc birkaç farklı yöntemle kurulabilir
    • pip3 install jc
    • OS paket depoları
    • GitHub Releases’teki mimariye göre hazırlanmış ikili dosyalar
  • OS paketiyle kurulum örnekleri şunları içerir
    • Debian/Ubuntu: apt-get install jc
    • Fedora: dnf install jc
    • openSUSE: zypper install jc
    • Arch: pacman -S jc
    • macOS: brew install jc
    • FreeBSD: ports üzerinden kurulum
    • Ansible filter plugin: ansible-galaxy collection install community.general
    • FortiSOAR connector: FortiSOAR Connector Marketplace’ten kurulum

Başlıca seçenekler

  • -a / --about: jc ve parser bilgilerini JSON veya YAML olarak yazdırır
  • -d / --debug: Ayrıştırma sorunu olduğunda izleme mesajları yazdırır; -dd daha ayrıntılı hata ayıklama sağlar
  • -h / --help: Yardımı yazdırır; jc -h --parser_name ile parser dokümantasyonu görülebilir
  • -M / --meta-out: Zaman damgası, parser adı, magic command, magic command exit code gibi metadata bilgilerini çıktıya ekler
  • -q / --quiet: Parser uyarı mesajlarını bastırır; -qq streaming parser hatalarını yok sayar
  • -s / --slurp: Çok satırlı girdiyi bir diziye toplar
  • -u / --unbuffer: Çıktı buffering’ini devre dışı bırakır
  • -B / --bash-comp, -Z / --zsh-comp: Bash veya Zsh completion script’i üretir

Slice ve Slurp

  • Slice, Python slicing’e benzer START:STOP söz dizimiyle yalnızca girdi satırlarının bir bölümünü işler
  • Örneğin başlığı ve alt bilgisi olan bir tabloda, jc 1:-1 --asciitable veya jc 1:4 --asciitable ile ortadaki veriler JSON’a dönüştürülebilir
  • Pozitif ve boş slice en iyi bellek verimliliğini sağlar; negatif slice daha fazla bellek kullanır
  • Slurp, tek satırlık girdi alan string parser’larında birden fazla öğeyi tek seferde dizi olarak yazdıran bir özelliktir
    • Örn: Her satırda bir IP adresi bulunan bir dosya jc --slurp --ip-address ile işlenir
  • /proc magic syntax, birden fazla dosya seçildiğinde slurp’ü otomatik olarak destekler
    • Birden fazla /proc dosyası dönüştürüldüğünde, her sonuç nesnesinin hangi dosyaya karşılık geldiğini göstermek için _file alanı eklenir
  • --meta-out slurp ile birlikte kullanıldığında, result dizisi ve _jc_meta nesnesiyle sarmalanmış bir yapı yazdırılır

Çıkış kodu ve metadata

  • jc içindeki ölümcül hatalar çıkış kodu 100 üretir; aksi halde 0 döndürür
  • Magic syntax kullanıldığında jc, ayrıştırılacak programın çıkış kodunu saklar ve bunu jc çıkış koduna ekler
    • ifconfig 1, jc 0 ise birleşik çıkış kodu 1 olur
    • ifconfig 0, jc 100 ise birleşik çıkış kodu 100 olur
    • İkisinde de hata varsa birleşik çıkış kodu 101 olur
  • Magic syntax’ta --meta-out veya -M kullanıldığında _jc_meta nesnesi magic command bilgilerini ve çıkış kodunu içerir

Renkler ve ortam değişkenleri

  • JC_COLORS ortam değişkeniyle key name, keyword, number ve string renkleri belirtilebilir
    • Biçim JC_COLORS=<keyname_color>,<keyword_color>,<number_color>,<string_color> şeklindedir
    • Renk değeri black, red, green, yellow, blue, magenta, cyan, gray, brightblack, brightred, brightgreen, brightyellow, brightblue, brightmagenta, brightcyan, white, default seçeneklerinden biri olabilir
  • NO_COLOR ortam değişkeni ayarlanırsa renkli çıktı devre dışı bırakılır
  • -C seçeneği, NO_COLOR ortam değişkeni ve -m seçeneğinin önüne geçerek renkli çıktıyı zorunlu kılar

Streaming parser

  • Çoğu parser, STDIN’in tamamını belleğe okuyup ayrıştırdıktan sonra JSON belgesini seri halde yazar
  • Bazı streaming parser’lar girdiyi alır almaz satır satır işler ve JSON Lines veya NDJSON olarak yazdırır
    • Örn: ls-s, ping-s
    • ls -lR / gibi büyük komut çıktılarında bellek kullanımını ciddi ölçüde azaltabilir ve bazı durumlarda daha hızlı işleyebilir
  • Streaming parser’lar magic syntax ile birlikte kullanılamaz
  • Uzun süre çalışan pipeline’larda ayrıştırma hatasının pipe’ı bozmaması için -qq veya Python’daki ignore_exceptions=True kullanılabilir
    • Başarılı satırlar _jc_meta.success: true içerir
    • Başarısız satırlar _jc_meta.success: false, error, line alanlarını içerir
  • Pipe’lar arasında işletim sistemi buffer’ı nedeniyle çıktı gecikmeli görünüyorsa -u ile unbuffered output kullanılabilir
    • Ancak büyük veri akışlarında unbuffered output daha yavaş olabilir
  • Python’da streaming parser’lar iterable girdi alır ve lazy işlem için iterable nesne döndürür

Parser eklentisi

  • Yerel parser plugin’i, uygulama veri dizinindeki jc/jcparsers klasörüne konabilir
    • Linux/unix: $HOME/.local/share/jc/jcparsers
    • macOS: $HOME/Library/Application Support/jc/jcparsers
    • Windows: $LOCALAPPDATA\jc\jc\jcparsers
  • Eklentiler standart Python modül dosyalarıdır
  • jc/parsers/foo.py veya jc/parsers/foo_s.py şablon olarak kullanılabilir
  • Eklenti dosya adı geçerli bir Python modül adı olmalı; harfle başlamalı ve yalnızca alfanümerik karakterler ile underscore içermelidir
  • Yerel eklentiler varsayılan parser’ları override edebilir

Locale, saat dilimi ve uyumluluk

  • En iyi sonuçlar için LC_ALL değerinin C veya en_US.UTF-8 olarak ayarlanması önerilir
  • Bazı eski sistemlerde C locale’i UTF-8 kodlamasını desteklemediğinden UTF-8 çıktı ASCII ve \\u escape sequence’larına düşebilir
  • Bazı parser’lar hesaplanmış epoch timestamp alanları ekler
    • Alan adı _utc suffix’ine sahip değilse yerel saat dilimine dayalı naive timestamp kabul edilir
    • UTC saat dilimi komut çıktı metninde algılanırsa timezone aware timestamp olur ve anahtar adına _utc suffix’i eklenir
    • UTC dışındaki saat dilimleri aware timestamp olarak desteklenmez
  • Bazı parser’lar platforma özgü çıktıları dönüştürdüğünden desteklenmeyen bir platformda çalıştırıldığında uyarı yazdırır
  • Desteklenmeyen platformlarda da başka sistemlerin çıktı dosyaları ayrıştırılabilir; bu durumda -q veya Python’daki quiet=True ile uyarılar bastırılabilir
  • Test edilen platformlar arasında Centos 7.7, Ubuntu 18.04/20.04, Fedora32, macOS 10.11.6/10.14.6, NixOS, FreeBSD12, Windows 10, Windows 2016 Server ve Windows 2019 Server yer alır

İlgili okumalar

1 yorum

 
GN⁺ 2023-12-10
Hacker News yorumları

  • FreeBSD’de bu sorun libxo ile bir ölçüde çözülmüş durumda:
    $ ps --libxo=json | jq gibi yapılandırılmış çıktı alınabiliyor
    Kusursuz değil; ls desteği vardı ama bir nedenle kaldırıldı ve tüm yardımcı araçlar da desteklemiyor
    jc, birçok komut ayrıştırıcısı sunan iyi bir geçici çözüm gibi görünüyor; ancak en baştan ayrıştırma için tasarlanmamış metin çıktısını ayrıştırma sınırlamasına sahip
    Yardımcı araçların ortak bir bayrakla yapılandırılmış çıktı üretmesi için birleşmesi iyi olurdu; PowerShell’deki gibi varsayılan olması Unix/Linux için fazla olsa da standart bir --json bayrağı bile büyük bir ilerleme olur
    https://wiki.freebsd.org/LibXo
    https://reviews.freebsd.org/D13959

    • PowerShell, JSON’dan bir adım ileri giderek gerçek değiştirilebilir nesneleri destekliyor
      Anladığım kadarıyla yalnızca yapılandırılmış veri geçirmekle kalmıyor; opak nesneleri pipeline’dan geçirip önceki adıma dönerek metot da çağırabiliyor: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_methods?view=powershell-7.4
      jc, libxo gibi wrapper’ları ve https://www.nushell.sh/ gibi deneysel shell’leri de seviyorum; ancak bunlar çalıştırılabilir metotları olan nesnelerden çok veri aktarımına odaklanıyor
      Yapılandırılmış veri hâlâ Unix’e uygun hissettiriyor; gerçek nesnelere ihtiyaç varsa Python ya da Ruby açma zamanı geldiğini düşünüyorum
      Shell ne kadar iyi olursa olsun ve programlama özellikleri ne kadar güçlü olursa olsun, ne zaman shell betiğinden ciddi bir programlama diline geçileceğini bilmek önemli
    • Asıl yazının yazarı tarafından yazılan blog yazısı tam da bu konuyu ele alıyor
      jc bu zamana kadar bu rolü dolduran bir araç olarak tanıtılıyor ve Unix araçlarının genelinde -j/--json desteği yaygınlaşana kadar bir basamak taşı olarak amaçlandığı anlaşılıyor
      https://blog.kellybrazil.com/2019/11/26/bringing-the-unix-philosophy-to-the-21st-century/
    • SerenityOS’ta da benzer şekilde /proc altındaki öğeler yapılandırılmamış metin dosyaları yerine JSON verisi döndürüyor
      Daha yapısal bir çözüm, ELF içinden veri yapılarını dışa aktarılabilir kılmak; bu veri yapılarını terminal çıktısına serileştirdikten sonra kullanıcının istediği JSON, YAML gibi biçimlerde çıktı almasına ya da işlemesine izin vermek olabilir
    • Libxo teoride harika; ancak uygulamanın yapıyı libxo’ya verip biçimlendirmeyi ona bırakması yerine, her çıktı biçimi için mantığı kendisinin uygulaması gerekiyormuş gibi görünüyor
      Tam olarak hangi yardımcı araç olduğunu hatırlamıyorum ama muhtemelen iostat idi; JSON çıktı satırlarını string interpolation ile biçimlendirirken belirli bayrak kombinasyonlarında tamamen bozuk çıktı üretiyordu
      Şimdi düzelip düzelmediğini bilmiyorum ama aralık seçeneği varken JSON lines benzeri bir biçim beklerdim
      Kullanılabilirlik açısından PowerShell ve kubectl’in libxo’dan çok daha ileride olduğunu düşünüyorum
    • Libxo, FreeBSD temel sisteminde yer alıyor; ancak genel olarak da kullanılabiliyor
      https://github.com/Juniper/libxo
      https://libxo.readthedocs.io/en/latest/

  • Fikir gerçekten çok iyi, ama bakımını düşününce insan huzursuz oluyor
    Sürüm ve komut bayraklarına göre çıktı değişiklikleri gibi şeyler hesaba katılınca bakım cehennemi gibi görünüyor; pratikte bazı durumlarda iyi çalışacaktır ama temel örneklerin ötesine geçince yenilik hissi hızla kaybolacak gibi
    Ayrıca araç seçeneklerinde -- kullanmak da pek iyi görünmüyor
    Her yeni ayrıştırıcı için yeni bir bayrak gerekiyorsa yardım ya da kılavuz sayfaları binlerce satıra ulaşabilir

    • Bunu, komut satırı yardımcı araçları giderek JSON çıktısını desteklemeye başladıkça sorumluluk kapsamı azalacak bir shim olarak görürsek makul olabilir
      Bir yardımcı araç kendi JSON dışa aktarımını desteklemeye karar verdiğinde, bundan sonra bu araç o özelliğe delege edebilir
    • Belgelerde biraz daha aşağı inince jc ls gibi komutun başına jc ekleyerek de kullanılabildiği görülüyor
      --cmd parametresi, dönüştürme öncesinde veriyi işlemeyi mümkün kıldığı için aslında iyi bir fikir
      Örneğin dönüştürmeden önce listeyi greplemek isteyebilirsiniz
      Bakım açısından da temel Unix komutlarının çıktısı büyük ölçüde değişirse yalnızca bu aracı değil, sayısız betiği de bozacağından; başka ikili dosya güncellemeleri yüzünden sanıldığı kadar sık bozulacak gibi görünmüyor
    • Bir yandan da çelişkili hissediyorum
      İyi yönetilen tek bir ortak ayrıştırıcı paketi, oraya buraya dağılmış geçici çıktı ayrıştırıcılarından daha iyidir; ancak karmaşık işler yapmaya çalışıp doğrudan JSON çıktısına ihtiyaç duyduğum durumlarda ayrıştırmanın kendisinin soruna ek yük getirmemesini isterim
      Bunu rahat kullanmak için, sanırım kullanacağım her şey için ek test vakalarını PR olarak göndermek gerekir
      Zaten o testleri kendim yazmak zorunda kalacaktım
    • Bu iş işbirliği gerektiriyor
      İnsanların ihtiyaç duyulan araçların ayrıştırma bilgilerini göndermesi ve kullananların bunları kolayca güncel tutması dışında yol yok
    • Yapılandırılmamış metni yapılandırılmış nesnelere dönüştürmede iyi beceri gösteren LLM’ler için daha iyi kullanım alanlarından biri

  • Nushell’in yaklaşımı farklı olsa da çoğunlukla aynı noktaya, kabuk komutlarının yapılandırılmış verisine ulaşıyor
    Bu rolü esas olarak kabuğun kendisinin üstlendiği bir yaklaşım
    http://www.nushell.sh/

    • Nushell’de from json işlemi var; bu yüzden JC ile gerçekten iyi uyum sağlıyor
      Daha önce Nushell’in bazı güzel özelliklerini gösteren bir video kaydetmiştim; 19. dakika civarında jc ile birlikte kullanmaktan bahsediyorum: https://www.youtube.com/watch?v=KF5dtxVsn1E
    • Nushell ilk duyurulduğundan beri ara sıra göz atmıştım, ama ancak bir iki ay önce nihayet özünü gerçekten kavradım
      Belirli bir desene uyan dizinlerdeki dosyaları tarayıp, değiştirilme zamanları birbirinden 10 dakika içinde olanları kaldıran bir script yazmaya çalışırken Nushell’in böyle işler için iyi olduğunu hatırladım
      Biraz kurcalayınca sonunda kafama yattı ve şimdi ona kapılmış durumdayım
      Yapılandırılmamış veriyi bile kayıt listesi gibi bir biçime dönüştürüp işleyebiliyorsanız bu çok güçlü

  • Bir anlamda dosyaların her yerde olması harika; Unix’in vaadi bu, Plan 9’da da daha genişletilmiş hali
    Ama yapılandırılmamış dosyalar ya da her dosyanın kendi formatına sahip olması da aynı ölçüde ayak bağı oluyor
    Yalnızca awk gibi araçlarla tek bir nginx günlük dosyasını ayrıştırmaya çalışmak bile zahmetli olabilir
    Büyük eksilerden biri, Linux kullanıcı alanında büyük ölçekli sistem yeniden yazımlarını ya da tasarım değişikliklerini hayata geçirmenin zor olması
    Daha akıllı bir kabuk istiyorum, dosyaları da seviyorum, yanımda awk kitabı da duruyor; ama artık veri ayrıştırma konusunda ciddi bir iyileştirme zamanının geldiğini düşünüyorum
    Programların renkli çıktı render edip etmeyeceğine kendilerince karar vermesi gibi, yapılandırılmış çıktı verip vermeyeceğini de yapabilmesi iyi olurdu

    • Sorunun bir parçası, komut çıktısının hem kullanıcı arayüzü hem de API olması
      Herhangi bir metin arayüzü API gibi kullanılabildiği için insanın okuması kolay metin öncelik kazanıyor
      Bu yüzden kabuk betikleme, üçüncü taraf tarayıcı eklentisi yazmaya benziyor
      Bakıp tahmin ediyor, sonra o tahmine dayanarak aceleyle bir ayrıştırıcı uyduruyor ve çalışmasını umuyorsunuz
      Makinenin okuyacağı içerik için üçüncü bir standart çıktı olsa iyi olurdu
      Terminal varsayılan olarak bunu basmaz, pipe yapıldığında bu çıktı pipe edilir, JSONL olur ve man sayfası sözleşmeyi belirtir
      Böylece standart çıktı insanlara ayrılmış kalabilir; ayrıştırma ise mümkün ama kırılgan olduğunu bilerek yapılan bir iş olur
      Elbette bu tamamen geriye dönük uyumluluğu bozan bir fikir; gerçekçi olmayan biçimde CLI’ı temelden yeniden icat edip modernleştirecek olsak değiştirmek isteyeceğim şeylerin listesi uzun
    • Yarım yüzyıl önce epey iyi fikirler ortaya çıktı; birçok kişinin bunları geliştirilecek şeyler olarak görmek yerine kutsal metin gibi kabul etmesi can sıkıcı
      İyileştirme elde etmek de gerçekten zor; Lennart gibi biri onlarca yıllık eski tortuları temizlemeye kalkınca hemen drama çıkıyor
      JSON da hâlâ kusursuz değil
      JSON fena sayılmayan bir fikir, ama işi doğru yapmak için veri türleri gibi şeyleri ifade edebilen bir biçime ihtiyaç var
      Sayıları sayı olarak ele alıp $a - $b ile tarih farkı hesaplama gibi şaşırtıcı şeyleri yapabilmek için PowerShell’e daha yakın bir yaklaşım gerekir
    • Daha kolay bir iyileştirme, tüm CLI araçlarında komut satırı argümanı olarak JSON çıktısı uygulamak olurdu
      Bunun GNU coreutils’te gerçekleşmesini isterdim
    • PowerShell seçeneği her zaman var
      Sorun, .NET’e ve nesnelere fazlasıyla kök salmış olması; bu yüzden herhangi bir platformda mevcut yerel komutlarla bütünleştirmek çok zor
    • Sunucu günlüklerini ayrıştırma tarafında, logstash gibi şeylerden bu işlevi söküp alamamak üzücü
      Çünkü özünde zaten aynı işi yapıyorlar
      Yine de nihai hedef muhtemelen üst seviye araçların değeri görüp doğrudan yapılandırılmış çıktı sunması olacak

  • Harika
    Makul JSON çıktısını destekleyen CLI araçlarını güçlü biçimde destekliyorum; https://github.com/WireGuard/wireguard-tools/blob/master/contrib/json/wg-json gibi şeyler ve PowerShell’in |ConvertTo-Json özelliği yönetim/izleme otomasyonunun büyük bir parçası
    Ancak burada makul kelimesi çok iş yapıyor ve gerçekler de ortada
    LSI/Broadcom StorCLI’de komutun sonuna J ekleme yöntemi ya da PowerShell’in COM’u gizleyen wrapper’ları gibi, teknik olarak JSON olan ama sonucu saçma derecede karmaşık veya kullanışsız çıkan şeyler yüzünden çoğu zaman sonunda “düz metin çıktıya biraz regex uygulayalım” geçici çözümüne geri dönülüyor
    Yine de buna mutlaka bakacağım
    İlk örnek olan dig çıktısını ayrıştırma, güvenilir biçimde yapılabilecek işleri temsil ediyorsa epey ilginç olabilir

  • Bence varsayılan sözdizimi jc dig example.com olmalı
    Çünkü dig example.com | jc --dig, çıktıyı ayrıştırmak için önceki komutun bayraklarını ve parametrelerini sonradan tahmin etmeyi gerektiriyor

  • Tüm çıktıların nesne olması, PowerShell’de en sevdiğim şeylerden biri
    Ne zaman bash scripti yazmak zorunda kalsam bunu özlüyorum

  • Bunu bakımını üstlenmeye karar veren kişiye saygılar

    • Bu aracın yanlış varsaydığı kısımlarla gerçekten karşılaşıp kullanmaya karar veren kişiye de saygılar
    • Sürüm sorununu nasıl ele alacaklarını merak ediyorum
      aws s3 ls | jc --aws=1.2.3 gibi bir şeyse kâbus olur
    • İyi nokta
      Linux veya Unix’teki file programını ve onun bakımını yapan kahramanları hatırlatıyor
    • Teorik olarak plugins gibi şeyler yüklenebiliyorsa, örneğin ayrı kabuk komutu biçiminde tutarak bakım emeğinin bir kısmını eklenti yazarlarına devredebilirsiniz

  • --json seçeneğini kabul eden modern Unix komut satırı araçlarının bir listesinin olup olmadığını merak ediyorum
    Bu depoya böyle bilgileri eklemek de faydalı olabilir

    • FreeBSD’de libxo aracılığıyla fiilen neredeyse her şey destekleniyor
    • Liste yok ama ifconfig’in modern alternatifi olan ip JSON’u destekliyor
      lldpctl de destekliyor
      Ansible, sistem ayrıntılarını facts adlı JSON olarak sunuyor ve otomasyonun bunlardan yararlanması için tasarlanmış
    • lsblk, --json bayrağını kabul ediyor ve çok fazla bilgi verebiliyor
      lsblk --json --output-all komutunu deneyebilirsiniz
      Bir betiğin sistemdeki diskleri ve bölümleri kontrol etmesi gerektiğinde çok kullanışlı
    • Wireshark’ın CLI eşlik aracı TShark, -T json bayrağıyla destekliyor
    • Kastedilen yanıt olmayabilir ama AWS CLI var

  • İlginç bir proje
    Ama ilk aşama ayrıştırıcı olarak textfsm gibi bir şey kullanacağını düşünmüştüm
    textfsm, ağ cihazlarının CLI çıktısını ayrıştırmak için yaygın olarak kullanılıyor
    https://github.com/google/textfsm