Posté par ymorin .
En réponse au journal sortie de rpmrebuild 2.7.
Évalué à 6.
Dernière modification le 16 juin 2012 à 23:31.
le mec qui me dit que au dessus de X lignes de shell, il a codé dans un vrai langage de script
Pourquoi le shell n ́est pas bien ?
À mon avis, c ́est le meilleur langage lorsqu ́il s ́agit d ́automatiser certains traitements systèmes : installer un batch de packages, triturer les fichiers de conf, sauvegarder et restaurer, traiter l ́ajout et la suppression d ́utilisateurs (vaut mieux automatiser lorsqu ́il faut créer les homes, les repositories, affecter les droits… pour des centaines d ́utilisateurs qui vont et viennent).
Comme tout langage, il y a des pièges à éviter. Comme tout langage, il vaut mieux bien architecturer avant de coder. Comme tout langage, il faut coder proprement et respecter des règles.
De plus, avec bash-4 sont arrivées certaines améliorations qui en font maintenant un langage plutôt intessant : tableaux associatifs (aka dictionnaires), co-process… bash-3 proposait déjà les tableaux indexés, le '$?' pour chaque process d ́un pipeline… Mais dans ce cas, il faut utiliser #!/bin/bash, et garder #!/bin/sh pour les scripts réellement POSIX.
Par exemple, le projet que je maintiens (crosstool-NG) a pour but de compiler l ́ensemble des packages nécessaire pour construire une chaîne de cross-compilation : gcc, binutils, librairie C (glibc/eglibc/uClibc/…, installer les en-têtes du noyau, télécharger les archives, les extraire et les patcher, compiler certains packages ou pas en fonction de la config, appliquer des contournements ou pas pour certaines versions, etc… C ́est globalement ce qu ́il y aurait à taper en ligne de commande si ça de vait être fait à la mimine (./configure --blabla && make blabla && make install, mais en beaucoup plus compliqué et touffu). Résultat : environ 14000 lignes de code shell bash-3 réparties dans environ 70 fichiers. À part en shell, je vois pas en quoi ça aurait pu être codé…
Bref, dire que quelqu ́un est stupide/mauvais/fou/con/… d ́avoir utilisé le shell pour écrire un 'gros' programme, c ́est comme traiter de la sorte quelqu ́un qui fait un gros Makefile pour compiler un gros programme. Si le langage shell est adapté au problème, alors l ́utiliser est bien ; s ́il n ́est pas adapté, alors l ́utiliser est mal. C ́est comme tout, il faut choisir le meilleur outil pour chaque tâche, et de préférence un outils connu.
[^] # Re: Embauche
Posté par ymorin . En réponse au journal sortie de rpmrebuild 2.7. Évalué à 6. Dernière modification le 16 juin 2012 à 23:31.
Pourquoi le shell n ́est pas bien ?
À mon avis, c ́est le meilleur langage lorsqu ́il s ́agit d ́automatiser certains traitements systèmes : installer un batch de packages, triturer les fichiers de conf, sauvegarder et restaurer, traiter l ́ajout et la suppression d ́utilisateurs (vaut mieux automatiser lorsqu ́il faut créer les homes, les repositories, affecter les droits… pour des centaines d ́utilisateurs qui vont et viennent).
Comme tout langage, il y a des pièges à éviter. Comme tout langage, il vaut mieux bien architecturer avant de coder. Comme tout langage, il faut coder proprement et respecter des règles.
De plus, avec bash-4 sont arrivées certaines améliorations qui en font maintenant un langage plutôt intessant : tableaux associatifs (aka dictionnaires), co-process… bash-3 proposait déjà les tableaux indexés, le '$?' pour chaque process d ́un pipeline… Mais dans ce cas, il faut utiliser
#!/bin/bash, et garder#!/bin/shpour les scripts réellement POSIX.Par exemple, le projet que je maintiens (crosstool-NG) a pour but de compiler l ́ensemble des packages nécessaire pour construire une chaîne de cross-compilation : gcc, binutils, librairie C (glibc/eglibc/uClibc/…, installer les en-têtes du noyau, télécharger les archives, les extraire et les patcher, compiler certains packages ou pas en fonction de la config, appliquer des contournements ou pas pour certaines versions, etc… C ́est globalement ce qu ́il y aurait à taper en ligne de commande si ça de vait être fait à la mimine (
./configure --blabla && make blabla && make install, mais en beaucoup plus compliqué et touffu). Résultat : environ 14000 lignes de code shell bash-3 réparties dans environ 70 fichiers. À part en shell, je vois pas en quoi ça aurait pu être codé…Bref, dire que quelqu ́un est stupide/mauvais/fou/con/… d ́avoir utilisé le shell pour écrire un 'gros' programme, c ́est comme traiter de la sorte quelqu ́un qui fait un gros Makefile pour compiler un gros programme. Si le langage shell est adapté au problème, alors l ́utiliser est bien ; s ́il n ́est pas adapté, alors l ́utiliser est mal. C ́est comme tout, il faut choisir le meilleur outil pour chaque tâche, et de préférence un outils connu.
Hop,
Moi.