Re: *sh VS. python

[^] # Re: *sh VS. python

Posté par Ignatz Ledebur le 20 août 2012 à 17:27. En réponse au journal Tu souhaites apprendre à programmer en shell. Évalué à 3.
Debian qui préfère pousser un truc "POSIX" sous licence BSD, qu'un truc GNU sous GPLv3 8-o … c'est la fin des haricots !

S'ils se basent sur la branche Xu, il n'y a pas de guillemets à mettre à POSIX, c'est plutôt en deçà de la norme qu'au delà (ie. si ce n'est pas explicitement requis, ce n'est pas supporté).

Je suis particulièrement sceptique sur ce point puisque les "bashism" permettent souvent d'éviter des appels à sed, awk, expr, ou de faire des choses en beaucoup moins d'Itérations.

C'est faux. Plus il y a d'itérations, plus tu gagnes à utiliser une commande dédiée. Exemple :
```
#!/bin/sh
while read l; do
echo "${l%9}"
done
```
```
$ time seq 0 9999 | dash bench.sh > /dev/null 
 0m0.11s real 0m0.08s user 0m0.02s system
$ time seq 0 9999 | bash bench.sh >/dev/null
 0m0.45s real 0m0.40s user 0m0.04s system
```
```
#!/bin/sh
sed 's/$.*$9$/1円/;'
```
```
$ time seq 0 9999 | bash /tmp/bench.sh >/dev/null
 0m0.05s real 0m0.04s user 0m0.00s system
$ time seq 0 9999 | dash /tmp/bench.sh >/dev/null
 0m0.05s real 0m0.04s user 0m0.00s system
```
On voit que dash est plus rapide que bash, mais que les deux restent en deçà d'un sed bien placé.

Enfin revenir à du "pur" shell POSIX, me semble pas une bonne approche, je vois cela vraiment comme un simple retour en arrière plutôt qu'une évolution.

Ce n'est pas revenir, c'est rester dans la norme. Honnêtement, les extensions me paraissent plus être des facilités que des réformes du langage. Quand le shell POSIX trouve ses limites (on peut faire beaucoup mais, je le reconnais, pas tout), je préfère coder en Perl qu'utiliser des extensions propres à un shell particulier.

[^] # Re: *sh VS. python