दुनिया के सबसे बड़े Shell प्रोग्राम

 (github.com/oils-for-unix)
4 पॉइंट द्वारा GN⁺ 2024-12-09 | 1 टिप्पणियां | WhatsApp पर शेयर करें
  • यह wiki सिर्फ लंबी scripts नहीं, बल्कि हाथ से लिखे गए और data structures व algorithms तक इस्तेमाल करने वाले “वास्तविक” Shell प्रोग्राम्स की सूची है
  • मानदंड आम तौर पर 5K lines से अधिक है, और auto-generated scripts या दोहरावदार completion scripts को मुख्य उदाहरणों से बाहर रखा गया है
  • प्रमुख उदाहरण सामान्य Shell script की धारणा से काफी आगे जाते हैं, जैसे ble.sh 87K lines, kalua करीब 56K SLoC/lines, Relax-and-Recover 35K lines, nb 26K lines, winetricks 22K lines
  • सूची में interactive line editor, OpenWRT add-on, Bash debugger, TLS testing tool, Kubernetes implementation, backup/restore tools, certificate issuance tools, resource monitor जैसे वास्तविक उपयोग के tools व्यापक रूप से शामिल हैं
  • OSH “Wild” tests दस लाख से अधिक lines के Shell को parse करते हैं, लेकिन उनमें से ज्यादातर छोटे programs और दोहरावदार distro package definitions हैं, इसलिए इन्हें बड़े Shell programs से अलग माना जाता है

“बड़ा Shell program” किसे माना जाए

  • यहां “biggest” का मतलब सिर्फ raw line count नहीं, बल्कि “substantial”, यानी वास्तविक scale और complexity है
  • शामिल करने का आधार मूल रूप से हाथ से लिखी गई Shell scripts हैं
    • autoconf द्वारा generate की गई बड़ी scripts को exception माना गया है
    • 70K lines वाली coreutils script जैसे auto-generated artifacts को वास्तविक अर्थ में बड़े Shell programs नहीं माना जाता
  • data structures और algorithms इस्तेमाल करने वाले Shell programs को खास महत्व दिया गया है
    • bash-completion sophisticated है, लेकिन Unix machine के हर command के लिए अपेक्षाकृत simple functions रखने वाली repetitive structure के कारण यह counterexample के करीब है
  • मोटा benchmark 5K lines से अधिक है
    • non-repetitive सबसे बड़े Shell programs आम तौर पर 10K+ lines की range में हैं
    • 100K lines से अधिक का कोई program अभी confirm नहीं हुआ है

सबसे बड़े Shell program के उदाहरण

  • akinomyoga/ble.sh: कुल 87K lines, comments हटाकर 63K LoC
    • pure bash में लिखा गया fish जैसा interactive line editor है
    • main file out/ble.sh 39K lines की है, comments हटाकर 29K LoC, और module files जोड़ने पर कुल 80K+ lines है
    • Japanese comments बहुत हैं
    • bind -x से terminal के raw bytes पढ़ता है, कई explicit state machines से खुद decode करता है, और drawing buffer को maintain/update करता है
    • timing और “fibers” भी शामिल हैं
    • Shell parser से जुड़ी details issue 663 comment में हैं, और इसे Shell में data structures के सबसे sophisticated उपयोगों में से एक माना जाता है
    • इसे OSH में चलाने की कोशिशें हुई हैं और ज्यादातर parse हो जाता है
    • पहला commit 2015 में 8K lines / 6K LoC का था, जबकि असली development 2013 में शुरू हुआ
  • kalua: OpenWRT add-on, करीब 56K SLoC/lines का POSIX shell में लिखा गया
  • Relax-and-Recover: 35K lines, 24K LoC का backup/restore tool
    • पहला git commit March 2009 में था और तब 4K lines / 3K LoC था
  • xwmx/nb: nb खुद 26K lines, 22K LoC के bash में लिखा गया है
    • bats tests को bash में गिनें तो अतिरिक्त 91K lines, 61K LoC हैं
    • पहला commit 2014 में था, और active commit history 2016 की शुरुआत से शुरू होती है
  • vegardit/bash-funk: कुल 27K lines, 24K LoC की Bash library
    • पहला commit May 2017 में था और तब 10K lines / 8K LoC था
  • winetricks: 22K lines की Shell script, जो Wine के तहत कई Windows programs install करती है
  • drwetter/testssl.sh: single file में 21K lines का bash है
    • हाथ से लिखा हुआ लगता है
    • 2006 में कुछ openssl commands से शुरू हुआ
    • parsing के दौरान issue #606 से टकराता है
  • rkhunter: 2003 से 2018 तक लिखा गया 21K lines का Bourne shell program
  • Simplenetes: “Kubernetes in 17K lines of Shell” के रूप में पेश किया गया
    • इसे चौंकाने वाला example बताया गया है, लेकिन dormant state में लगता है
    • संबंधित Hacker News Thread linked है
  • inxi 2.3.56: obsolete के रूप में marked 16K lines का bash program
    • 2008 में infobash से fork हुआ
    • तब infobash 889 lines का था, और infobash 2005 में शुरू हुआ था
    • v2.9 से inxi को Perl implementation से replace किया गया
  • bashdb: Bash debugger, करीब 14K lines के bash में लिखा गया
  • romkatv/powerlevel10k: internal/ directory में 12K lines की zsh scripts हैं
    • इसके अलावा config और helper script 8K lines की हैं
    • पहला commit 2014 में था
  • dylanaraps/neofetch: Bash 3.2 में लिखा गया 10K lines program, जो system information दिखाता है
    • images से जुड़ी दिलचस्प features भी कर सकता है
    • पहला commit 2015 में था
  • distrobox: 7K lines से अधिक की bash script, जो terminal के अंदर किसी भी Linux distribution का उपयोग संभव बनाती है
  • acme.sh: 8K lines की Shell script, जो certificates issue और renew करती है

scale छोटा हो, फिर भी उल्लेखनीय implementations

  • bashforth: करीब 3,800 lines, बहुत बड़ा नहीं लेकिन एक वास्तविक programming language implement करता है
    • whitespace और comments बहुत हैं
  • yoda: bashforth के लगभग आधे size का, लेकिन पूरा interpreter और compiler implement करता है
    • उसी author का 20 साल ज्यादा नया implementation, जिसमें ज्यादा features हैं
    • “What learned you have, unlearn you must!” comment दिया गया है

अन्य प्रमुख Shell programs

  • abcde / A Better CD Encoder: CD ripping में इस्तेमाल होता है और करीब 5.5K LoC है
  • thc-segfault: 3.3K LoC, ज्यादातर Bash से बना pubnix server
  • ffmpeg/configure: FFmpeg की हाथ से लिखी configure script, 8.4K LoC
  • ffhevc: FFmpeg और libx265 से HEVC video encode करने वाला पूरी तरह हाथ से लिखा Bash wrapper, 4K LoC
  • ffx264: FFmpeg और libx264 से H.264/AVC video encode करने वाला पूरी तरह हाथ से लिखा Bash wrapper, 3.9K LoC
  • h264enc: MEncoder से H.264/AVC video encode करने वाला पूरी तरह हाथ से लिखा Bash wrapper, 9.2K LoC
  • bashtop: 5.3K LoC का resource monitor
  • halcyon: Haskell app installation system, 6.6K LoC
    • हाथ से लिखा code जो bash semantics और error checking पर ध्यान देता है, और functional programming से inspired एक अनोखी style रखता है
  • wordshell: करीब 7K lines का code, command line से कई WordPress sites manage करता है
  • BaCon: करीब 10K lines, BASIC में लिखे programs को C में convert करता है
    • BASIC implementation और Shell script implementation, दोनों हैं
  • FireHOL: main script 9K lines, FireQOS tool अतिरिक्त 3K lines
    • human-readable configuration से secure, stateful firewall बनाने वाली language और executable program है
  • gxadmin: 11K LoC, scientific workflow engine Galaxy के management के लिए templated SQL query और data processing utilities का collection
  • mulle-bashfunctions: bash/zsh के लिए करीब 6K lines की function library
    • mulle-sde में इस्तेमाल होती है, और mulle-sde खुद एक और 100K lines की Shell script है
  • x11docker: 11.6K lines, docker या podman containers में GUI applications चलाता है

Shell जैसी languages और DSL

  • modernish: Shell में लिखी portable shell dialect
  • bats: tests लिखने के लिए DSL, और bash code generate करता है
  • bashible: bash में लिखा Ansible जैसा DSL
    • संबंधित comments linked हैं
  • clash: सभी modern POSIX shells के साथ compatible object-oriented framework
  • bash Infinity: bash के लिए standard library और boilerplate framework

छोटे programs और संबंधित ecosystem

  • Alpine, Aboriginal, Debian scripts अलग blog post से linked हैं
  • completion scripts बड़ी होती हैं, लेकिन अक्सर repetitive होती हैं
    • _git Zsh completion 8.3K lines का code है
    • git-completion.bash और Docker completion को भी examples के रूप में बताया गया है
  • dyne/Tomb: करीब 3,500 lines की zsh script
  • Basalt: pure Bash में लिखा full-featured package manager
    • कुछ हजार lines के scale का है, लेकिन 15 से अधिक apps और libraries वाला rich ecosystem है
    • bash-core: trap और shopt builtins को extend करने और stacktrace व जरूरी convenience features जोड़ने वाली library
    • bash-object: pure Bash में arbitrarily nested data structures बनाने वाली library, और लगभग 200 tests हैं
    • bash-json: pure Bash में JSON parse और output करने वाली library
  • tablespoon/fun/cli-clock: bash में लिखी multi-line text clock
  • json.bash / jb: JSON बनाने वाला command-line tool और bash library
    • करीब 1,700 lines, और tests करीब 3,000 lines के हैं

OSH tests और Shell usage से जुड़ी सावधानियां

  • OSH "Wild" Tests दस लाख से अधिक lines के Shell को parse करते हैं
    • ज्यादातर छोटे programs और Alpine PKGBUILD, Gentoo ebuild जैसे repetitive distro package definitions हैं
  • Shell Programs That Run Under OSH OSH में चलने वाले Shell programs की सूची से linked है
  • shell script are dangerous चेतावनी देता है कि Shell system internals को interactive console या non-interactive तरीके से handle करने वाला program है; इसमें बहुत features हैं, यह बेहद dangerous है और applications बनाने के लिए नहीं बना है

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

1 टिप्पणियां

 
GN⁺ 2024-12-09
Hacker News की राय
  • करीब 25 साल पहले Sony में काम करते समय, मुझे एक बहुत धीमे और बार-बार क्रैश होने वाले order management system को ठीक करने का project मिला था
    अंदर जाकर देखा तो OMS AIX server पर चलने वाले विशाल shell scripts के bundle जैसा था, जो 10 साल से ज़्यादा समय तक evolve होने के बाद छोड़ दिया गया था। code 50 हज़ार lines से भी ज़्यादा था, orders·payments·बाकी जानकारी FTP से servers के बीच move होती थी और फिर जटिल sed/awk से parse की जाती थी, और inventory भी text files में track होकर FTP से move हो रही थी
    उस समय इस अफरातफरी को migrate करने के लिए Perl सबसे practical लगा, और मैंने सबसे सरल हिस्सों से शुरू करके उन्हें छोटे Perl modules में बदलना शुरू किया और एक बड़े Perl application के अंदर step-by-step refactor किया। 3 महीनों में पूरा system घटकर करीब 5 हज़ार lines of Perl रह गया, और मूल system की failures लगभग गायब हो गईं जबकि speed 10~100 गुना बढ़ गई। बहुत भयानक था, लेकिन अब तक किए गए कामों में सबसे संतोषजनक कामों में से एक था
    • सिर्फ 3 महीने, यानी रोज़ 800 lines delete करने जैसा
      उत्सुकता है कि क्या आपने original code पूरा पढ़कर गहराई से समझा और behavior को ठीक-ठीक match किया, या बड़े हिस्से फेंककर “इसे ऐसे behave करना चाहिए” सोचकर फिर से लिखा। यह भी जानना चाहूंगा कि क्या बहुत सारा boilerplate था जिसे जल्दी replace किया जा सकता था
    • ऐसे shell script monster को tame करने के लिए आज भी Perl सबसे practical है। Tcl भी अच्छा option है
  • लगता है पहले लिखी चीज़ें फिर से खंगालनी पड़ेंगी
    मेरी पहली सचमुच बड़ी script Enrust CA और directory के लिए करीब 7 हज़ार lines का installer थी, और उसे उस समय के लगभग हर Unix पर चलना था। शुरू से ऐसा नहीं था, लेकिन customer requirements के चलते बढ़ती गई
    installation खुद बहुत complex नहीं था, लेकिन upgrades थोड़े complex थे, और उस समय हर Unix में सभी utilities थोड़ी-थोड़ी अलग थीं। script का बड़ा हिस्सा इन्हीं differences को detect और manage करने वाला code था, और उसमें error detection·recovery·rollback, बहुत primitive package और dependency management भी शामिल था
    DEC का Unix, जो Ultrix नहीं था, सबसे पेचीदा था। यह समझने में कई दिन लगे कि सभी command-line utilities अपना output terminal column width पर काट देती हैं, और 30 साल बाद भी मुझे वह याद है
    HP-UX में हर release में breaking changes होते थे, और अगर मेरी याद सही है तो 6.5 से 11 तक support किया था। Ultrix, Novell वाला, NeXT, Sequent लगभग याद नहीं हैं। AIX अजीब था, यह याद है, लेकिन वजह भूल गया। Sun के तीन/चार OS में भी differences थे, लेकिन manuals शानदार थे और सबसे अच्छे थे
    • वह column width पर कटने वाला output सचमुच अजीब लगता है। उत्सुकता है कि क्या यह पक्का है कि terminal में horizontal scroll जैसी कोई feature नहीं थी
    • DEC के Unix से आपका मतलब OSF/1, Digital Unix, Tru64 Unix में से किससे है, यह जानना चाहूंगा
    • मैं भी कई हज़ार lines तक गया था, लेकिन लगभग 2 हज़ार lines के आसपास। फिर भी अच्छी बात थी कि support सिर्फ latest Red Hat और Ubuntu को करना था
    • पिछले साल एक project के main binary और auxiliary library पर wc चलाया तो अब तक 6,224 lines हैं
      यह एक script थी जो input protocol adapter, एक या अधिक filters, और output protocol adapter से बने containers के bundle के जरिए linear-guarantee pipeline manage करती थी। goal था कि इसे वे लोग भी use कर सकें जो container या protocol experts नहीं हैं, लेकिन जानते हैं कि files को pipeline से गुजरते हुए कैसे filter·transform होना चाहिए
      top-level binary की structure git [ git options ] < git action> [action options] या systemctl जैसी है, यानी sub-functions होते हैं। एक subcommand ऐसा भी है जो नया subcommand add करता है, required libraries बनाता है और templates से function definitions पहले से भर देता है। templates में short/long usage functions हैं, जिससे cbap -h या cbap pipeline -h useful guidance देते हैं
      base images, components, pipelines को manipulate करने वाले subcommands हैं। code का बड़ा हिस्सा components और pipeline definitions सही लिखी गई हैं या नहीं, यह verify करने वाले tests के लिए है। pipeline लगभग TOML जैसी format में है, इसलिए TOML parsing और sections को arrays में convert करने वाला code है; components simple key=value files हैं, इसलिए left-hand side·right-hand side extraction और schema validation code है
      pipeline components properties share कर सकते हैं, इसलिए var और etc files में common properties खोजने और component properties specify करने वाला code भी है। security requirements के हिसाब से user·group·directory·FIFO manipulation functions भी बहुत हैं। pipeline set करने पर users, groups, SELinux types, MCS categories create·apply किए जाते हैं और फिर components start करने वाली service files से map किए जाते हैं, इसलिए systemd manipulation भी बहुत है
      सबसे बड़ा call group शायद component properties, असल में container properties, get और set करने वाले functions हैं। हर property के लिए get function, validation function, और pipeline के अंदर inline version रखा, ताकि data-driven container definition को जितना हो सके flexible बनाया जा सके
      files, environment variables, और command line से variables set करने के लिए Bash references का काफी use करने वाला code भी है, जिससे quick testing संभव है। user levels भी चार तरह के support करता है: code खुद handle करने वाले maintainers, component definitions develop करने वाले developers, components से pipelines बनाने वाले integrators, और pipelines install करने वाले operators; और हर level के user को export करने के लिए यह खुद को copy·package कर सकता है
      target system कोई भी Linux हो सकता है, इसलिए makeself से package और extract करता है। उदाहरण के लिए, integrator अगर pipeline definition बनाता है तो makeself file बनती है, और target system पर run करने पर सभी users·groups·directories·FIFO, यानी components के बीच IPC बनाता है, DAC/MAC apply करता है, systemd files बनाता है, हर user को images copy करता है और फिर pipeline run करता है। delete option से यह सब वापस भी किया जा सकता है
      seccomp भी कुछ हद तक है, लेकिन allow list और block list के बीच balance ढूंढना था इसलिए फिलहाल रुका हुआ है। ShellCheck का सचमुच बहुत thorough use करता हूं
  • मैंने कभी अपने scripting language Lil का interpreter maximum portability के लिए Bash में लिखने के बारे में सोचा था, लेकिन जल्दी ही समझ गया कि floating-point arithmetic बेहद दर्दनाक होगी
    हर environment में bc/dc होगा, यह expect भी नहीं कर सकते, और मेरे पास कुछ machines में Bash version पुराना था, इसलिए associative arrays support भी बहुत limited था। compromise के तौर पर AWK को target बनाया; AWK अधिकांश shells की तुलना में कहीं ज़्यादा सुखद general-purpose language है और POSIX environment हो तो हर जगह होती है: https://beyondloom.com/blog/lila.html
    • मैंने भी language को shell target बनाते हुए खुद जाना कि हर environment में bc/dc expect नहीं कर सकते

मुझे काफ़ी हैरानी हुई कि WSL2 के Ubuntu इंस्टॉल में शायद bc/dc नहीं थे। floating-point calculations के लिए मैं AWK इस्तेमाल कर रहा हूँ, लेकिन वह बस external process के तौर पर call करने वाला तरीका है

  • अपने करियर में कई बार बड़े Perl programs लिखने और maintain करने के अनुभव से कहूँ तो, लोग ऐसा क्यों करते हैं इसकी वजह है
    Java या Python जैसी languages तब अच्छी बैठती हैं जब interfaces और formats defined हों और OS interaction लगभग न हो। JSON/XML/YAML इस्तेमाल करना, या database और दूसरे programs से HTTP(S) के जरिए communicate करना—ऐसी स्थितियाँ इन languages के चमकने के लिए ideal होती हैं
    लेकिन बड़े पैमाने पर text और OS interaction संभालना हो तो Java और Python बहुत तकलीफ़देह बन जाते हैं। इसके उलट Shell/Perl ऐसे कामों में कहीं ज़्यादा आसान लगते हैं
    लगभग हर automation task, गड़बड़ और non-standardized interfaces, text/log files, unstructured या पर्याप्त रूप से structured न होने वाले data formats इसी में आते हैं। इसमें Perl की backward compatibility, व्यापक install base और performance भी जोड़ दें, तो ऐसे कामों के लिए Perl के अलावा practically कोई विकल्प नहीं बचता
    मैं लंबे समय से मानता आया हूँ कि आजकल बड़ी कंपनियों में मामूली रूप से automate किए जा सकने वाले कामों के लिए हजारों लोगों को रखने वाला manual labor इतना ज़्यादा होने की एक बड़ी वजह Perl का कम इस्तेमाल होना है। Python या Java में बड़ा automation task करने की कोशिश करते हैं, फिर लिखने और maintain करने वाले code की verbosity और कुल size देखकर जल्द ही हार मान लेते हैं

    • “ऐसा इसलिए है क्योंकि Perl गायब हो गया” वाली बात से मैं कड़ी असहमति रखता हूँ। मुझे लगता है complexity बढ़ गई है, scripts जोड़ने वाले Perl person का काम full-time job बन गया, और Perl से भी कुछ limits थीं
      इसलिए अब शायद महंगे full-time staff की और ज़रूरत पड़ती है। अगर end user Windows पर है, तो desktop पर पहले से ही Perl जैसा विकल्प मौजूद है। वह PowerShell है और Perl जैसी ही भूमिका निभाता है
    • बड़े automation tasks मैंने native code में किए हैं। ऐसे मामलों में efficiency अहम होती है
      Bash+grep में हर text line के लिए नया process चलाने की दिशा में जाना आसान होता है। efficient बनने के लिए काम को minimize करना पड़ता है, और उसके लिए batch processing और deduplication चाहिए। इसका मतलब है कि deduplication context track करते हुए stateful तरीके से data handle करना होगा, जो किसी proper programming language में आसान है
      Bash+grep stateless text processing के लिए अच्छा है, इसलिए काम का duplication बढ़ना आसान है। काम कम करने का एक और तरीका accurate filtering है, जिसे proper language में imperative तरीके से साफ़-साफ़ express करना आसान होता है। grep और regex इस use case के लिए बिल्कुल fit नहीं हैं
      line-based format इस्तेमाल करने पर git कुछ भी accept करने के लिए escaping जोड़ता है, लेकिन support consistent नहीं है, और -z option से null-terminated string format मांगकर इसे disable किया जा सकता है। लगता है Bash के पास इसे handle करने का कोई तरीका नहीं है, जबकि पर्याप्त low-level language में इसे naturally handle किया जा सकता है। साथ ही हर text line के लिए नया process शुरू किए बिना incremental streaming भी संभव है
      बोनस के तौर पर, बीच में HTTP हो या कुछ और, सभी कामों के लिए एक single codebase इस्तेमाल किया जा सकता है
    • सहमत हूँ। मेरी सबसे पसंदीदा language Python है, लेकिन कुछ खास low-level OS tasks के लिए यह झंझट वाली या inefficient हो सकती है। इसलिए मैंने https://www.oilshell.org और linked wiki page बनाया
      context के लिए कुछ links हैं। “क्या हम Perl को फिर से invent कर रहे हैं?”: https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#a...
      “Unix shell को Perl 6/Raku जैसे big bang की तरह नहीं, बल्कि compatible upgrade options वाले Perl 5 की तरह evolve होना चाहिए”: https://www.oilshell.org/blog/2020/07/blog-roadmap.html#the-...
      YSH tour: https://www.oilshell.org/release/latest/doc/ysh-tour.html
    • जब से मुझे पता चला कि कई Linux और BSD systems में Perl default रूप से installed होता है, मैं Perl 5 को गंभीरता से सीखने पर सोच रहा हूँ। मेरी जानकारी में OpenBSD में भी Perl installed आता है
      जब तक आप ऐसे environment में काम नहीं करते जहाँ internet से कुछ install नहीं किया जा सकता या internet access ही नहीं है, तब तक यह बड़ा advantage नहीं लग सकता

  • बड़े programs को Bash scripts के रूप में लिखने की मुख्य समस्या यह है कि shell scripting language मूल रूप से complexity के लिए design नहीं की गई थी
    छोटे commands को coordinate करने और existing tools को तेज़ी से exploratory तरीके से जोड़ने में यह शानदार है, लेकिन जैसे ही Bash कुछ सौ lines से आगे बढ़ने लगता है, long-term maintenance और scalability को सिरदर्द बनाने वाली limitations एक के बाद एक सामने आती हैं
    सबसे पहले readability की समस्या है। Bash syntax बढ़ने के साथ सचमुच बहुत obscure हो सकता है। variable scoping rules subtle हैं, error handling primitive है, और string handling जल्दी ही messy हो जाती है। नतीजतन maintainers क्या हो रहा है यह decode करने में समय गंवाते हैं, और confident होकर बदलाव करना भी मुश्किल हो जाता है
    अगला मुद्दा robust tools की कमी है। ज़्यादा mature languages में static analysis tools, linters और debuggers होते हैं जो common mistakes जल्दी पकड़ लेते हैं। Bash में ये चीज़ें या तो नहीं हैं या बहुत limited हैं। ऐसी safety checks के बिना बड़े Bash programs silent errors, regressions और subtle bugs के प्रति ज़्यादा vulnerable होते हैं
    testing भी समस्या है। Bash scripts को test किया जा सकता है, लेकिन process आम तौर पर ज़्यादा cumbersome होता है, और complex logic या data structures हों तो और कठिन हो जाता है। filenames में spaces या unexpected environment conditions जैसे edge cases संभालते-संभालते बहुत सारा defensive code बन जाता है जिसे verify करना painful होता है
    अंत में, ecosystem खुद large-scale Bash development के लिए बना ही नहीं है। आप modularization, package management, standardized dependency handling और Python या Go द्वारा दिए जाने वाले modern development patterns खो देते हैं। समय के साथ ये कमियाँ जमा होकर speed कम कर देती हैं
    one-off tasks या simple automation के लिए Bash इस्तेमाल करना ठीक है। वही Bash अच्छी तरह करता है। लेकिन अगर कुछ बड़ा बनाने का इरादा है, तो आम तौर पर ऐसी language इस्तेमाल करना बेहतर होता है जिसे complex applications बनाने और maintain करने के लिए design किया गया हो; शुरुआती learning curve या setup थोड़ा ज़्यादा हो, फिर भी long term में समय बचता है

  • ShellCheck को linter के तौर पर इस्तेमाल करने से कई आम pitfalls पकड़े जा सकते हैं। Bash/shell में सचमुच बहुत सारे traps और unexpected behavior होते हैं, जिनमें अनुभवी Bash लेखक भी फंस सकते हैं
    हालांकि भाषा hierarchy में Bash/shell की जगह अनोखी है। यह लगभग हर जगह मौजूद है और 30 साल बाद भी बने रहने की काफी संभावना है। अगर आप ऐसा प्रोग्राम चाहते हैं जो लगभग कहीं भी चले और 30 साल बाद भी चल सके, तो shell/Bash अच्छा विकल्प है

    • मैं अभी अपनी नौकरी में ठीक यही झेल रहा हूं। हजारों लाइनों वाले Bash में सिर खपा रहा हूं
      यह कोई बहुत पुराने समय में लिखा script भी नहीं है, फिर भी पता नहीं Bash क्यों चुना गया। script चलता है, लेकिन लगता है कि code को गलत तरीके से घूर भर लिया तो कुछ टूट जाएगा
    • Bash/ksh में debugging और tracing argument के लिए -x होता है

  • पहले नियमित रूप से इस्तेमाल किया गया मेरा सबसे बड़ा हाथ से लिखा shell program शायद abcde (A Better CD Encoder) था, करीब 5,500 लाइनों का
    https://abcde.einval.com
    https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git;a=blob...

    • यह तो नहीं कहूंगा कि मैं इसे अच्छी तरह जानता हूं, लेकिन पहले What.CD पर recommend किए जाने वाले tools में से यह एक था। दोस्तों ने बताया था कि Max भी साथ में recommend होता था: https://github.com/sbooth/Max
    • मैंने इसे इस्तेमाल किया है और यह वाकई बहुत अच्छे से काम करता था, इस्तेमाल में भी काफी आसान था। मुझे बिल्कुल अंदाजा नहीं था कि पूरा का पूरा एक विशाल shell script है

  • ऐसे programs में से काफी सचमुच gems हैं। उदाहरण के लिए rkhunter script का code भी ठीक-ठाक है, सुधार की गुंजाइश भी है, और यह जानकारी का खजाना भी है
    ऐसे scripts के code size का बड़ा हिस्सा यह सुनिश्चित करने में जाता है कि अलग-अलग platforms पर जरूरी utilities मौजूद हैं या नहीं, और वे विभिन्न command-line options के साथ उम्मीद के मुताबिक काम करती हैं या नहीं। गंभीर shell script लिखने वालों के लिए यही सबसे दर्दनाक हिस्सा है, signals और subprocesses से भी ज्यादा कठिन
    अगर rkhunter किसी “proper” programming language में लिखा गया होता, तो शायद यह जानकारी कम transparent होती। वह data structures के अंदर records में धकेल दी जाती और lookup होती, या nested data structures के ऊपर कई functions—या उससे भी बुरा, methods और classes के combination—से काम करती। logs भी शायद JSON में टूटकर database में compress हो जाते और किसी दूसरे method से access करने पड़ते
    shell scripts में ऐसे complex tools नहीं होते, इसलिए उल्टा वे अक्सर साफ दिखा देते हैं कि हो क्या रहा है। इसलिए rkhunter कई exploits और rootkits पर एक ठीक-ठाक documentation की तरह भी काम करता है, और file से file, structure से structure, database से database तक खोदते रहने की जरूरत कम पड़ती है

  • FreeBSD Update client करीब 3,600 लाइनों का sh code है
    यहां बताए गए दूसरे programs की तुलना में यह बड़ा नहीं है, लेकिन “पूरे operating system को update करने वाला tool” होने के हिसाब से इसकी functionality काफी वजनदार लगती है। updates build करने वाला code कई files में बंटा है, इसलिए मिलाने पर और ज्यादा होगा

  • “सिर्फ” 7.1 हजार lines का है, लेकिन मेरा पसंदीदा acme.sh script है, जिसका इस्तेमाल Let’s Encrypt से certificates issue और renew करने के लिए होता है
    https://github.com/acmesh-official/acme.sh/blob/master/acme....

  • कभी-कभी केवल shell ही उपलब्ध होने की guarantee दी जा सकती है, और portability बेहद जरूरी होती है
    लेकिन आम तौर पर अगर आपके पास कोई विशाल shell application है, तो शायद आपको अपने जीवन के फैसलों पर दोबारा सोचना चाहिए

    • समस्या यह है कि “कौन सा shell?” Bash universal होने से काफी दूर है
      ऊपर से आम तौर पर सिर्फ shell से बहुत कुछ नहीं हो पाता और find, grep, sed, cat, head, tail, cut जैसी commands चाहिए होती हैं। इन commands की भी अपनी portability problems हैं
      BusyBox को target बनाना सबसे अच्छा हो सकता है, लेकिन सामान्य Linux system से बाहर निकलते ही portable Bourne shell script लिखना मुश्किल या लगभग असंभव हो जाता है
    • ऐसी बातें काफी बार सुनता हूं, लेकिन सच में उत्सुक हूं कि कितनी बार ऐसा होता है कि shell तो हो, लेकिन C compiler न हो, या shell के जरिए C compiler install न किया जा सके
      अगर C compiler हो, तो shell से बाहर निकलकर C programs लिखे जा सकते हैं जिन्हें shell scripts combine करें, या Lua जैसी बेहतर scripting language install की जा सकती है। आज के समय में सिर्फ shell ही इस्तेमाल करना जरूरी हो, ऐसे मामले काफी niche लगते हैं