Je prends grand soin à éviter les bashismes pour que mes scripts puissent tourner sur n’importe quel système, quelque soit le shell présent, pourvu qu’il soit compatible POSIX.
Mes scripts shell son préfixés avec le shebang #!/usr/bin/env sh
et jusqu’à maintenant, je le faisais purement pour la bonne pratique, en me disant que je pourrais très bien utiliser #!/bin/sh
, et mon environnement d’exécution se débrouillera toujours pour trouver un shell compatible POSIX pour exécuter mon script. Et si le système ne respecte pas la hiérarchie standard, j’aurai un problème dans tous les cas puisqu’on spécifie de toute façon /usr/bin/env
dans l’autre shebang. Or, quel système, en pratique, fournirait /usr/bin/env
et pas /bin/sh
? D’ailleurs, il me semblait plus probable de tomber sur un système qui a un /bin/sh
et pas un /usr/bin/env
, la description de /usr/bin
étant « Binaires exécutables qui ne sont pas déjà présents dans /bin et donc pas indispensables à un système minimaliste » (d’ailleurs, pourquoi env
est dans /usr/bin
et pas dans /bin
?). Ce qui ressemble effectivement à un point négatif à l'utilisation de #!/usr/bin/env sh
.
Les systèmes que j’ai l’habitude d’utiliser utilisent dash
comme shell par défaut. Tout va bien dans le meilleur des mondes, c’est un shell minimaliste qui à priori ne propose que très peu d’ajouts par rapport à la norme POSIX. Ce qui veut dire que si un script tourne chez moi, il devrait tourner partout pourvu que ses dépendances soient installées.
Et là, j’utilise un système qui utilise bash
pour /bin/sh
. Je m’en rends vite compte, parce que pour vérifier qu’une construction n’est pas un bashisme, je lance sh
et je la colle dedans.
Sauf que là, les bashismes passaient (aka Comment ça, $EPOCHREALTIME fonctionne dans sh
alors que c’est une fonctionnalité du tout nouveau Bash 5 ?). Ce qui veut aussi dire que mes scripts avec le shebang #!/usr/bin/env sh
se mettent à fonctionner même s’ils contiennent des bashismes (et bon, si je me mets à avoir besoin des bashismes, peut-être qu’il est temps d’utiliser un autre langage de script installé par défaut sur la plupart des systèmes).
Que faire ? Je ne vais pas changer le shell par défaut du système, parce que c’est certainement un bon moyen de chercher les ennuis voire casser le démarrage (il doit y avoir des scripts plein partout se déclarant avec /bin/sh
ou /usr/bin/env sh
et qui contiennent en fait des bashismes).
Grâce à l’utilisation de #!/usr/bin/env sh
, la solution est simple : installer dash
ou n’importe quel autre shell limité à la norme POSIX, créer un lien $HOME/bin/sh
pointant vers ce shell et avoir $HOME/bin
dans mon $PATH
, et paf ça fonctionne (initialement, l’idée de faire ce lien dans /usr/local/bin
m’a chatouillé l’esprit deux secondes, mais à la troisième seconde je me suis dit que ça avait un bon potentiel pour semer le même chaos que celui qui est décrit dans le paragraphe précédent).
Ouf, ma vie n’a pas changé, je vais pouvoir continuer à écrire mes scripts en toute tranquillité indépendamment du shell par défaut du système que j’utilise. N’avais-je pas utilisé #!/usr/bin/env sh
, j’étais bon pour changer tous mes shebangs. Un bon gros sed
sur tout mon $HOME
. #!/usr/bin/env sh
, c’est bon, mangez-en.
# Branlette intellectuelle
Posté par SChauveau . Évalué à 5.
Tout est dans le titre.
[^] # Re: Branlette intellectuelle
Posté par raphj . Évalué à 6.
Assumée :-)
Cela dit, j'ai déjà écrit des scripts pour le shell d'Android et avoir l'habitude d'écrire en POSIX a permis de le faire sans se sentir limité par l'absence de bash.
[^] # Re: Branlette intellectuelle
Posté par LaBienPensanceMaTuer . Évalué à 7.
Bein non, désolé…. De mon point de vue, la démarche est pro et propre.
Beaucoup devrait s'en inspirer, ça éviterait souvent des "chez moi ça marche ©" et autre "ah mais non, là y a pas bash, je vais devoir tout réécrire … à moins que tu me déploies bash sur les 123 serveur AIX".
# Ksh
Posté par YBoy360 (site web personnel) . Évalué à 8. Dernière modification le 02 mai 2019 à 17:09.
J'ai l'impression d'être en 2005 d'un coup.
Pas que c'était si lointain, mais parce qu'il y avait dans mon entourage des évangélistes du Ksh, du Sh, mais jamais du Bash.
Pourquoi bash se fait basher? La compatibilité Posix? c'est vraiment ça le truc?
[^] # Re: Ksh
Posté par Thomas Douillard . Évalué à 3.
C’est de bon ton de basher le truc en cours de règne ! Rares sont les présidents populaires. En tout cas bash n’est détrôné que marginalement.
De mémoire Dash est utilisé notamment pour les perfs comme shell de démarrage, mais avec systemd comme il y a moins de scripts à l’init ça a sans doute perdu de son intérêt.
[^] # Re: Ksh
Posté par barmic . Évalué à 5.
Je n'ai rien contre bash perso, j'ai juste une préférence pour zsh comme shell interactif et du coup j'ai tendance à l'utiliser pour mes scripts perso.
[^] # Re: Ksh
Posté par Sytoka Modon (site web personnel) . Évalué à 8. Dernière modification le 03 mai 2019 à 13:01.
bash, zsh, si Debian a basculé sur dash il y a des années pour les scripts systèmes (le compte root a toujours bash comme shell), ce n'est pas juste pour les beaux yeux. dash est plus rapide et a moins de fonctionnalités donc un angle d'attaque plus faible. Il y a d'ailleurs eu un bogue sur bash qui a touché de manière critique toutes les distributions sauf celles basées sur dash comme Debian et ses dérivées.
Bref, il ne faut pas opposer le shell du terminal du shell utilisé dans certains scripts.
[^] # Re: Ksh
Posté par barmic . Évalué à 2.
Te-ai pas le même usage que debian donc j'utilise pas les même outils que debian.
[^] # Re: Ksh
Posté par Sytoka Modon (site web personnel) . Évalué à 2.
Toi oui mais raphj semble vouloir faire aussi des script système donc chacun ses usages. J'ai un chercheur chez moi qui te dirait de tout faire en Python puisque tu ne fait pas du système ! La diversité à du bien ;-)
# Nixos
Posté par Guillaum (site web personnel) . Évalué à 6.
J'allais te dire nixos, mais en fait non ;)
# Solaris
Posté par Arthur Accroc . Évalué à 4.
Rien n’est complètement garanti.
La dernière fois que j’ai essayé openindiana, il y a quelques années seulement, il conservait encore comme /bin/sh un ksh antédiluvien et notoirement buggé, paraît‐il pour garantir la compatibilité à des logiciels qui en dépendent étroitement…
Et ce n’est pas que ce shell fasse des choses en plus par rapport à la norme POSIX, c’est qu’il en fait moins.
« Le fascisme c’est la gangrène, à Santiago comme à Paris. » — Renaud, Hexagone
# POSIX
Posté par barmic . Évalué à 4.
Tu pense aussi à positionner la variable POXILY_CORRECT par exemple ?
Perso, je me fou de POSIX, faut juste que mes scripts soient cohérents. Si j'utilise une fonctionnalité de bash, je déclare bien bash, par exemple.
J'aime bien zsh et il me permet d'avoir assez peu de dépendances dans mes scripts, je trouve ça cool.
[^] # Re: POSIX
Posté par raphj . Évalué à 2.
Non, par contre j'essaie d'utiliser les fonctionnalités POSIX des outils. Peut-être que je devrais pour être parfaitement cohérent !
Il m'est déjà arrivé d'avoir un problème dans un de mes scripts qui fonctionnait sous GNU/Linux et pas sous macOS à cause d'une option prise en charge par l'un et pas par l'autre.
[^] # Re: POSIX
Posté par raphj . Évalué à 1.
Ça m'intéresse, tu as des exemples ?
[^] # Re: POSIX
Posté par barmic . Évalué à 2.
Une partie peu aussi de faire avec d'autres, mais pêle-mêle :
Bien sûr ce ne sont pas des remplaçant parfait et identiques, mais dans bien des cas ils me conviennent voir sont plus confortables
[^] # Re: POSIX
Posté par Zenitram (site web personnel) . Évalué à 6.
Moi qui croyais que le Linuxiens ne juraient que par "une fonctionnalité, un outil, ne pas faire des couteaux suisses compliqués et on pipe tout", tout s'en va… Bientôt fera un système d'init dans le même style tout imbriqué et on l'appellera systemd.
--> []
[^] # Re: POSIX
Posté par David Marec . Évalué à 10.
Les unixiens, pas les
linuxiens. Je commence à croire que ce sont deux mondes qui s'éloignent de plus en plus.il ne faut pas s'arrêter là !
Pourquoi se contenter du système d'init ? pourquoi ne pas y ajouter plein d'autre trucs comme les logs, le hostname, un bus système ou que sais-je encore ?
[^] # Re: POSIX
Posté par Lutin . Évalué à 0.
Windowsd ?
[^] # Re: POSIX
Posté par kna . Évalué à 9.
Pire, on pourrait intégrer à un bête éditeur de texte comme emacs tout plein de fonctionnalités comme calculatrice, client mail, lecteur de news, client IRC, lecteur audio, lecteur pdf et navigateur web. Ça serait tellement perturbant pour les utilisateurs qu'on y rajouterait un psy virtuel.
[^] # Re: POSIX
Posté par Le Pnume . Évalué à 7.
On pourrait aussi ajouter un firewall à Libreoffice
-->[]
[^] # Re: POSIX
Posté par barmic . Évalué à 3.
C'est une règle, il faut savoir ce qu'elle signifie pour comprendre quand s'en servir ou quand elle est moins pertinente. Parser la sortie de ls ou file peut être une gageure par exemple (et assez fragile).
[^] # Re: POSIX
Posté par LaBienPensanceMaTuer . Évalué à 3.
Bash fait aussi de la substitution… après, je connais pas les capacités de zsh en la matière, je peux donc pas te dire si c'est du même niveau.
[^] # Re: POSIX
Posté par barmic . Évalué à 2.
Oui oui c'est pas une spécifité de zsh, laid zsh est plus sympa. Pour enchaîner des substitutions tu n'es pas contraint de créer des variables intermédiaires.
# autres langages ?
Posté par pizaninja . Évalué à 3.
Pour ma part, quand j'ai un script un peu balaise à écrire (traitement de données via json et utilisation de libs externes bien pratiques), j'hésite souvent entre node.js et python.
Je suis hors sujet ? 😀
[^] # Re: autres langages ?
Posté par Nodeus . Évalué à 1.
et pourquoi pas scratch !
non je rigole
[^] # Re: autres langages ?
Posté par remyd1 . Évalué à 2. Dernière modification le 03 mai 2019 à 10:51.
Bonjour,
C'est d'autant plus vrai avec python, perl, etc… En effet, si tu prends Python, entre Python2, Python3, virtualenv, pyenv, conda, les installs spécifiques avec un prefix différent, environment modules…. Bref, il me parait très important pour les développeurs de respecter cette règle élémentaire décrit dans cet article.
Il m'arrive malheureusement régulièrement de faire un sed massif sur tous les scripts python pour corriger ça en vérifiant la version de python nécessaire au préalable.
Cdlmt
[^] # Re: autres langages ?
Posté par raphj . Évalué à 3.
Pour le traitement des données (et c'est ce que je fais en ce moment), je me rends compte que l'idée de créer une chaîne de traitements (pipeline) avec un script shell et des pipes reliant des bouts de traitement indépendant les uns avec les autres me séduit de plus en plus.
On a un script shell qui orchestre le traitement. On évite les fichiers intermédiaires sauf peut-être pour certains traitements lourds, et chaque brique est codée dans un langage adapté. Les briques très simples peuvent être des fonctions du shell.
Par exemple, j'ai eu besoin de faire une transposition d'un tableau en CVS. Une réponse sur stack overflow suggère l'utilisation de Ruby, langage que je ne maîtrise pas du tout, mais ça fait exactement le job que je veux. Du coup, j'ai adapté la réponse pour que ça utilise des points virgules plutôt que des virgules et ma brique de traitement pour ça est :
Ensuite, dans ma chaîne de traitement :
Cette manière de traiter les données peut être (bien) plus lente qu'un traitement monolithique spécialisé, mais le script sera peu lancé dans sa vie et l'opération lourde dans mon cas est la création des données, de toute façon. Les enjeux ici sont :
[^] # Re: autres langages ?
Posté par Sytoka Modon (site web personnel) . Évalué à 3.
Entièrement d'accord avec toi. C'est ainsi que je fait de plus en plus. Cela permet d'avoir des petites briques qu'on teste bien de manière indépendante et qu'on comprends. Si la vitesse n'est pas un critère, c'est vraiment intéressant.
Deux cas que j'utilise, un bien et un mauvais :
C'est assez pratique pour éviter les grosses conneries !
[^] # Re: autres langages ?
Posté par vv222 . Évalué à 3.
Suite à ton exemple d’utilisation d’
eval
, je ne résiste pas au plaisir malsain de partager ce bout de code :PS : Je sais que
local
n’est pas POSIX, je l’utilise quand même parce que dans les faits tous les interpréteurs que j’ai testé savent l’utiliser et qu’il est trop pratique pour s’en passer sans méchamment compliquer beaucoup de choses.# posix
Posté par pizaninja . Évalué à -2.
!/bin/bash --posix
Voir https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html
[^] # Re: posix
Posté par barmic . Évalué à 7.
Donc tu as une dépendance explicite à bash, autant utiliser ses fonctionnalités.
[^] # Re: posix
Posté par YBoy360 (site web personnel) . Évalué à 1. Dernière modification le 03 mai 2019 à 12:03.
en même temps, shebang ne supporte pas les arguments..
Question puisque l'on est vendredi, que tout est permis
j'ai testé csh, ksh, bash, aucun ne râle lorsque je fais :
$ false && truc
ou
Je me rappelle que sous certaines versions de Solaris 8 c'était impossible…
[^] # Re: posix
Posté par Sytoka Modon (site web personnel) . Évalué à 4.
Tu peux très bien passer un argument ce qui est la cas ici. Sinon l'astuce avec /usr/bin/env ne fonctionnerait pas !
[^] # Re: posix
Posté par YBoy360 (site web personnel) . Évalué à 1.
j'ai lu cela il y a bien longtemps peut-être un peu rapidement : multiple-arguments-in-shebang
pour passer des arguments à mes scripts Groovy, je fais un truc immonde :
normalement je ne passe jamais d'arguments pour mes scripts Groovy, car les libs se trouve en général sur Maven, mais là, c'est une lib qui n'est plus maintenu depuis 2008, je suis obligé de déclarer le classpath.
[^] # Re: posix
Posté par YBoy360 (site web personnel) . Évalué à 2.
D'ailleurs, comme
#!/usr/bin/env bash --posix
ne fonctionne pas, tu dois faire
[^] # Re: posix
Posté par Sufflope (site web personnel) . Évalué à 2.
Hem pourtant dans le man ça parle de
-S
https://www.gnu.org/software/coreutils/manual/html_node/env-invocation.html#env-invocation
[^] # Re: posix
Posté par YBoy360 (site web personnel) . Évalué à 2.
Hmmm, merci pour le conseil, c'est récent, car :
mais sur ma machine, mga7, ça passe.
[^] # Re: posix
Posté par barmic . Évalué à 2.
Depuis une dizaine d'années au moins ça fonctionne. Ça permet d'utiliser env ou awk -F
[^] # Re: posix
Posté par BFG . Évalué à 3.
C'est un peu plus subtil, il ne supporte qu'un argument.
[^] # Re: posix
Posté par Sufflope (site web personnel) . Évalué à 2.
Depuis 2018 il supporte sous linux l'option
-S
comme sous FreeBSD. Mais ça fait pas 10 ans c'est vrai.[^] # Re: posix
Posté par BFG . Évalué à 2.
En effet, mais utiliser l'option
-S
introduira une dépendance à certaines versions deenv
dès la première ligne. C'est dommage car la portabilité est réduite dès le tout début du fichier et empêche de mettre des conditions pour supporter différents systèmes.[^] # Re: posix
Posté par barmic . Évalué à 1.
OSEF? Si le problème de portabilité se résume au shebang, on en parlerait pas :)
[^] # Re: posix
Posté par BFG . Évalué à 2.
Au contraire, c'est d'autant plus grave sur la première ligne car il n'y a pas la possibilité d'adapter le comportement en fonction du système.
[^] # Re: posix
Posté par raphj . Évalué à 1.
Ça a l'air de se comporter comme quand on appelle
bash
avec le nom de programmesh
chez moi.Entre autres,
echo $EPOCHREALTIME
fonctionne.Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.