Je préfère apprendre en autodidacte. Et apprendre à utiliser efficacement un Shell Unix, je trouve cela difficile. J’aime bien le projet GNU pour les valeurs du projet et la documentation au format Info pour transmettre des connaissances (un savoir-faire). Mais la documentation de Bash est difficile à assimiler. On découvre souvent une multitude de manières, pour faire la même chose, lorsqu’on fait des recherches sur le Web sur l’invocation de commandes Shell. En fait, j’en suis venu à penser qu’il fallait bien connaître le fonctionnement du système d’exploitation pour savoir comment procéder. On ne peut pas deviner. Les gens qui concevaient les utilitaires Unix participaient aussi au développement du système Unix. Idem pour le projet GNU. Dans son livre Scripts Shell Linux et Unix, Christophe Blaess recommande d’ailleurs d’apprendre la programmation Shell par la pratique. J’ai l’impression que, à mon niveau débutant, programmer avec un Shell de type Unix peut entraîner une perte de temps. Cela nécessite de déployer trop d’énergie, de façon générale. Après, quand on maîtrise, aucun problème rédhibitoire : cela vient, ou pas (on perçoit intuitivement).
Depuis des décennies, le conseil a toujours été d’éviter d’utiliser les shells pour traiter des entrées de données non fiables, pour des raisons de sécurité. Tout le monde vous dira qu’utiliser des scripts shell pour des pages web CGI – c’est-à-dire générées dynamiquement par des programmes – est une très mauvaise idée. La principale raison est que la syntaxe des shells est complexe. Il est difficile d’écrire des scripts correctement.
Source : Stéphane Chazelas (article 01net.com, à propos de la faille Shellshock)
On peut dire que je ne suis pas vraiment un utilisateur confirmé du Shell Unix. Néanmoins, ZSH et Fish, ils me donnent l’impression que c’est trop sophistiqué comme outils (voire surfait), pour l’usage qu’on peut en faire. Quand j’aurais plus de temps, j’essayerais d’expérimenter avec Rash (The Reckless Racket Shell, implémenté en Racket Scheme). Je pense que c’est plus en phase dans ma ligne de conduite.
Je préfère apprendre en autodidacte. Et apprendre à utiliser efficacement un Shell Unix, je trouve cela difficile. J’aime bien le projet GNU pour les valeurs du projet et la documentation au format Info pour transmettre des connaissances (un savoir-faire). Mais la documentation de Bash est difficile à assimiler. On découvre souvent une multitude de manières, pour faire la même chose, lorsqu’on fait des recherches sur le Web sur l’invocation de commandes Shell. En fait, j’en suis venu à penser qu’il fallait bien connaître le fonctionnement du système d’exploitation pour savoir comment procéder. On ne peut pas deviner. Les gens qui concevaient les utilitaires Unix participaient aussi au développement du système Unix. Idem pour le projet GNU. Dans son livre Scripts Shell Linux et Unix, Christophe Blaess recommande d’ailleurs d’apprendre la programmation Shell par la pratique. J’ai l’impression que, à mon niveau débutant, programmer avec un Shell de type Unix peut entraîner une perte de temps. Cela nécessite de déployer trop d’énergie, de façon générale. Après, quand on maîtrise, aucun problème rédhibitoire : cela vient, ou pas (on perçoit intuitivement).
Source : Stéphane Chazelas (article 01net.com, à propos de la faille Shellshock)
On peut dire que je ne suis pas vraiment un utilisateur confirmé du Shell Unix. Néanmoins, ZSH et Fish, ils me donnent l’impression que c’est trop sophistiqué comme outils (voire surfait), pour l’usage qu’on peut en faire. Quand j’aurais plus de temps, j’essayerais d’expérimenter avec Rash (The Reckless Racket Shell, implémenté en Racket Scheme). Je pense que c’est plus en phase dans ma ligne de conduite.