Reddit – linux – Alors, quelle est la meilleure façon d’apprendre bash ?

La façon dont j’ai appris n’importe quel langage n’est pas de m’asseoir et de lire un livre dessus juste pour l’apprendre, mais d’avoir un but en tête:

Je veux automatiser X.

Je commence alors à réfléchir au problème, puis j’utilise Internet pour trouver la syntaxe qui me permettra d’aller de A à B.

Par exemple, il y a des années, je voulais suivre les temps de fonctionnement de mon système, alors que je venais de passer de Windows qui devait être redémarré toutes les 48 heures et aussi parce que j’étais un gros nerd. Je me moquais d’un ami en ligne avec ça, je voulais donc mettre à jour le temps de fonctionnement de mon système ici à la maison, sur une page web qui était hébergée hors d’Internet, sur un serveur dans un autre état.

Comment faire ça?

Bien, tout d’abord, comment puis-je commencer à faire un script qui va réellement s’exécuter.

#!/bin/bash <- Oh, specifies the script interpreter. LEARNED.

Hm, il ne s’exécute toujours pas…

# chmod +x <- Oh, needs execute bit set. LEARNED.

Maintenant, comment récupérer l’uptime ? Eh bien, je pourrais démonter la commande uptime, mais une des fonctionnalités que je voulais était de suivre mon « record uptime ». La commande uptime de Linux affiche les temps de fonctionnement sous une forme lisible par l’homme:

13:23:54 up 32 days, 4:19

Eh bien, c’est un peu difficile à analyser comme supérieur ou inférieur à. C’est possible, mais il doit y avoir un moyen plus simple. Je me demande d’où le programme « uptime » tire ces données ? Un peu de google me fait découvrir le système /proc:

/proc/uptime

Comment puis-je lire cela ? Il y a plusieurs façons. La façon que j’ai utilisée par habitude (et c’est probablement la mauvaise façon car la commande cat n’est pas vraiment destinée à cela 🙂

cat /proc/uptime

Qui renvoie :

2780345.41 5546896.19

OK, maintenant nous avons de belles décimales qui permettent de déterminer plus facilement si c’est un temps de fonctionnement record. Mais comment puis-je saisir cela dans une variable ? J’ai lu un peu plus en ligne sur les rétro-citations :

UPTIME=`cat /proc/uptime`

Cool, maintenant je l’ai dans une variable. Note mentale, vous pouvez lire toutes sortes de choses intéressantes dans les variables de cette façon. Je dois m’en souvenir à l’avenir. APPRIS. Aussi, c’est quoi ce truc /proc ? Ooh, toutes sortes de bonnes choses là-dedans comme:

cat /proc/cpuinfo

OK donc maintenant j’ai ce grand nombre décimal. Comment je le convertis en jours, pour avoir des temps de fonctionnement comme « 23.8 jours » ? De plus, cat /proc/cpuinfo renvoie deux nombres. Lequel dois-je vouloir ? Et comment puis-je les séparer pour n’avoir que ce nombre ? J’ai lu un peu plus. Il y a plusieurs façons de séparer une chaîne de caractères, mais la première chose que je rencontre est la commande cut. Comment l’utiliser avec une chaîne de caractères ? Je lis un article sur le piping et la redirection. Je vois que les deux nombres sont séparés par un espace comme délimiteur, donc:

NUMBERIWANT=`echo ${uptime} | cut -d " " -f 1`

Cool. Je dois m’en souvenir. Je peux faire des choses intéressantes avec ce tuyau. Je classe cela mentalement, avec la commande cut, qui sera l’un des outils de ligne de commande les plus utiles que j’ai rencontrés.

Maintenant, comment transformer cela en jours…hm, décevant, bash a un support mathématique de merde. Hm, cet article parle de bc. Un peu d’expérimentation et:

uptime=`echo "scale=2; $uptime/86400" | bc`

Donc bc est le programme utilisé pour faire le calcul. Il faudra que je m’en souvienne. J’ai appris les guillemets et le pipe dans les étapes précédentes, il était donc évident de les utiliser ici.

Maintenant, comment puis-je faire un écho de ceci dans un fichier texte que je peux utiliser comme un include PHP sur le site web (PHP a appris à peu près de la même manière)?

Ah, la redirection!

echo $uptime > ./uptime.txt

Et ainsi de suite. Si je regarde mes anciens scripts (celui-ci inclus), le codage est inefficace et pas nécessairement comme je le ferais maintenant. Mais en suivant ce processus au fil des ans, mes compétences et mes connaissances s’améliorent, et en me mettant dans le pétrin par de mauvaises pratiques, j’apprends comment ne pas faire les choses. Mes méthodologies s’améliorent de sorte que les scripts sont plus maintenables — non pas en restant assis dans une salle de classe ou en lisant un livre, mais en me foutant dans la merde et en apprenant de cela.

NOTE : je ne suis pas un développeur professionnel. J’écris des scripts principalement pour mes propres besoins (hobbyistes). Je sais que les personnes ayant une formation en informatique peuvent avoir des objections à cette méthode d’apprentissage, mais cela a jusqu’à présent bien fonctionné pour moi. Et c’est très amusant parce que plutôt que d’être une sorte d’exercice de lecture et de mémorisation au travail, j’obtiens quelque chose « hors de lui » au fur et à mesure – des scripts utiles.

A propos — mettez ceci dans vos favoris si vous ne l’avez pas fait. C’est fantastique :

Guide de script Bash avancé — la plupart de ce que je connais de Bash vient de là.