Il y a deux énormes problème en shell : le scoping et les "tableaux".
Pour passer les arguments à une commande, quelle est la bonne manière : cmd "$*", cmd "$@", cmd $* ou cmd $@ ? (hint : sachant que zsh et bash n’ont pas le même comportement en plus...)
Et ça c’est encore la version simple. Supposons que tu veuilles passer tous les arguments à une commande, en les remplaçant d’une certaine façon (par exemple en remplaçant les chemins relatifs par des chemins absolus), comment tu fais ? (vraie question hein, le problème s’est posé à moi il y a quelque jour, ben je suis passé à Python après m’être cassé la tête contre le mur pendant quelques heures)
Les scopes sont très rigolo aussi. Petit jeu : qu’affiche ce programme ?
Explications : dans certains cas, le shell fork. S’il fork les variables d’environnement ne sortent pas du fils. Ce qui donne des challenge intéressant comme : comment savoir à l’avance dans quelle situation le shell va forker ? (dans le premier exemple, le fork pour read était loin d’être évident...), et surtout, comment réussir à réorganiser tout ton programme pour qu’il ne fork pas parce que tu as besoin de la variable login au bon endroit ? (dans mon exemple j’ai pas réorganisé, j’ai tout fait dans le fils, mais si j’avais eu besoin de login dans le processus initial...)
Dernier point en shell, il est impossible de choper le code de retour des processus initiaux et intermédiaires dans une chaine de pipes. Ce qui, couplé à des trucs précédents, donne lieu à de grosses grosses prises de tête. Exemple, comment faire pour détecter le cas « téléchargement foiré » dans la chaine suivante ?
curl http://monsite | sed s/toto/tata > test
Le shell est un langage qui est extrêmement intéressant et bien pensé par certains aspects, mais il a aussi d’énormes problèmes.
[^] # Re: Syntaxe bash ?
Posté par Moonz . En réponse au journal Batsh - Scripting Bash, et Windows. Évalué à 4. Dernière modification le 19 mars 2015 à 16:30.
Il y a deux énormes problème en shell : le scoping et les "tableaux".
Pour passer les arguments à une commande, quelle est la bonne manière :
cmd "$*",cmd "$@",cmd $*oucmd $@? (hint : sachant que zsh et bash n’ont pas le même comportement en plus...)Et ça c’est encore la version simple. Supposons que tu veuilles passer tous les arguments à une commande, en les remplaçant d’une certaine façon (par exemple en remplaçant les chemins relatifs par des chemins absolus), comment tu fais ? (vraie question hein, le problème s’est posé à moi il y a quelque jour, ben je suis passé à Python après m’être cassé la tête contre le mur pendant quelques heures)
Les scopes sont très rigolo aussi. Petit jeu : qu’affiche ce programme ?
Réponse : "Hello, ". Le bon programme serait :
Explications : dans certains cas, le shell fork. S’il fork les variables d’environnement ne sortent pas du fils. Ce qui donne des challenge intéressant comme : comment savoir à l’avance dans quelle situation le shell va forker ? (dans le premier exemple, le fork pour read était loin d’être évident...), et surtout, comment réussir à réorganiser tout ton programme pour qu’il ne fork pas parce que tu as besoin de la variable login au bon endroit ? (dans mon exemple j’ai pas réorganisé, j’ai tout fait dans le fils, mais si j’avais eu besoin de login dans le processus initial...)
Dernier point en shell, il est impossible de choper le code de retour des processus initiaux et intermédiaires dans une chaine de pipes. Ce qui, couplé à des trucs précédents, donne lieu à de grosses grosses prises de tête. Exemple, comment faire pour détecter le cas « téléchargement foiré » dans la chaine suivante ?
curl http://monsite | sed s/toto/tata > testLe shell est un langage qui est extrêmement intéressant et bien pensé par certains aspects, mais il a aussi d’énormes problèmes.