JC, लोकप्रिय कमांडलाइन टूल्स के आउटपुट को JSON में बदलता है

 (github.com/kellyjonbrazil)
2 पॉइंट द्वारा GN⁺ 2023-12-10 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • JC कई CLI टूल्स, फ़ाइल फ़ॉर्मैट्स और सामान्य strings के आउटपुट को JSON में बदलता है, ताकि scripts में उन्हें आसानी से parse किया जा सके
  • यह pipe input लेता है और STDOUT पर JSON output देता है, साथ ही jc dig example.com जैसी magic syntax भी सपोर्ट करता है
  • डिफ़ॉल्ट output parser-विशिष्ट strict schema का उपयोग करता है और numbers, null, boolean, तथा अतिरिक्त semantic fields को convert करता है; -r या raw=True से pre-processing से पहले के raw JSON तक पहुँचा जा सकता है
  • इसे Python library के रूप में भी इस्तेमाल किया जा सकता है, जहाँ JSON की जगह Python dictionary, dictionary list, या lazy iterable के रूप में result मिल सकता है
  • बड़े और लंबे समय तक चलने वाले pipelines के लिए यह JSON Lines/NDJSON output देने वाले streaming parsers, --slurp, --meta-out, local parser plugins, और platform compatibility warnings को suppress करने के options देता है

JC क्या करता है

  • JC(JSON Convert) कई CLI टूल्स, फ़ाइल फ़ॉर्मैट्स और सामान्य strings के आउटपुट को JSON में बदलता है
  • बदले हुए output को jq या jello जैसे टूल्स के साथ pipe करके आगे process किया जा सकता है
  • उदाहरण के तौर पर dig example.com | jc --dig dig के output को JSON array में बदलता है, और फिर jq -r '.[].answer[].data' से सिर्फ IP addresses निकाले जा सकते हैं
  • यही काम jc dig example.com | jq -r '.[].answer[].data' जैसी magic syntax से भी किया जा सकता है

CLI और Python library का उपयोग

  • बेसिक CLI उपयोग pipe input लेकर JSON representation output करने का है
    • COMMAND | jc [SLICE] [OPTIONS] PARSER
    • cat FILE | jc [SLICE] [OPTIONS] PARSER
    • echo STRING | jc [SLICE] [OPTIONS] PARSER
  • magic syntax में jc [SLICE] [OPTIONS] COMMAND या jc [SLICE] [OPTIONS] /proc/<path-to-procfile> फ़ॉर्म में command या /proc फ़ाइल के आगे jc लगाया जाता है
    • command alias और shell builtin सपोर्ट नहीं होते
  • Python में इसे jc.parse('dig', cmd_output) की तरह call किया जाता है
    • return value JSON string नहीं, बल्कि Python dictionary, dictionary list, या streaming parser का lazy iterable हो सकता है
  • Python package docs help('jc'), help('jc.lib'), या online docs में देखे जा सकते हैं

Output representation और schema

  • डिफ़ॉल्ट representation parser-विशिष्ट strict schema का उपयोग करता है
    • पहचाने गए numbers को JSON int या float values में बदला जाता है
    • पहचानी गई None values को JSON null में बदला जाता है
    • पहचानी गई boolean values भी convert की जाती हैं
    • कुछ parsers अतिरिक्त semantic fields जोड़ते हैं
  • raw pre-processed JSON तक CLI के -r option या Python library के parse(..., raw=True) से पहुँचा जा सकता है
  • हर parser का schema parser list के पास दिए गए docs links में देखा जा सकता है
  • JSON output डिफ़ॉल्ट रूप से compact format में होता है, और -p option से pretty format इस्तेमाल किया जा सकता है
  • -y या --yaml-out option से YAML output भी दिया जा सकता है

Supported parsers और उपयोग के उदाहरण

  • सपोर्टेड targets में CLI commands, फ़ाइल फ़ॉर्मैट्स और string parsers शामिल हैं
  • README की parser list में dig, ls, ping, ps, netstat, ifconfig, csv, xml, yaml, /etc/hosts, /etc/passwd, /proc/, systemctl, git log, jwt, url, semver, और x509 से संबंधित फ़ाइलें शामिल हैं
  • example outputs दिखाते हैं कि अलग-अलग inputs को JSON structures में कैसे बदला जाता है
    • arp output को address, hardware type, MAC address, और interface fields में बदला जाता है
    • CSV फ़ाइल को header को key मानने वाले object array में बदला जाता है
    • /etc/hosts को IP और hostname arrays में बदला जाता है
    • ifconfig को interface name, MTU, IPv4/IPv6 addresses, packet·byte counters आदि वाले object में बदला जाता है
    • ping को packet send/receive counts, loss rate, round-trip time, और response list वाले object में बदला जाता है
  • Ansible में इसे community.general collection के filter plugin के रूप में इस्तेमाल किया जा सकता है

Installation

  • jc को कई तरीकों से install किया जा सकता है
    • pip3 install jc
    • OS package repositories
    • GitHub Releases के architecture-specific binaries
  • OS package installation examples में ये शामिल हैं
    • Debian/Ubuntu: apt-get install jc
    • Fedora: dnf install jc
    • openSUSE: zypper install jc
    • Arch: pacman -S jc
    • macOS: brew install jc
    • FreeBSD: ports के जरिए installation
    • Ansible filter plugin: ansible-galaxy collection install community.general
    • FortiSOAR connector: FortiSOAR Connector Marketplace से installation

मुख्य options

  • -a / --about: jc और parser information को JSON या YAML में output करता है
  • -d / --debug: parsing समस्या होने पर trace messages output करता है, और -dd अधिक detailed debugging देता है
  • -h / --help: help output करता है, और jc -h --parser_name से parser docs देखी जा सकती हैं
  • -M / --meta-out: timestamp, parser name, magic command, magic command exit code जैसी metadata को output में जोड़ता है
  • -q / --quiet: parser warning messages को suppress करता है, और -qq streaming parser errors को ignore करता है
  • -s / --slurp: multi-line input को array में समेटता है
  • -u / --unbuffer: output buffering को disable करता है
  • -B / --bash-comp, -Z / --zsh-comp: Bash या Zsh completion script generate करता है

Slice और Slurp

  • Slice Python slicing जैसी START:STOP syntax से input lines के सिर्फ एक हिस्से को process करता है
  • उदाहरण के लिए, header और footer वाली table में jc 1:-1 --asciitable या jc 1:4 --asciitable से बीच का data ही JSON में बदला जा सकता है
  • positive और empty slice सबसे memory-efficient होते हैं, जबकि negative slice ज्यादा memory इस्तेमाल करते हैं
  • Slurp single-line input लेने वाले string parsers में कई items को एक साथ array के रूप में output करने की सुविधा है
    • उदाहरण: हर line में एक IP address वाली फ़ाइल को jc --slurp --ip-address से process किया जा सकता है
  • /proc magic syntax कई files चुने जाने पर अपने-आप slurp सपोर्ट करती है
    • कई /proc files convert करने पर हर result object में _file field जुड़ता है, ताकि पता चल सके कि वह किस file से आया है
  • --meta-out और slurp को साथ इस्तेमाल करने पर result array और _jc_meta object में wrapped structure output होता है

Exit codes और metadata

  • jc के अंदर होने वाली fatal errors exit code 100 बनाती हैं, अन्यथा यह 0 return करता है
  • magic syntax इस्तेमाल होने पर jc, parse किए जाने वाले program का exit code save करता है और उसे jc exit code में जोड़ता है
    • अगर ifconfig का 1 और jc का 0 है, तो combined exit code 1 होगा
    • अगर ifconfig का 0 और jc का 100 है, तो combined exit code 100 होगा
    • अगर दोनों में error है, तो combined exit code 101 होगा
  • magic syntax में --meta-out या -M इस्तेमाल करने पर _jc_meta object में magic command information और exit code शामिल होते हैं

Colors और environment variables

  • JC_COLORS environment variable से key name, keyword, number, और string colors तय किए जा सकते हैं
    • इसका format JC_COLORS=<keyname_color>,<keyword_color>,<number_color>,<string_color> है
    • color values में black, red, green, yellow, blue, magenta, cyan, gray, brightblack, brightred, brightgreen, brightyellow, brightblue, brightmagenta, brightcyan, white, default में से कोई एक हो सकता है
  • NO_COLOR environment variable सेट करने पर color output disable हो जाता है
  • -C option, NO_COLOR environment variable और -m option से ऊपर प्राथमिकता लेकर color output force करता है

Streaming parsers

  • ज़्यादातर parsers पूरा STDIN memory में पढ़कर parse करते हैं और फिर JSON document को serialized form में output करते हैं
  • कुछ streaming parsers input मिलते ही line-by-line process करते हैं और JSON Lines या NDJSON में output देते हैं
    • उदाहरण: ls-s, ping-s
    • इससे ls -lR / जैसे बड़े command outputs की memory usage बहुत कम हो सकती है, और कुछ मामलों में processing तेज भी हो सकती है
  • streaming parsers को magic syntax के साथ इस्तेमाल नहीं किया जा सकता
  • लंबे समय तक चलने वाले pipelines में parsing error से pipe न टूटे, इसके लिए -qq या Python में ignore_exceptions=True इस्तेमाल किया जा सकता है
    • सफल lines में _jc_meta.success: true शामिल होता है
    • असफल lines में _jc_meta.success: false, error, और line fields शामिल होते हैं
  • अगर pipes के बीच operating system buffering की वजह से output देर से दिखे, तो -u से unbuffered output इस्तेमाल किया जा सकता है
    • हालांकि बड़े data streams में unbuffered output धीमा हो सकता है
  • Python में streaming parsers iterable input लेते हैं और iterable object return करते हैं, जिससे lazy processing संभव होती है

Parser plugins

  • local parser plugin को app data directory के jc/jcparsers folder में रखा जा सकता है
    • Linux/unix: $HOME/.local/share/jc/jcparsers
    • macOS: $HOME/Library/Application Support/jc/jcparsers
    • Windows: $LOCALAPPDATA\\jc\\jc\\jcparsers
  • plugin standard Python module files होते हैं
  • jc/parsers/foo.py या jc/parsers/foo_s.py को template की तरह इस्तेमाल किया जा सकता है
  • plugin filename एक valid Python module name होना चाहिए, letter से शुरू होना चाहिए, और उसमें सिर्फ alphanumeric characters और underscore होने चाहिए
  • local plugins डिफ़ॉल्ट parsers को override कर सकते हैं

Locale, timezone, और compatibility

  • सबसे अच्छे results के लिए LC_ALL को C या en_US.UTF-8 पर set करने की सलाह दी जाती है
  • कुछ पुराने systems में C locale UTF-8 encoding सपोर्ट नहीं करता, इसलिए UTF-8 output ASCII और \\u escape sequences में downgrade हो सकता है
  • कुछ parsers calculated epoch timestamp fields जोड़ते हैं
    • अगर field name में _utc suffix नहीं है, तो उसे local timezone पर आधारित naive timestamp माना जाता है
    • अगर command output text में UTC timezone detect हो जाए, तो timezone-aware timestamp बनाया जाता है और key name में _utc suffix जुड़ता है
    • UTC के अलावा अन्य timezones aware timestamp के रूप में supported नहीं हैं
  • कुछ parsers platform-specific outputs convert करते हैं, इसलिए unsupported platform पर चलाने पर warning दिखाई जाती है
  • unsupported platform पर भी दूसरे systems के output files parse किए जा सकते हैं; इस स्थिति में -q या Python के quiet=True से warnings suppress की जा सकती हैं
  • tested platforms में Centos 7.7, Ubuntu 18.04/20.04, Fedora32, macOS 10.11.6/10.14.6, NixOS, FreeBSD12, Windows 10, Windows 2016 Server, और Windows 2019 Server शामिल हैं

संबंधित पढ़ाई

1 टिप्पणियां

 
GN⁺ 2023-12-10
Hacker News की रायें

  • FreeBSD में यह समस्या कुछ हद तक libxo से हल होती है:
    $ ps --libxo=json | jq की तरह structured output मिल सकता है
    यह परफेक्ट नहीं है; ls support था लेकिन किसी कारण हटा दिया गया, और सभी utilities भी इसे support नहीं करतीं
    jc कई command parsers देने वाला एक बेहतरीन अस्थायी हल लगता है, लेकिन इसकी सीमा यह है कि यह ऐसे text output को parse करता है जिसे मूल रूप से parsing के लिए design नहीं किया गया था
    अच्छा होगा अगर utilities एक common flag के साथ structured output दें; PowerShell जैसा default Unix/Linux के लिए ज़्यादा हो सकता है, लेकिन सिर्फ standard --json flag भी बड़ी प्रगति होगी
    https://wiki.freebsd.org/LibXo
    https://reviews.freebsd.org/D13959

    • PowerShell JSON से एक कदम आगे जाकर असली mutable objects को support करता है
      मेरी समझ से यह सिर्फ structured data pass नहीं करता, बल्कि pipeline में opaque objects बहने देता है और पिछली stage पर लौटकर methods भी call किए जा सकते हैं: https://learn.microsoft.com/en-us/powershell/module/microsoft.powershell.core/about/about_methods?view=powershell-7.4
      jc, libxo जैसे wrappers और https://www.nushell.sh/ जैसी experimental shells भी अच्छी हैं, लेकिन ये executable methods वाले objects से ज़्यादा data transfer पर ध्यान देती हैं
      structured data अभी भी Unix-जैसा लगता है, और अगर सचमुच objects चाहिए हों तो शायद Python या Ruby चलाने का समय है
      shell चाहे जितनी शानदार हो और उसमें programming features हों, यह जानना ज़रूरी है कि shell script से कब किसी proper programming language पर जाना चाहिए
    • मूल पोस्ट के लेखक की blog post इसी बारे में है
      jc को अब तक इस भूमिका को भरने वाले tool के रूप में पेश किया गया है, और ऐसा लगता है कि Unix tools में -j/--json support व्यापक होने तक इसे एक stepping stone के रूप में सोचा गया है
      https://blog.kellybrazil.com/2019/11/26/bringing-the-unix-philosophy-to-the-21st-century/
    • SerenityOS में भी इसी तरह /proc के नीचे की entries unstructured text files नहीं बल्कि JSON data लौटाती हैं
      इससे भी ज़्यादा structured समाधान यह हो सकता है कि ELF से data structures export किए जा सकें, फिर उन data structures को terminal output के लिए serialize किया जाए, और उसके बाद user अपनी पसंद के JSON, YAML जैसे formats में उन्हें output या process करे
    • Libxo सिद्धांत में शानदार है, लेकिन ऐसा लगता है कि application को structure libxo को देकर formatting सौंपने के बजाय हर output format के लिए logic खुद implement करना पड़ता है
      सही utility याद नहीं, शायद iostat था, और वह JSON output lines को string interpolation से format कर रहा था, जिससे कुछ flag combinations में output पूरी तरह टूट जाता था
      अब स्थिति बेहतर है या नहीं, पता नहीं, लेकिन spacing options होने पर मुझे JSON lines जैसे किसी format की उम्मीद थी
      usability के लिहाज़ से PowerShell और kubectl libxo से कहीं आगे लगते हैं
    • Libxo FreeBSD base system में शामिल है, लेकिन इसे सामान्य रूप से भी इस्तेमाल किया जा सकता है
      https://github.com/Juniper/libxo
      https://libxo.readthedocs.io/en/latest/

  • आइडिया सच में बहुत अच्छा है, लेकिन maintenance के बारे में सोचकर चिंता होती है
    versions, command flags के हिसाब से output में बदलाव वगैरह देखें तो यह maintenance hell जैसा लगता है; असली इस्तेमाल में कुछ cases में यह अच्छा चलेगा, लेकिन basic cases से आगे जाते ही इसका नया-पन जल्दी खत्म हो जाएगा
    ऊपर से tool options में -- का उपयोग भी बहुत अच्छा नहीं लगता
    अगर हर नए parser के लिए नया flag चाहिए, तो help या man page हज़ारों lines की हो सकती है

    • अगर इसे ऐसे shim की तरह देखें जिसकी जिम्मेदारी command-line utilities के धीरे-धीरे JSON output support करने के साथ कम होती जाएगी, तो यह ठीक लगता है
      अगर कोई utility अपना JSON export support करने लगे, तो बाद में यह tool उसी feature को delegate कर सकता है
    • दस्तावेज़ में नीचे पढ़ें तो jc ls की तरह command के आगे jc लगाकर भी इस्तेमाल किया जा सकता है
      --cmd parameter conversion से पहले data को process करने देता है, इसलिए यह उल्टा अच्छा idea है
      उदाहरण के लिए, conversion से पहले आप list को grep करना चाह सकते हैं
      maintenance के नज़रिए से भी, अगर base Unix commands का output बहुत बदल जाए तो यह tool ही नहीं बल्कि अनगिनत scripts भी टूटेंगी, इसलिए दूसरे binaries के updates की वजह से यह शायद उतनी बार नहीं टूटेगा जितना लगता है
    • दूसरी तरफ, मन थोड़ा उलझा हुआ है
      एक अच्छी तरह maintain किया गया shared parser bundle जगह-जगह बिखरे ad-hoc output parsers से बेहतर है, लेकिन अगर मैं कोई complex काम करने के लिए सीधे JSON output चाहता हूँ, तो parsing खुद समस्या में और इज़ाफ़ा न करे, यही चाहूँगा
      इसे आराम से इस्तेमाल करने के लिए शायद मुझे जिन चीज़ों का उपयोग करना है, उन सबके लिए अतिरिक्त test cases के PR भेजने पड़ेंगे
      वैसे भी वे tests मुझे खुद लिखने ही पड़ते
    • इसके लिए collaboration चाहिए
      लोगों को जिन tools की parsing जानकारी चाहिए, वह submit करनी होगी, और users को भी उसे आसानी से up-to-date बनाए रखना होगा
    • यह LLM के बेहतर उपयोगों में से एक है, क्योंकि इसने unstructured text को structured objects में बदलने की अच्छी क्षमता दिखाई है

  • Nushell का तरीका अलग है, लेकिन ज़्यादातर वही लक्ष्य हासिल करता है: shell commands का structured data
    आम तौर पर shell खुद ही यह भूमिका निभाता है
    http://www.nushell.sh/

    • Nushell में from json ऑपरेशन है, इसलिए यह JC के साथ वास्तव में अच्छी तरह मेल खाता है
      मैंने पहले Nushell की कुछ अच्छी features दिखाने वाला एक वीडियो रिकॉर्ड किया था, और लगभग 19 मिनट पर jc के साथ इसे जोड़ने की बात की है: https://www.youtube.com/watch?v=KF5dtxVsn1E
    • Nushell की पहली घोषणा के बाद से मैं इसे कभी-कभी देखता रहा, लेकिन एक-दो महीने पहले ही आखिरकार इसकी असली बात ठीक से समझ आई
      मैं एक script लिखना चाह रहा था जो किसी खास pattern से मेल खाने वाली directories में files को देखे और जिनकी modification time एक-दूसरे से 10 मिनट के भीतर हो उन्हें हटा दे; तभी याद आया कि Nushell ऐसे कामों के लिए अच्छा है
      थोड़ी देर इस्तेमाल किया तो आखिरकार बात समझ आ गई, और अब मैं इसका प्रशंसक हो गया हूँ
      unstructured data भी अगर records की list जैसी शक्ल में बदलकर प्रोसेस किया जा सके तो बहुत ताकतवर हो जाता है

  • एक मायने में यह शानदार है कि files हर जगह हैं; यही Unix का वादा है, और Plan 9 में यह और भी आगे बढ़ा हुआ रूप लेता है
    लेकिन unstructured files होना, या हर file का अलग format होना, उतना ही बाधा भी बनता है
    सिर्फ awk जैसी चीज़ों से एक nginx log file पार्स करने की कोशिश भी झंझट भरी हो सकती है
    बड़ी कमियों में से एक यह है कि Linux user space में बड़े पैमाने पर system rewrite या design change लागू करना मुश्किल है
    मुझे ज़्यादा समझदार shell चाहिए, मुझे files भी पसंद हैं, और बगल में awk की किताब भी रखी है, लेकिन अब लगता है कि data parsing में गंभीर सुधार की ज़रूरत है
    जैसे programs खुद तय कर लेते हैं कि color output render करना है या नहीं, वैसे ही अगर वे structured output भेजना है या नहीं यह भी तय कर सकें तो अच्छा होगा

    • समस्या का एक हिस्सा यह है कि command output user interface और API दोनों होता है
      किसी भी text UI को API की तरह इस्तेमाल किया जा सकता है, इसलिए इंसानों के लिए पढ़ने लायक text को प्राथमिकता मिलती है
      इसीलिए shell scripting कुछ हद तक third-party browser extension बनाने जैसी लगती है
      आप देखते हैं, अंदाज़ा लगाते हैं, फिर उसी अंदाज़े के आधार पर जल्दी-जल्दी parser जोड़ते हैं और उम्मीद करते हैं कि सब चल जाए
      machine-readable content के लिए तीसरा standard output होना अच्छा रहेगा
      terminal इसे default रूप से प्रिंट न करे, लेकिन pipe करने पर यही output pipe हो; यह JSONL हो; और manual page contract को स्पष्ट करे
      तब standard output इंसानों के लिए रखा जा सकता है, और parsing एक ऐसा काम होगा जिसे इस समझ के साथ किया जाएगा कि वह संभव तो है, लेकिन नाज़ुक है
      बेशक यह पूरी तरह backward compatibility तोड़ने वाला विचार है, और अगर अवास्तविक तरीके से CLI को नींव से दोबारा गढ़कर modernize करना हो, तो बदलने की मेरी सूची बहुत लंबी है
    • आधी सदी पहले कई काफ़ी अच्छे ideas आए थे, लेकिन बहुत से लोग उन्हें सुधारने की चीज़ नहीं बल्कि किसी सिद्धांत की तरह मान लेते हैं; यह निराशाजनक है
      सुधार हासिल करना भी वाकई बहुत मुश्किल है, और Lennart जैसा कोई व्यक्ति जब दशकों पुराने जमे हुए कचरे को हटाने की कोशिश करता है, तो तुरंत ड्रामा शुरू हो जाता है
      JSON भी अभी परफेक्ट नहीं है
      JSON ठीक-ठाक अच्छा idea है, लेकिन अगर इसे सही ढंग से करना हो तो ऐसा format चाहिए जो data types जैसी चीज़ों को व्यक्त कर सके
      यह PowerShell के अधिक करीब होना चाहिए, ताकि numbers को numbers की तरह संभाला जा सके और $a - $b से dates का अंतर निकालने जैसी शानदार चीज़ें की जा सकें
    • इससे आसान सुधार यह होगा कि सभी CLI tools में command-line argument के रूप में JSON output लागू किया जाए
      अच्छा होगा अगर GNU coreutils में यह हो जाए
    • PowerShell का विकल्प हमेशा मौजूद है
      समस्या यह है कि वह .NET और objects में बहुत गहराई से जड़ा हुआ है, इसलिए किसी भी platform पर मौजूदा native commands के साथ उसका integration बहुत कठिन हो जाता है
    • server logs parsing में यह अफ़सोस की बात है कि logstash जैसी चीज़ों से functionality अलग नहीं की जा सकती
      क्योंकि वे मूल रूप से पहले से वही काम कर रही हैं
      फिर भी लगता है कि अंतिम लक्ष्य यही होगा कि ऊपर की layers के tools इसकी value समझें और खुद structured output देना शुरू करें

  • बढ़िया
    मैं sensible JSON output को support करने वाले CLI tools का ज़ोरदार समर्थक हूँ, और https://github.com/WireGuard/wireguard-tools/blob/master/contrib/json/wg-json जैसी चीज़ें और PowerShell का |ConvertTo-Json admin/monitoring automation का बड़ा हिस्सा हैं
    लेकिन यहाँ sensible शब्द बहुत काम कर रहा है, और हक़ीक़त तो हक़ीक़त है
    LSI/Broadcom StorCLI में command के अंत में J जोड़ने वाले तरीके, या PowerShell के COM-hiding wrappers जैसी चीज़ें तकनीकी रूप से JSON तो हैं, लेकिन नतीजा इतना बेहूदा जटिल या बेकार होता है कि अंत में फिर “चलो plain-text output पर regex चला लेते हैं” जैसे जुगाड़ पर लौटना पड़ता है
    फिर भी मैं इसे ज़रूर देखूँगा
    अगर पहला उदाहरण dig output parsing उन चीज़ों का प्रतिनिधि है जिन्हें स्थिर तरीके से किया जा सकता है, तो यह काफ़ी दिलचस्प होगा

  • मेरे हिसाब से jc dig example.com ही default syntax होना चाहिए
    dig example.com | jc --dig में output को parse करने के लिए पिछले command के flags और parameters का बाद में अंदाज़ा लगाना पड़ता है

  • यह कि हर output एक object है, PowerShell की उन बातों में से एक है जो मुझे सबसे ज़्यादा पसंद हैं
    जब भी मुझे bash scripts लिखनी पड़ती हैं, इसकी कमी महसूस होती है

  • जिसने इसे maintain करने की ज़िम्मेदारी ली है, उसे सलाम

    • और जिसने इस tool को इस्तेमाल करते हुए इसकी गलत धारणाओं का सीधे सामना करने का फैसला किया, उसे भी सलाम
    • version issues को कैसे संभालेंगे, यह जानने की उत्सुकता है
      aws s3 ls | jc --aws=1.2.3 जैसी चीज़ तो एक दुःस्वप्न होगी
    • यह अच्छी बात उठाई गई है
      इससे Linux या Unix के file program और उसे maintain करने वाले नायकों की याद आती है
    • सिद्धांत रूप में अगर plugins जैसी चीज़ें load की जा सकें, जैसे उन्हें अलग shell commands के रूप में रखा जाए, तो maintenance effort का कुछ हिस्सा plugin authors को सौंपा जा सकता है

  • यह जानने की जिज्ञासा है कि कौन-कौन से modern Unix command-line tools --json option स्वीकार करते हैं
    ऐसी जानकारी इस repository में जोड़ना भी उपयोगी हो सकता है

    • FreeBSD में libxo के ज़रिए लगभग हर चीज़ practically supported है
    • कोई सूची तो नहीं है, लेकिन ifconfig का modern replacement ip JSON support करता है
      lldpctl भी support करता है
      Ansible सिस्टम की details को facts नाम के JSON के रूप में देता है, और automation को उसी का उपयोग करने के लिए डिज़ाइन किया गया है
    • lsblk में --json flag है और यह काफ़ी जानकारी दे सकता है
      lsblk --json --output-all आज़मा सकते हैं
      जब scripts को सिस्टम की disks और partitions inspect करनी हों, तब यह बहुत उपयोगी है
    • Wireshark का CLI companion tool TShark -T json flag के साथ इसे support करता है
    • शायद यह इच्छित जवाब न हो, लेकिन AWS CLI भी है

  • दिलचस्प project है
    लेकिन मुझे लगा था कि पहले चरण के parser के रूप में textfsm जैसी किसी चीज़ का उपयोग होगा
    textfsm का उपयोग network equipment के CLI output को parse करने में काफ़ी होता है
    https://github.com/google/textfsm