Les plus grands programmes Shell au monde

 (github.com/oils-for-unix)
4 points par GN⁺ 2024-12-09 | 1 commentaires | Partager sur WhatsApp
  • Ce wiki recense non pas simplement de longs scripts, mais une liste de programmes Shell « substantiels », écrits à la main et exploitant même des structures de données et des algorithmes
  • Le seuil retenu est en général de plus de 5K lignes, et les scripts générés automatiquement ou les scripts de completion répétitifs sont exclus des exemples principaux
  • Parmi les cas emblématiques figurent ble.sh avec 87K lignes, kalua avec environ 56K SLoC/lignes, Relax-and-Recover avec 35K lignes, nb avec 26K lignes et winetricks avec 22K lignes, bien au-delà de l’image habituelle que l’on se fait des scripts Shell
  • La liste couvre largement des outils réellement utilisés : éditeur de ligne interactif, addon OpenWRT, débogueur Bash, outil de test TLS, implémentation de Kubernetes, outils de sauvegarde et de restauration, outil d’émission de certificats, moniteur de ressources, etc.
  • Les tests OSH « Wild » parsèment plus d’un million de lignes de Shell, mais il s’agit surtout de petits programmes et de définitions répétitives de paquets de distributions, à distinguer des grands programmes Shell

Qu’est-ce qu’un « grand programme Shell » ?

  • Ici, « biggest » ne désigne pas simplement le nombre brut de lignes, mais plutôt quelque chose de « substantial », c’est-à-dire d’une ampleur et d’une complexité réelles
  • Sont inclus en priorité des scripts Shell écrits à la main
    • les gros scripts générés par autoconf sont traités comme une exception
    • des artefacts générés automatiquement, comme un script coreutils de 70K lignes, ne sont pas considérés comme de grands programmes Shell au sens substantiel
  • Une attention particulière est portée aux programmes Shell qui utilisent des structures de données et des algorithmes
    • bash-completion est sophistiqué, mais son organisation répétitive — avec des fonctions relativement simples pour chaque commande d’une machine Unix — en fait presque un contre-exemple
  • La ligne de base approximative est de plus de 5K lignes
    • les plus grands programmes Shell non répétitifs se situent généralement dans la plage des 10K+ lignes
    • aucun programme dépassant 100K lignes n’a encore été identifié

Exemples des plus grands programmes Shell

  • akinomyoga/ble.sh : 87K lignes au total, 63K LoC hors commentaires
    • il s’agit d’un éditeur de ligne interactif de type fish, écrit en bash pur
    • le fichier principal out/ble.sh compte 39K lignes, 29K LoC hors commentaires, et avec les fichiers modules l’ensemble dépasse 80K lignes
    • il contient beaucoup de commentaires en japonais
    • il lit les octets bruts du terminal via bind -x, les décode lui-même avec plusieurs machines à états explicites, puis maintient et met à jour un drawing buffer
    • il inclut aussi du timing et des « fibers »
    • des détails sur le parser Shell figurent dans les commentaires de l’issue 663, et le projet est considéré comme l’un des usages les plus sophistiqués de structures de données en Shell
    • des tentatives existent pour l’exécuter sur OSH, et la majeure partie est parsée
    • le premier commit faisait 8K lignes / 6K LoC en 2015, même si le développement réel a commencé en 2013
  • kalua : addon OpenWRT écrit en shell POSIX, avec environ 56K SLoC/lignes
  • Relax-and-Recover : outil de sauvegarde et de restauration de 35K lignes, 24K LoC
    • le premier commit git date de mars 2009, avec alors 4K lignes / 3K LoC
  • xwmx/nb : nb lui-même représente 26K lignes, 22K LoC en bash
    • si l’on compte les tests bats en bash, cela ajoute 91K lignes et 61K LoC
    • le premier commit date de 2014, et l’historique de commits soutenu commence au début de 2016
  • vegardit/bash-funk : bibliothèque Bash de 27K lignes au total, 24K LoC
    • le premier commit remonte à mai 2017, avec alors 10K lignes / 8K LoC
  • winetricks : script Shell de 22K lignes qui installe divers programmes Windows sous Wine
  • drwetter/testssl.sh : 21K lignes de bash dans un seul fichier
    • semble avoir été écrit à la main
    • a commencé en 2006 à partir de quelques commandes openssl
    • le parsing bute sur l’issue #606
  • rkhunter : programme Bourne shell de 21K lignes, écrit entre 2003 et 2018
  • Simplenetes : présenté comme « Kubernetes in 17K lines of Shell »
    • signalé comme un cas étonnant, mais semble dormant
    • un fil Hacker News est lié
  • inxi 2.3.56 : programme bash de 16K lignes, indiqué comme obsolete
    • forké depuis infobash en 2008
    • infobash faisait alors 889 lignes et avait démarré en 2005
    • à partir de la v2.9, inxi a été remplacé par une implémentation en Perl
  • bashdb : débogueur Bash écrit en bash, d’environ 14K lignes
  • romkatv/powerlevel10k : le répertoire internal/ contient 12K lignes de scripts zsh
    • s’y ajoutent 8K lignes de config et de helper scripts
    • le premier commit date de 2014
  • dylanaraps/neofetch : programme de 10K lignes écrit pour Bash 3.2, affichant des informations système
    • il propose aussi des fonctionnalités intéressantes liées aux images
    • le premier commit date de 2015
  • distrobox : script bash de plus de 7K lignes permettant d’utiliser n’importe quelle distribution Linux dans le terminal
  • acme.sh : script Shell de 8K lignes pour émettre et renouveler des certificats

Implémentations remarquables malgré une taille plus modeste

  • bashforth : environ 3 800 lignes ; ce n’est pas énorme, mais il implémente un véritable langage de programmation
    • il contient beaucoup d’espaces et de commentaires
  • yoda : environ deux fois plus petit que bashforth, mais implémente à la fois un interpréteur et un compilateur complets
    • c’est une implémentation du même auteur, vingt ans plus récente, avec davantage de fonctionnalités
    • elle porte le commentaire « What learned you have, unlearn you must! »

Autres programmes Shell notables

  • abcde / A Better CD Encoder : utilisé pour le ripping de CD, avec environ 5.5K LoC
  • thc-segfault : 3.3K LoC, serveur pubnix construit majoritairement en Bash
  • ffmpeg/configure : script configure de FFmpeg, écrit à la main, avec 8.4K LoC
  • ffhevc : wrapper Bash entièrement écrit à la main pour encoder de la vidéo HEVC avec FFmpeg et libx265, avec 4K LoC
  • ffx264 : wrapper Bash entièrement écrit à la main pour encoder de la vidéo H.264/AVC avec FFmpeg et libx264, avec 3.9K LoC
  • h264enc : wrapper Bash entièrement écrit à la main pour encoder de la vidéo H.264/AVC avec MEncoder, avec 9.2K LoC
  • bashtop : moniteur de ressources de 5.3K LoC
  • halcyon : système d’installation d’applications Haskell, avec 6.6K LoC
    • code écrit à la main, attentif à la sémantique de bash et à la vérification d’erreurs, dans un style singulier inspiré de la programmation fonctionnelle
  • wordshell : environ 7K lignes de code pour gérer plusieurs sites WordPress en ligne de commande
  • BaCon : environ 10K lignes, convertissant en C des programmes écrits en BASIC
    • il existe une implémentation en BASIC et une autre en script Shell
  • FireHOL : script principal de 9K lignes, avec l’outil FireQOS ajoutant 3K lignes supplémentaires
    • c’est à la fois un langage et un programme d’exécution permettant de créer un pare-feu sécurisé et stateful à partir d’une configuration lisible par un humain
  • gxadmin : 11K LoC, ensemble de requêtes SQL templated et d’utilitaires de traitement de données pour administrer le moteur de workflows scientifiques Galaxy
  • mulle-bashfunctions : bibliothèque de fonctions bash/zsh d’environ 6K lignes
    • utilisée par mulle-sde, lui-même un autre script Shell de 100K lignes
  • x11docker : 11.6K lignes pour exécuter des applications GUI dans des conteneurs docker ou podman

Langages apparentés au Shell et DSL

  • modernish : dialecte shell portable écrit en Shell
  • bats : DSL pour écrire des tests, qui génère du code bash
  • bashible : DSL de type Ansible écrit en bash
  • clash : framework orienté objet compatible avec tous les shells POSIX modernes
  • bash Infinity : bibliothèque standard et framework boilerplate pour bash

Programmes plus petits et écosystème associé

  • Les scripts Alpine, Aboriginal et Debian sont reliés dans un article de blog séparé
  • Les scripts de completion sont volumineux, mais souvent répétitifs
    • la completion Zsh _git représente 8.3K lignes de code
    • git-completion.bash et la completion Docker sont aussi cités en exemple
  • dyne/Tomb : script zsh d’environ 3 500 lignes
  • Basalt : package manager full-featured écrit en Bash pur
    • il ne compte que quelques milliers de lignes, mais s’accompagne d’un riche écosystème comprenant plus de 15 applications et bibliothèques
    • bash-core : bibliothèque qui étend les builtins trap et shopt, et ajoute des stacktraces ainsi que des fonctions de confort essentielles
    • bash-object : bibliothèque en Bash pur pour construire des structures de données arbitrairement imbriquées, avec près de 200 tests
    • bash-json : bibliothèque en Bash pur pour parser et produire du JSON
  • tablespoon/fun/cli-clock : horloge textuelle multiligne écrite en bash
  • json.bash / jb : outil en ligne de commande et bibliothèque bash pour créer du JSON
    • environ 1 700 lignes, avec près de 3 000 lignes de tests

Tests OSH et points d’attention sur l’usage du Shell

  • Les tests OSH « Wild » parsèment plus d’un million de lignes de Shell
    • il s’agit majoritairement de petits programmes et de définitions répétitives de paquets de distribution comme Alpine PKGBUILD ou Gentoo ebuild
  • Shell Programs That Run Under OSH renvoie vers une liste de programmes Shell exécutables sous OSH
  • shell script are dangerous avertit que le Shell est un programme destiné à manipuler les entrailles du système, en console interactive ou non interactive, qu’il est très riche en fonctionnalités, très dangereux, et qu’il n’a pas été conçu pour fabriquer des applications

À lire aussi

1 commentaires

 
GN⁺ 2024-12-09
Commentaires sur Hacker News
  • Il y a environ 25 ans, quand je travaillais chez Sony, on m’a confié un projet pour réparer un système de gestion des commandes très lent et qui plantait souvent
    En creusant, j’ai découvert que l’OMS était un énorme ensemble de scripts shell tournant sur des serveurs AIX, qui avait évolué pendant plus de 10 ans avant d’être laissé à l’abandon. Le code faisait plus de 50 000 lignes, les commandes, paiements et autres informations étaient déplacés entre serveurs via FTP puis analysés avec des combinaisons complexes de sed/awk, et même l’inventaire était suivi dans des fichiers texte puis transféré en FTP
    À l’époque, Perl semblait être le choix le plus pratique pour migrer ce chaos, et j’ai commencé par remplacer les parties les plus simples par de petits modules Perl, avant de refactoriser progressivement l’ensemble dans une application Perl plus grande. En trois mois, j’ai réduit le tout à environ 5 000 lignes de Perl, avec des pannes quasiment disparues et des performances multipliées par 10 à 100. C’était horrible, mais cela reste l’un des travaux les plus satisfaisants que j’aie jamais faits
    • Seulement 3 mois, ça veut dire 800 lignes supprimées par jour en moyenne
      Je me demande si tu as tout lu et compris en profondeur pour reproduire exactement le comportement, ou si tu as jeté de gros blocs pour réécrire selon ce que tu pensais être le bon fonctionnement. Je me demande aussi s’il y avait beaucoup de code standard facile à remplacer rapidement
    • Pour dompter ce genre de monstre en shell script, Perl reste encore aujourd’hui le choix le plus pratique. Tcl est aussi une bonne option
  • Il faudrait que je reparte fouiller dans ce que j’ai écrit autrefois
    Le premier très gros script que j’ai écrit était un programme d’installation d’environ 7 000 lignes pour Enrust CA et l’annuaire, et il devait fonctionner sur presque tous les Unix de l’époque. Ce n’était pas le cas au départ, mais il a grossi au fil des demandes clients
    L’installation elle-même n’était pas très complexe, mais les mises à niveau l’étaient un peu plus, et à l’époque chaque Unix avait des utilitaires légèrement différents. Une bonne partie du script servait à détecter et gérer ces différences, avec en plus de la détection/récupération d’erreurs, des retours en arrière, et une gestion très primitive des paquets et dépendances
    Le Unix de DEC, hors Ultrix, était le plus déroutant. Il m’a fallu plusieurs jours pour comprendre que tous les utilitaires en ligne de commande tronquaient leur sortie à la largeur du terminal, et 30 ans plus tard je m’en souviens encore
    HP-UX introduisait des changements cassants à chaque version, et si je me souviens bien on prenait en charge de 6.5 à 11. Je me rappelle à peine d’Ultrix, de la branche Novell, de NeXT et de Sequent. Je me souviens qu’AIX était bizarre, mais j’ai oublié pourquoi. Les trois ou quatre OS de Sun avaient aussi des différences, mais la documentation était excellente, c’était le top
    • Cette sortie tronquée à la largeur de colonne paraît vraiment étrange. Je me demande s’il est bien certain qu’il n’y avait pas une sorte de défilement horizontal sur le terminal
    • Pour le Unix de DEC, je me demande si tu parles de OSF/1, Digital Unix ou Tru64 Unix
    • Moi aussi je suis monté à quelques milliers de lignes, mais plutôt autour de 2 000. Heureusement je n’avais à prendre en charge que des Red Hat et Ubuntu récents
    • L’an dernier, j’ai lancé wc sur le binaire principal et les bibliothèques auxiliaires d’un projet, et j’en suis à 6 224 lignes à ce jour
      C’était un script qui gérait des pipelines à garantie linéaire sous forme d’un ensemble de conteneurs composés d’adaptateurs de protocole d’entrée, d’un ou plusieurs filtres, et d’adaptateurs de protocole de sortie. L’objectif était que des gens qui ne sont ni experts des conteneurs ni des protocoles puissent l’utiliser, tant qu’ils savent comment ils veulent que les fichiers soient filtrés et transformés au fil du pipeline
      Le binaire de plus haut niveau est structuré avec des sous-fonctions, comme git [ git options ] < git action> [action options] ou systemctl. Il existe même une sous-commande pour ajouter de nouvelles sous-commandes, qui crée les bibliothèques nécessaires et préremplit les définitions de fonctions à partir de modèles. Les modèles contiennent des fonctions d’aide courte et longue, de sorte que cbap -h ou cbap pipeline -h donnent des indications utiles
      Il y a des sous-commandes pour manipuler les images de base, les composants et les pipelines. Une bonne partie du code sert à tester si les définitions de composants et de pipelines sont correctement écrites. Les pipelines utilisent un format presque équivalent à TOML, donc il y a du code pour parser du TOML et convertir des sections en tableaux, tandis que les composants sont de simples fichiers key=value, avec du code pour extraire les parties gauche et droite et valider le schéma
      Comme les composants de pipeline peuvent partager des propriétés, il y a aussi du code pour chercher des propriétés communes dans les fichiers var et etc et pour attribuer des propriétés aux composants. Il y a également beaucoup de fonctions pour manipuler utilisateurs, groupes, répertoires et FIFO conformément aux exigences de sécurité. Quand on configure un pipeline, on crée et applique des utilisateurs, groupes, types SELinux et catégories MCS, puis on les mappe aux fichiers de service qui démarrent les composants, donc il y a aussi beaucoup de manipulation de systemd
      Le plus gros ensemble d’appels concerne sans doute les fonctions qui récupèrent et définissent les propriétés des composants, en pratique les propriétés des conteneurs. Pour chaque propriété, il y a une fonction de lecture, une fonction de validation, et une version inline dans le pipeline, afin de rendre les définitions de conteneurs pilotées par les données aussi flexibles que possible
      Il y a aussi pas mal de code qui s’appuie sur les références Bash pour définir des variables depuis des fichiers, des variables d’environnement et la ligne de commande, afin de permettre des tests rapides. Quatre niveaux d’utilisateurs sont pris en charge, depuis les mainteneurs qui manipulent directement le code lui-même jusqu’aux développeurs qui créent des définitions de composants, aux intégrateurs qui construisent des pipelines à partir de composants, puis aux opérateurs qui installent les pipelines, et le système peut se copier et se packager lui-même pour être livré à chacun de ces niveaux
      Comme le système cible peut être n’importe quel Linux, l’empaquetage et l’extraction se font avec makeself. Par exemple, quand un intégrateur crée une définition de pipeline, cela génère un fichier makeself qui, une fois exécuté sur le système cible, crée tous les utilisateurs, groupes, répertoires et FIFO — c’est-à-dire l’IPC entre composants — applique DAC/MAC, crée les fichiers systemd, copie les images à chaque utilisateur, puis lance le pipeline. Une option de suppression permet aussi d’annuler tout cela
      Il y a aussi un peu de seccomp, mais c’est en pause pour le moment, le temps de trouver le bon équilibre entre liste blanche et liste noire. J’utilise ShellCheck de manière vraiment intensive
  • J’ai déjà envisagé d’écrire en Bash l’interpréteur de mon langage de script Lil pour maximiser la portabilité, mais j’ai vite compris que les calculs en virgule flottante seraient atrocement pénibles
    On ne peut pas supposer que bc/dc soient présents partout, et sur certaines des machines que j’avais, la version de Bash était si ancienne que la prise en charge des tableaux associatifs était très limitée. Comme compromis, j’ai choisi AWK comme cible, et AWK est un langage généraliste bien plus agréable que la plupart des shells, tout en étant présent partout dans un environnement POSIX : https://beyondloom.com/blog/lila.html
    • Moi aussi, en essayant de cibler le shell pour un langage, j’ai appris à mes dépens qu’on ne peut pas compter sur bc/dc dans tous les environnements

J’ai été assez surpris de constater qu’il n’y avait apparemment pas bc/dc dans l’installation Ubuntu de WSL2. Pour les calculs en virgule flottante, j’utilise AWK, mais simplement en l’appelant comme processus externe.

  • Pour avoir écrit et maintenu plusieurs gros programmes Perl au cours de ma carrière, il y a une raison pour laquelle les gens font ça
    Des langages comme Java ou Python conviennent bien quand les interfaces et les formats sont définis et qu’il y a peu d’interactions avec l’OS. Si on utilise JSON/XML/YAML ou qu’on communique avec une base de données, d’autres programmes ou via HTTP(S), on se retrouve dans la situation idéale où ces langages excellent
    Mais dès qu’il faut gérer de gros volumes de texte et des interactions avec l’OS, Java et Python deviennent très pénibles. À l’inverse, Shell/Perl donnent l’impression d’être bien plus simples pour ce type de travail
    Cela couvre presque tous les travaux d’automatisation, les interfaces confuses et non standardisées, les fichiers texte/logs, ainsi que les formats de données non structurés ou insuffisamment structurés. Si on ajoute à cela la rétrocompatibilité de Perl, son large parc installé et ses performances, il n’existe pratiquement pas d’alternative réelle à Perl pour ce genre de tâches
    Cela fait longtemps que je pense que l’une des grandes raisons pour lesquelles les grandes entreprises emploient aujourd’hui des milliers de personnes pour faire manuellement des tâches pourtant facilement automatisables, c’est le recul de l’usage de Perl. Elles essaient de faire de grosses automatisations en Python ou en Java, puis abandonnent vite, rebutées par la verbosité du code à écrire et à maintenir ainsi que par l’ampleur de l’ensemble

    • Je ne suis pas du tout d’accord avec l’idée que « c’est parce que Perl a disparu ». À mon avis, c’est plutôt que la complexité a augmenté, que le travail du spécialiste Perl qui assemblait des scripts est devenu un métier à plein temps, et que Perl seul avait aussi ses limites
      Donc maintenant, il faut probablement en plus du personnel permanent coûteux. Si les utilisateurs finaux sont sur Windows, il existe déjà sur le desktop une option comparable à Perl. C’est PowerShell, qui joue un rôle similaire à Perl
    • J’ai fait de grosses automatisations en code natif. Dans ce genre de cas, c’est l’efficacité qui compte
      Bash+grep a tendance à partir dans une logique où l’on lance un nouveau processus pour chaque ligne de texte. Pour être efficace, il faut minimiser le travail, ce qui implique du traitement par lots et de la déduplication. Cela signifie qu’il faut manipuler les données avec état, en suivant le contexte de déduplication, ce qui est plus simple dans un vrai langage de programmation
      Bash+grep est avantageux pour le traitement de texte sans état, ce qui fait facilement exploser le travail redondant. Une autre manière de réduire le travail consiste à filtrer précisément, et cela s’exprime bien plus proprement de façon impérative dans un vrai langage. grep et les expressions régulières ne conviennent pas du tout à cet usage
      Avec les formats ligne par ligne, git ajoute des échappements pour essayer d’accepter n’importe quoi, mais le support n’est pas cohérent, et on peut désactiver cela en demandant un format de chaîne terminée par un caractère nul avec l’option -z. Bash ne semble pas avoir de moyen de traiter cela, alors que c’est naturel dans un langage suffisamment bas niveau. On peut aussi faire du streaming incrémental sans devoir lancer un nouveau processus pour chaque ligne de texte
      En prime, on peut utiliser une base de code unique pour tout le travail, qu’il y ait du HTTP au milieu ou autre chose
    • D’accord. Python est mon langage préféré, mais pour certains travaux bas niveau liés à l’OS, il peut être pénible ou inefficace. C’est pour cela que j’ai créé https://www.oilshell.org et la page wiki liée ci-dessus
      Voici quelques liens pour donner du contexte. « Êtes-vous en train de réinventer Perl ? » : https://www.oilshell.org/blog/2021/01/why-a-new-shell.html#a...
      « Le shell Unix devrait évoluer comme Perl 5, avec des options de mise à niveau compatibles, et non comme un big bang à la Perl 6/Raku » : https://www.oilshell.org/blog/2020/07/blog-roadmap.html#the-...
      Tour d’horizon de YSH : https://www.oilshell.org/release/latest/doc/ysh-tour.html
    • Depuis que j’ai réalisé que Perl 5 est installé par défaut sur beaucoup de systèmes Linux et BSD, je me demande si je ne devrais pas l’apprendre sérieusement. Il me semble qu’OpenBSD est aussi livré avec Perl installé
      Cela peut ne pas sembler être un gros avantage tant qu’on n’a pas travaillé dans un environnement où l’on ne peut rien installer depuis Internet, voire qui n’a aucun accès à Internet

  • Le problème central quand on écrit de gros programmes en scripts Bash, c’est que le langage de script shell n’a pas été conçu à l’origine pour gérer la complexité
    Il est excellent pour orchestrer de petites commandes et assembler rapidement des outils existants de façon exploratoire, mais dès qu’un script Bash dépasse quelques centaines de lignes, les limites qui rendent la maintenance à long terme et l’évolutivité pénibles commencent à s’enchaîner
    D’abord, il y a le problème de la lisibilité. La syntaxe de Bash peut devenir vraiment opaque à mesure que le projet grossit. Les règles de portée des variables sont subtiles, la gestion des erreurs est primitive, et la manipulation des chaînes devient vite brouillonne. Au final, les mainteneurs perdent du temps à déchiffrer ce qui se passe et ont du mal à modifier quoi que ce soit avec confiance
    Ensuite, il manque des outils robustes. Les langages plus mûrs disposent d’outils d’analyse statique, de linters et de débogueurs qui attrapent tôt les erreurs courantes. En Bash, ces outils sont absents ou très limités. Sans ces garde-fous, les gros programmes Bash sont plus exposés aux erreurs silencieuses, aux régressions et aux bugs subtils
    Les tests posent aussi problème. Il est possible de tester des scripts Bash, mais le processus est généralement plus fastidieux, et cela devient encore plus délicat en présence de logique complexe ou de structures de données. Dès qu’il faut gérer des cas limites comme les espaces dans les noms de fichiers ou des conditions d’environnement inattendues, on se retrouve avec une montagne de code défensif pénible à valider
    Enfin, l’écosystème lui-même n’a pas été conçu pour le développement Bash à grande échelle. On perd la modularité, la gestion de paquets, le traitement standardisé des dépendances et les modèles de développement modernes qu’offrent Python ou Go. Avec le temps, ces manques s’accumulent et finissent par ralentir le travail
    Utiliser Bash pour des tâches ponctuelles ou une automatisation simple, c’est très bien. C’est ce que Bash fait bien. Mais si l’on envisage de construire quelque chose de volumineux, il vaut généralement mieux utiliser un langage pensé pour créer et maintenir des applications complexes, même si la courbe d’apprentissage ou la configuration initiale est un peu plus élevée, car cela fait gagner du temps sur le long terme

  • Utiliser ShellCheck comme linter permet d’éviter beaucoup de pièges courants. Bash/le shell regorge vraiment de pièges et de comportements inattendus, au point que même des auteurs Bash expérimentés peuvent s’y faire prendre
    Cela dit, Bash/le shell occupe une place particulière dans la hiérarchie des langages. Il est presque partout, et il y a de fortes chances qu’il soit encore là dans 30 ans. Si vous voulez un programme qui s’exécute presque partout et qui s’exécutera encore dans 30 ans, le shell/Bash est un bon choix

    • C’est exactement ce que je vis au travail en ce moment. Je suis en train d’explorer un script Bash de plusieurs milliers de lignes
      Ce n’est même pas un script écrit il y a très longtemps, et je ne sais pas pourquoi Bash a été choisi. Le script fonctionne, mais on a l’impression que quelque chose va casser rien qu’en regardant le code de travers
    • Bash/ksh a un argument de débogage/traçage, -x

  • Le plus gros programme shell écrit à la main que j’ai probablement utilisé régulièrement autrefois, c’était abcde (A Better CD Encoder), avec environ 5 500 lignes
    https://abcde.einval.com
    https://git.einval.com/cgi-bin/gitweb.cgi?p=abcde.git;a=blob...

    • Je ne dirais pas que je le connais bien, mais c’était l’un des outils recommandés autrefois sur What.CD. Des amis m’ont aussi dit que Max était recommandé : https://github.com/sbooth/Max
    • Je l’ai déjà utilisé, ça marchait vraiment bien et c’était assez simple à utiliser. Je n’avais absolument aucune idée que tout cela n’était qu’un énorme script shell

  • Beaucoup de ces programmes sont de véritables bijoux. Par exemple, le script rkhunter est bien écrit, présente une marge d’amélioration et constitue aussi une mine d’informations
    Une grande partie de la taille du code de ce type de scripts sert à garantir la présence des utilitaires nécessaires sur différentes plateformes, ainsi que leur comportement conforme aux attentes avec diverses options en ligne de commande. C’est le point le plus pénible pour les auteurs de scripts shell sérieux, plus encore que les signaux et les sous-processus
    Si rkhunter avait été écrit dans un « vrai » langage de programmation, ces informations auraient probablement été moins transparentes. Elles auraient pu être enfouies sous forme d’enregistrements dans des structures de données puis consultées, ou manipulées via plusieurs fonctions sur des structures imbriquées, ou pire encore, par une combinaison de méthodes et de classes. Les journaux auraient aussi pu être découpés en JSON et compressés dans une base de données, accessibles seulement via d’autres méthodes
    Comme les scripts shell ne disposent pas de ce genre d’outils complexes, ils ont plutôt tendance à montrer directement ce qui se passe. C’est aussi pour cela que rkhunter fait office de bonne documentation sur divers exploits et rootkits, sans qu’il soit nécessaire de creuser de fichier en fichier, de structure en structure, ou de base de données en base de données

  • Le client FreeBSD Update représente environ 3 600 lignes de code sh
    Ce n’est pas énorme comparé aux autres programmes mentionnés ici, mais en termes de fonctionnalités, « un outil qui met à jour tout le système d’exploitation », c’est tout de même assez lourd. Le code qui construit les mises à jour est réparti sur plusieurs fichiers, donc le total serait plus élevé

  • « Seulement » 7,1 milliers de lignes, mais l’un de mes préférés est le script acme.sh utilisé pour émettre et renouveler les certificats de Let’s Encrypt
    https://github.com/acmesh-official/acme.sh/blob/master/acme....

  • Parfois, le shell est la seule chose dont on peut garantir la disponibilité, et il existe aussi des situations où la portabilité est indispensable
    Mais en général, si vous avez une énorme application shell, il faudrait peut-être reconsidérer vos choix de vie

    • Le problème, c’est de savoir « quel shell ? ». Bash est loin d’être universel
      Et en plus, on ne peut généralement pas faire grand-chose avec le shell seul : il faut des commandes comme find, grep, sed, cat, head, tail, cut. Ces commandes ont elles aussi leurs propres problèmes de portabilité
      Viser BusyBox est peut-être la meilleure option, mais dès qu’on sort d’un système Linux standard, écrire un script Bourne shell portable devient difficile, voire presque impossible
    • J’entends ce genre d’argument assez souvent, mais je me demande sincèrement à quelle fréquence il arrive réellement d’avoir le compilateur C absent, sans même pouvoir l’installer via le shell
      Avec un compilateur C, on peut déjà sortir du shell, écrire un programme en C que les scripts shell assembleront, ou installer un meilleur langage de script comme Lua. À ce stade, les cas où l’on doit absolument n’utiliser que le shell me paraissent assez niche