Marotte ⛧ a écrit 8486 commentaires

Peut-être comme moi, pour être POSIX/portable ?
Peut-être juste que tu n’as pas eu besoin des plus ?

J’ai relu plus ou moins intégralement le manuel de getopt (enfin, du getopt qui est sur ma machine pour être précis), puis exécuté un help getopts.

Sûr que getopt est plus « puissant », mais quelle complexité ! Je crois que ce n’était même pas une histoire d’être POSIX. Juste un désire de m’épargner un tel « merdier » :)

Sinon il y a aussi cette méthode, basique, qu’il faudrait que je teste un jour :

while [[ "$1" =~ ^- && ! "$1" == "--" ]]; do case $1 in
  -V | --version )
    echo "$version"
    exit
    ;;
  -s | --string )
    shift; string=$1
    ;;
  -f | --flag )
    flag=1
    ;;
esac; shift; done
if [[ "$1" == '--' ]]; then shift; fi

(indiquée sur https://devhints.io/bash)

Mais je crois que ça souffre du même souci que la méthode de transformer toutes les options longues en leur équivalent court avant de passer la main à getopts : si une valeur a la forme '-x' ou '--xxx' ça coince. (oui j’ai eu le cas)

Je vais garder mes, maintenant 12 paramètres positionnels et attendre l’éclair de génie qui éclairera mon choix d’une gestion des options satisfaisante ! ^^

Si c’était un script pour le boulot susceptible d’être utilisé par autrui je pense qu’actuellement ce serait getopts avec options courtes uniquement ! À 12 paramètres j’aurais encore de la marge avant d’être bloqué. E j’ai l’impression qu’arrivé à un tel nombre de paramètre faut aller vers des sous-commandes si on veut faire quelque chose un minimum ergonomique.

bash fais aussi bien que python avec un script bash qui consiste à donner un code à manger à cpython

Je pense d’abord aux utilitaires tels que bc ou find, pour ne citer que ceux-là, qui sont définis dans POSIX et pas implémentés en Python. Je considère qu’il font parti du « langage » au sens large. Comme par exemple la bibliothèque "sys" fait partie de Python.

Le shell a été pensé comme un outil destiné à articuler ces autres programmes (les articuler autour du noyau), programmes implémentés en C pour des raisons évidente de performance. Je ne t’apprends rien.

Si tu utilise un binaire écrit en C ou autre langage, ou un script dans un autre langage, serait-ce du python, tu ne cesses pas pour autant de « faire du shell ».

Dirais-tu que tu cesses de faire du Python si tu utilises numpy ?

La différence que je vois c’est qu’en Bash tu appelles rarement d’autres outils « pure bash », au contraire de Python où tu vas trouver des bibliothèques « pure Python » (paramiko par exemple). Mais ça finira toujours par exécuter du C à un moment (cpython et bash étant eux-mêmes implémentés en C), même de l’assembleur si on continue le raisonnement… je ne trouve pas que ce genre de considération a le moindre de sens pour distinguer les deux langages. Ah si, peut-être celle-ci : pour reprendre l’exemple de paramiko, vu que c’est implémenté en Python tu peux modifier ce composant tout en continuant à à « parler Python », tu peux surcharger par exemple. Et voilà comment on en arrive à ce que je disais : des scripts Pythons qui pètent à un moment donné parce que celles et ceux qui l’ont écrit ont surchargé telle ou telle bibliothèque et que les chances que cette surcharge résiste à l’évolution de la bibliothèque s’amenuisent avec le temps, d’où on se retrouve avec des requirements.txt longs comme le bras.

Évidemment on peut faire le « sagouin » tout pareil en shell en faisant reposer son script sur un binaire à telle version ou compilé avec telles options, on peut… mais :

• Bash n’incite pas à cela puisque ça implique soit de compiler du C, soit « faire du Python » ou autre

• Je pense qu’on peut comparer la stabilité de l’interface du binaire ssh, mise en œuvre de référence de libssh (ie: OpenSSL en pratique bien souvent…) et livré avec celle-ci, et la stabilité de l’interface de paramiko, je ne suis pas sûr que paramiko soit aussi figé (quoi qu’aujourd’hui j’ose espérer que c’est plutôt le cas) que le premier.

Donc pour conclure, l’un dans l’autre, Perl, Python et Bash (leurs écosystèmes) ont des différences d’architecture mais fondamentalement aucune : ce sont des langages interprétés, point barre. C’est juste que le « système d’import » de Bash c’est… le systèmes de fichiers ! ;)

tu as pour chacun pleins de façons de t'en sortir ou de te tirer une balle.

D’accord suivant ce que je viens de dire, mais le danger de balle dans le pied n’est pas de même nature je dirais.

Si je sais que je vais partir dans un contexte ou je ne veux pas m'embêter avec les dépendances au déploiement j'utilise des binaires statistiques et je n'ai plus qu'à vérifier la libc.

Et voilà comment un Pythonien se retrouve à faire du shell ! ^^

Avec assez d’ouverture d’esprit je pense d’ailleurs qu’on pourrait utiliser Python ou Perl comme on utilise Bash, comme shell interactif pour les opérations quotidiennes, manuelles, comme regarder le contenu d’un répertoire, supprimer un fichier, etc… Ce qui montre bien que les trois ne sont fondamentalement pas différents.

D’après moi faut clairement faire les deux. Toi comme moi nous nous conterions volontiers de l’appli spartiate sobre et sans fioriture, qui peut fonctionner sur n’importe quel type de terminal, soit-il ancien. Mais d’autres personnes, nettement plus nombreuses, ayant une vision plus profane de la chose informatique auraient l’impression qu’on se moque d’eux avec une appli low-cost pour pays du tiers-monde. Bon nombre d’entre-eux en arriveraient possiblement à questionner le bien-fondé du paiement de leur impôts avec une appli qui ressemble fondamentalement à celle qu’utilisaient leurs parents, avec d’archaïques liste-déroulantes, de ridicules check-boxes, voire même pas le moindre de drag’n’drop possible ni contenu vidéo HD ou 3D texturé !

L’éducation des masses afin qu’elles privilégient le fonctionnel et la stabilité, l’ergonomie, sur l’esthétique et la complexité, la modernité apparente, était déjà perdue il y a 40 ans, minimum. Avant même que le combat commence en fait…

On notera qu’un acteur tel que Google fourni deux versions de son webmail, une pour le marché occidental normal, et une autre pour le tiers-monde et les marginaux occidentaux nostalgiques qui n’ont même pas ni la fibre ni la 5G (aucun des deux !). Dont certains utilisent même parfois des systèmes austères destinés aux serveurs et totalement inadaptés aux utilisateurs finaux, même aux doux rêveurs attachés au charme désuet des desktops ! C’est une erreur majeure de ne pas faire le nécessaire pour ces victimes de la fracture numérique inadaptées à la modernité du futur.

Mais alors quelle alternative pour inciter les utilisateurs a renouveler plus rapidement leurs smartphones et autres terminaux modernes tout en en acquérant de nouveaux afin d’assurer le chiffre d’affaire de de permettre une pénétration assez rapide des nouvelles technologies qui nous sauveront du réchauffement planétaire en transférant toute ou partie de l’humanité dans des métavers à l’abri de ces aléas climatiques d’un autre âge ?

C’est bien beau de vouloir nous renvoyer à l’âge de pierre du Web 3.0 mais faut faire appel aux IA pour réfléchir un peu aux conséquences avant d’avancer ce genre de thèse subversive, anti-science, qui sabote toute notre économie en niant la réalité de la croissance structurelle de long-terme, comme d’autres peuvent émettre l’idée que la Terre serait plate.

Ne sombrez pas dans le complotisme sectaire, exigez la 6G et le casque de réalité virtuelle pour « tous » dès le plus jeune âge.

il y a une petite hype pour réécrire tout en Rust.

Je ne suis pas bien au fait de l’état de la hype chez les développeurs systèmes mais il me paraît plus vraisemblable qu’il s’agissent d’utiliser Rust pour les nouveaux développements, mais sûrement pas de « tout réécrire » en Rust. Que ce soit pour Linux ou pour d’autres logiciels écrits actuellement en C.

Ce que je vais dire est à prendre avec des pincettes et tous les dispositifs de protection intellectuelle nécessaires, parce qu’encore une fois, mon expérience en la matière est insignifiante, mais c’est comme ça que je vois les choses, ce que je peux en dire en ma qualité de méta-expert de renommée inter-régionale.

Rust, de par sa conception plus récente que C (et pas qu’un peu !), présente sans aucun doute des caractéristiques avantageuses par rapport au C, qui traîne une « dette » (notez qu’on dit "legacy" si on veut rester hype) faramineuse, inévitable à son âge vénérable. Mais ce dernier reste une référence absolue pour les langages de « haut-niveau » compilés. C++ n’a rien à voir (aucun jugement de valeur mais l’approche est pour ainsi dire à l’opposé du C), et si Rust semble pouvoir éventuellement se revendiquer digne successeur de C, c’est assez récent. Ce n’est ni Java/Scala, ni Go, ni à ma connaissance aucun autre langage qui peut se targuer d’être au même niveau de justesse en terme d’équilibre entre « langage de haut-niveau », et « langage au plus proche du matériel et sans fioriture telle qu’un ramasse-miette, orientation object ou autre paradigme d’une complexité excessive ». Nonobstant les avantages que chacun d’entre eux peut posséder par ailleurs. C, un langage qui fait peu (tout ce qu’il faut mais pas plus), et qui le fait bien. Un langage exigeant qui ne fait aucun concession sur la performance pour disposer de fonctionnalités destinées à éviter au développeur de se fourvoyer.

Je pense que l’article ci-dessous, datant d’il y a trois mois, bien qu’assurément entaché d’inexactitudes qu’il m’est malheureusement impossible de préciser, dresse un état des lieux relativement représentatif. État des lieux que je résumerai de façon tout aussi relativement inexacte : « Rust dans Linux, on peut dire que ça a dépassé le statut d’idée à discuter, mais pas encore atteint celui d’une évidence indiscutable. »

https://www.zdnet.com/article/rust-in-linux-where-we-are-and-where-were-going-next/

L'entropie est de 44 bits si l'attaquant sait que cette méthode est utilisée, qu'il connaît la liste de mots initiale et le nombre de mots choisis.

Tu as sûrement raison, j’avoue ne pas comprendre d’où viennent les chiffres de 2²⁸ (dans le premier cas) et 2⁴⁴ (dans le second). En tous cas une chose est sûre, me semble-t-il, c’est que dans les deux cas l’entropie est plus faible qu’un mot de passe de la même longueur utilisant le même ensemble de caractères et qui serait vraiment aléatoire. Si on prend par exemple erotic flower stapled ouragan, qu’on fait l’hypothèse que sont utilisé 26 lettres minuscules + espace, qu’il y a comme ici 29 caractères, disons entre 20 et 40, si on sait qu’il s’agit de trois, quatre ou cinq mots de la langue anglaise séparés par des espaces, en terme d’entropie on est bien de deçà de ce qu’on peut atteindre avec les seuls éléments "longueur" et "nombre de figures" si on ne se fixe pas une règle de ce genre, on peut éventuellement avoir un 'xmafhxdgv hcpmmbc f fgsiegnxqw'. Idem pour le premier exemple si on s’abstient de partir d’un mot existant: c0qui!!4g3 vs. vv59yd!c4j. Mais bien sûr c’est là le point du XKCD, on est dans le compromis entre "entropie" et "mémorisabilité".

On devrait peut-être enseigner les méthodes de choix d’un mot de passe vers le CE2-CM1. C’est sûrement aussi, voire plus utile comme compétence que de savoir poser une division ou distinguer un complément d’objet d’un attribut du sujet…

il est possible aussi que ce soit une tambouille du clavier par dessus le système

Je pensais plutôt à ça, avec quelques condensateurs pour que le réglage persiste un moment. Côté driver je n’ai rien de spécial me semble-t-il, mais je ne suis pas très sûr (je suis même passablement largué je dois dire…). C’est "usbhid, hid_generic, hid" qui gère ça non ?

Mais faudrait que je check, tu as p-e raison.

Qu’importe le clavier (même ceux même pas à dix balles), ça fait pas bon ménage avec : les poils d’animaux, la fumette (ça permet de générer autant de dégâts que de la poussière sur dix à cent fois plus de temps), les miettes diverses (inévitables même quand on pense manger proprement devant son matériel) et les liquides (parfois quelques gouttes dans le tissus nettoyant)

je sais bien mais je n’avais jamais observé ce genre de problème avec ceux à membrane. Ceci dit c’est peut-être juste une question que je m’habitue. Le toucher est vraiment différent. Et nettement plus agréable et confortable malgré ces « ratés ».

(longueur d’activation, butée, etc.)

Oui j’ai vu ça, il y a même un code couleur pour les mécanismes et ces paramètres je crois. C’est un domaine très riche, dont la disposition, par exemple n’est qu’un des aspect. Le clavier reste encore l’interface par excellence pour interagir avec un ordinateur. En attendant un moyen de connecter directement l’activité électrique du cerveau. ^^ La voix par exemple ce n’est pas inintéressant mais sûrement pas encore ni assez fiable ni assez versatile. Les dispositifs de pointage aussi bien sûr complètent utilement le clavier (l’infographie au clavier c’est pas ouf par exemple).

Sur AZERTY je crois que le plus surprenant c’est la touche pour ù, lettre utilisée dans un seul mot du français (un mot très important certes, mais bon…) !

Excellente remarque, au temps pour moi !

/dev/sdX et pas se gourer de X !

Assurez-vous d’abord que le BIOS soit à jour.

C’est clairement pas idiot comme conseil mais mettre à jour un BIOS ça peut être encore plus touchy (et risqué par ailleurs). Je ne suis pas sûr que ce soit le meilleur conseil dans son cas. Même si son BIOS n’est pas à jour il devrait quand même pouvoir démarrer sur une clé USB.

rufus/balena, etc

Comment as-tu créé ta clé ? Je ne connais pas Mate mais généralement les images ISO d’installation de distribution sont dites « hybrides », et le plus simple (c’est comme ça que je fais pour ma part), plutôt que d’utiliser un utilitaire particulier, c’est d’utiliser la commande dd.

Évidemment il te faut un OS Linux fonctionnel pour procéder ainsi (quoi que Cygwin entre autre doit le permettre mais là on va faire que s’embrouiller…), mais au moins tu es sûr que l’image est copié « telle que » sur la clé, aucun utilitaire pour venir faire la moindre tambouille.

dd if=le_fichier_dinstallation.iso of=/dev/sdN

Bien sûr attention à quel chiffre tu mets pour "N", sois sûr que ce soit ta clé, et pas ton disque dur ou autre chose, ça ne pardonnerait pas.

Notebook Upgrade Bay
Notebook Hard Drive
Notebook Ethernet

Si tu ne vois pas "USB" dans ce menu, p-e aller voir dans le BIOS si tu n’aurais pas un réglage à faire, si ton image sur la clé est foireuse il devrait quand même pouvoir essayer de booter dessus pour seulement ensuite te dire (en substance) : « Pas d’OS sur le machin. Appuyer la touche n’importe. »

Au pire si tu as moyen de prendre une photo de là où tu es bloqué p-e que quelqu’un pourra t’aider.

Et si tu as la possibilité d’essayer avec une autre clé, fais-le, on sait jamais.

Merci pour l’info, mais à quel moment c’est utile de « smallcaser » ou « uppercaser » une valeur ? C’était ça ma question.

Dans le cas d’une saisie utilisateur ? Autre ? Note que je ne remets pas en doute l’utilité, juste que je l’ignore et ça m’agace ;)

TIL, merci.

Je sais pas plus ce que c’est qu’est un geoguesser qu’un wordle _o_

ROFL

plop June VII V Pepsi again belleck dbfen 4 FY777

Rule 11 j’abandonne :)

C’est exactement pour ce genre de possible galère que je pense qu’il vaut mieux rallonger le mot de passe que mettre un caractère « exotique ». J’ai eu le soucis assez régulièrement par le passé, je sais maintenant où sont le w, le m, le z, et quelques diacritiques, ou que les chiffres nécessitent pas de Shift, avec une dispo qwerty.

Il me serait jamais venu à l’idée d’utiliser un qwerty (en tant que français), les français qui font ça, c’est une question d’habitude ? Les premiers PC vendus en France avaient des claviers qwerty ? Ou bien vous utilisez une disposition qwerty sur un clavier qui est « physiquement » azerty par snobisme pour une bonne raison ?

À ça peut s’ajouter encore un sur-couche de problème… Il y a quelques temps j’ai acquis un clavier à touches mécaniques, pour voir ce que ça donnait. Il se trouve qu’en plus d’avoir des touches mécaniques elles ont des loupiottes, ça aucun problème, mais c’est un clavier dit « de gamer », on peut donc, par exemple échanger les touches qzsd avec les flèches. Je l’ai appris par hasard suite à un appuis involontaire sur la « bascule » qui active ce réglage, bah je me suis trouvé con. Surtout que débrancher le clavier un moment (le temps de brancher un bon vieux clavier de merde avec des touches « caoutchouc » pour finir mon taf) et bien ça ne remet pas la configuration à zéro (oui c’est sûr c’est plutôt une feature je dis pas ^^). J’ai fini par trouver mais ce fût un peu laborieux.

Au sujet des touches mécaniques : ya pas à dire le toucher est plus agréable, par contre j’ai certaines touches qui parfois ne s’activent pas. J’en ai déjà remplacé quelques une (le clavier était livré avec quelques mécanismes de remplacement…) mais c’est le genre de truc qui ne m’étais jamais arrivé avec des claviers normaux à 10 balles… Ceci dit je ne suis pas capable de dire pourquoi ça déconne précisément, vu qu’il y a un tas de raisons possible, alors je suppose que c’est une conjonction de toutes :

• C’est pas le premier prix mais quand je vois les prix qu’atteignent les claviers mécaniques je sais que j’ai pas le top

• Je suis un bourrin et les touches prennent cher, ces bêtes là sont probablement plus délicates que les claviers classiques

• Les poils d’animaux ont tout l’espace nécessaire pour aller se foutre où il ne faut pas (j’ai déjà ôté toutes les touches (enfin les « capuchons », les mécanismes c’est assez relou à sortir…) pour dégager les poils, mais je vais pas faire ça tout le temps.

• N’ayant jamais eu une motricité fine très développée et le temps passant, mes doigts ne frappent plus forcément là où mon cerveau s’attend à ce qu’ils frappent avec une précision suffisante. ^^

Pour les plus jeunes (ou les très vieux) : https://www.youtube.com/watch?v=zGvmL21pv6c

:p

Ah si, une remarque quand même. C’est quelque chose que je faisais aussi, en préfixant pour éviter tout risque de collisions mais de ce que j’ai compris, par convention les identifiants (ie: non de variable) en majuscule sont à réserver aux variables d’environnement.

Mais bon… je note que tu préfixes par _ par prudence, je crois pas que ce soit très grave comme façon de faire, perso je ne vais pas réécrire tous les scripts que j’ai fait avec des variables en majuscules pour les passer en minuscules ! :) Le plus souvent je me contentais de les préfixer toutes par une chaîne dériver du script. par exemple un script "UltimateTrucWrapper" je préfixais par UTW_. Avec ça je pense être assez tranquille. Mais maintenant j’ai changé j’en ai plus rien à branler j’utilise des minuscules avec un nom le plus descriptif possible, exemple : lobby_carpet_color_RVB :)

    _AXM_ARGS_FILE=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_args.XXXXXX)
    _AXM_ARGS_VALUE=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_value.XXXXXX)
    _AXM_LIST_ARGS=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_list_args.XXXXXX)
    _AXM_LIST_OPT=$(mktemp -t ${__AXM_FILE_PREFIX}-auxilium_list_opt.XXXXXX)

Il servent à quoi les .XXXXXX finaux ?

Si tu veux que le nom soit propre à l’exécution (au cas peu probable où on exécuterait ton script 2+ fois en parallèle (dans un framework plus large qui l’inclurait par exemple…)), tu devrais p-e utiliser $$ en lieu et place de .XXXXXX ?

Après lecture rapide de ton script je dois dire que je n’ai pas le volonté de vraiment étudier le truc. Mais je le garde dans mes bookmark et le testerai p-e à l’occasion.

Et j’apprends l’existence de /usr/bin/tabs, l’aide parle de COBOL, FORTRAN et S/370, entre autre, je t’avoue que je suis trop intimidé pour essayer de comprendre à quoi ça sert ! ^^

Je ne connaissais pas ${X,,} ni ${X^^} (c’est dans la « cheat sheet » à laquelle je me réfère mais je n’ai pas pris le temps de tout lire (parce qu’il m’est illusoire de tout retenir de toute façon…)).

J’ai vu que declare permettait effectivement de faire ça. Cependant je ne vois pas quels sont les cas d’usage. Vous auriez des exemples ?

si tu n'utilise pas un autre langage que tu donne à manger à un compilateur ou un interpréteur

Alors je mets de côté les langages compilés qui ont indéniablement des avantages sur les interprétés. Mais je ne vois pas ce que tu veux dire si tu parles d’interpréteur. Bash est au même titre que Perl et Python un langage interprété. Le fait que Python expose l’étape intermédiaire du bytecode ne change pas grand chose.

En d’autres termes, en quoi Perl et Python seraient de véritables langages interprétés et pas Bash ?

Les « exécutables de ma distribution » ils ont cet avantage sur les bibliothèques Python d’être nettement plus stabilisés en terme d’API… Sans parler de la quasi trivialité de la mise en place de « l’environnement d’exécution », qui s’il n’est pas très complexe dans le cas de Python, encore moins de Perl, n’est pas aussi trivial que les binaires qui constituent l’environnement d’exécution d’un script Bash.

Ça fait combien de temps que pip/pip3 ne permet même plus de faire un "search" ?

il n'est pas limitant (va dessiner des Qrcode en shell)

Je pense qu’on touche là à un point central, qu’est-ce que "le shell" désigne si on parle programmation ?

Est-ce uniquement Bash (ou zsh, etc…) ou bien est-ce qu’on n’y inclus l’ensemble des binaires disponibles ? Bash et les autre shells sont des langages que je qualifierais de « glue », sans binaires comme curl ou grep ou find etc… on ferait pas grand chose.

Les « bibliothèques » du shell ce sont les « standalone » que tout bonne bibliothèque fournie systématiquement.

En interactif ils peuvent être très pratiques

Oui, en interactif je ne réécris pas toute ma commande si je veux la relancer avec un grep dessus… Donc j’UUOC sans honte comme tout le monde, comme tu dis c’est très pratique.

Les UUOC ne sont que des problèmes de puristes, ils ne posent de véritables problèmes que d'un point de vue esthétique.

Là par-contre je m’inscris en faux. C’est d’abord un problème si ton script, ou ta fonction dans ton script, est amenée a être exécutée « plein de fois ». Une instruction qui prend 15ms au lieu de 2ms ça change rien si tu l’exécutes une seule fois. Si c’est quelques millions, ou même quelques milliers de fois, ça commence à avoir son importance.

Donc clairement, ce n’est pas une question purement esthétique.

toute une série d’instructions/lignes entre le changement de IFS et son rétablissement.

Oui en effet. Je ne vois pas de cas d’usage mais ça ne veut clairement pas dire qu’il n’y en a pas.

le shell utilise IFS quasiment partout

Tu veux dire des commandes du shell comme ls, xargs ou autre qui pourraient avoir leur comportement modifié à cause de la modification de IFS ? Ça m’étonnerait (ou plutôt j’espère que non ^^). Je pense que tu parles du reste du code du script, voire de script externes appelés par celui-ci ?

Et heureusement la modification ne se propage bien-sûr pas au « sur-shell » qui a lancé le script.

$ printf "%q\n" "$IFS"; echo -e 'IFS=4\nprintf "IFS vaut : %q\\n" "$IFS"; exit 4\n' > script; bash -f script; printf "%q" "$IFS"

$' \t\n'
IFS vaut : 4
$' \t\n'

(je sais c’est moche, mais c’est représentatif)

Et c’est un bon exemple de cas « àlakon » où un double échappement se justifie, encore que, c’est juste pour que le fichier "script" généré ait pas la gueule de travers :)

utiliser perl/python/ruby.

Il y a clairement des avantages, mais qui viennent bien sûr avec quelques inconvénient. Dans les avantages je pense d’abord au fait de la cohérence du langage, surtout pour Python, mais Perl est aussi exemplaire sur ce point (bien que les deux soient absolument différent, et à condition de ne pas recourir excessivement à la puissance d’abstraction de Perl ^^). Par rapport au shell(s) Unix c’est le jour et la nuit.

Par contre pour « qui doit durer », je pense que ça dépend de si on parle de « qui doit être étendu souvent, par de nombreuses personnes » ou « qui doit être laissé dans un coin et voir passer les upgrades systèmes sans demander la moindre attention ». Dans le second cas Python est pas ouf, d’expérience, à partir du moment où on utilise quelques lib externes ça explose fréquemment à la version d’OS N+1. Pas le shell.

Je trouve que la taille du code joue beaucoup aussi, la programmation objet de Python, dès que le programme devient relativement complexe, ça aide énormément, en plus de la syntaxe et du paradigme beaucoup plus cohérent auquel je faisais allusion précédemment.

Pour ma part, en tout cas dans le cas où un test est nécessaire. Généralement c’est pour conditionner l’exécution d’une autre commande ou d’une fonction. Alors à moins d’être dans le cas d’une « conditionnalité complexe » (ie: un if … elif … else … fi), je fais :

grep -q truc fichier || action

Le || pour coller à ton exemple avec -ne 0, mais si c’est au contraire -eq 0 (ie: on fait l’action si la condition est "success"), alors la même chose avec &&.

Je fais parfois même des condition || { action1; && action2; } (ou l’inverse…) mais j’avoue que là ça devient assez illisible et il vaut mieux recourir à un if même si on peut faire sans.

Flemme de vérifier (et pas sûr que ça change quoi que ce soit à l’exécution…) mais si c’est la condition “ya des lignes ou pas ?” qui t’intéresse, le -c de grep n’est même pas nécessaire :) Et l’intérêt à ne pas le mettre dans ce cas ce serait qu’à la simple lecture du début de la ligne, juste les options du grep, tu sais qu’on ne s’intéresse pas aux nombres de lignes qui matchent mais juste s’il y en a ou pas.