C'est exactement ce qu'on appelle bidouiller comme un cochon quand tu accumules toutes les étapes (sort vers fichier x2 vers join) que tu dois faire pour un truc aussi simple ;)
Pour prendre l'exemple le plus défavorable au shell tu peux comparer avec:
(je fais exprès de n'utiliser aucun idiome du langage choisi car ca ne me semble pas être le sujet)
Là on est dans le cas simple où on ne gère rien. En pratique dans get_fname t'as trois lignes de code (qui vont te demander X pipes grep/awk/sed/cut & variable substitution pour arriver au même résultat), tu vas aussi gérer que si le répertoire n'existe pas la commande se termine en erreur et faut que tu te comportes comme un set vide etc.
Tu peux très bien le faire en shell. Je sais le faire sans problème et je sais très bien reconnaitre la force des pipes textuels (je passe mes journées à analyser des gros gros fichiers textes). Maintenant regarde le temps que ca te prendre à écrire pour que ca juste marche et que ca soit relu par quelqu'un d'autre c'est vite vu. Le shell comme langage te force aux acrobaties et introduit énormément de bruit pour faire des choses simples en dehors des pipes et conditionnelles simples, bref la glue dont tu as besoin.
Si tu ajoutes à ca que les admins codent de plus en plus par le DevOps et qu'ils commencent à savoir programmer des trucs pas trop crado dans des langages modernes (ou la sélection naturelle va bien finir par s'opérer). La question de la pertinence du Shell comme langage de prog pour les scripts aujourd'hui se pose beaucoup je trouve.
C'est un peu comme les regex ou l'élégance en prog fonctionnelle. Ce sont des outils puissants et la recherche de la solution est intellectuellement satisfaisante. Maintenant on veut des trucs qui marchent, qui évoluent facilement, qui se testent et qui pourront être lu et compris rapidement dans X mois. Donc on réfléchi au meilleur outil pour le job.
[^] # Re: hop hop
Posté par ckyl . En réponse au journal Lister les programmes installés sur un (ou plusieurs) poste(s) sous Windows (XP ou 7). Évalué à 3.
C'est exactement ce qu'on appelle bidouiller comme un cochon quand tu accumules toutes les étapes (sort vers fichier x2 vers join) que tu dois faire pour un truc aussi simple ;)
Pour prendre l'exemple le plus défavorable au shell tu peux comparer avec:
(je fais exprès de n'utiliser aucun idiome du langage choisi car ca ne me semble pas être le sujet)
Là on est dans le cas simple où on ne gère rien. En pratique dans get_fname t'as trois lignes de code (qui vont te demander X pipes grep/awk/sed/cut & variable substitution pour arriver au même résultat), tu vas aussi gérer que si le répertoire n'existe pas la commande se termine en erreur et faut que tu te comportes comme un set vide etc.
Tu peux très bien le faire en shell. Je sais le faire sans problème et je sais très bien reconnaitre la force des pipes textuels (je passe mes journées à analyser des gros gros fichiers textes). Maintenant regarde le temps que ca te prendre à écrire pour que ca juste marche et que ca soit relu par quelqu'un d'autre c'est vite vu. Le shell comme langage te force aux acrobaties et introduit énormément de bruit pour faire des choses simples en dehors des pipes et conditionnelles simples, bref la glue dont tu as besoin.
Si tu ajoutes à ca que les admins codent de plus en plus par le DevOps et qu'ils commencent à savoir programmer des trucs pas trop crado dans des langages modernes (ou la sélection naturelle va bien finir par s'opérer). La question de la pertinence du Shell comme langage de prog pour les scripts aujourd'hui se pose beaucoup je trouve.
C'est un peu comme les regex ou l'élégance en prog fonctionnelle. Ce sont des outils puissants et la recherche de la solution est intellectuellement satisfaisante. Maintenant on veut des trucs qui marchent, qui évoluent facilement, qui se testent et qui pourront être lu et compris rapidement dans X mois. Donc on réfléchi au meilleur outil pour le job.