Mauvaise hygiène de la ligne de commande ? Envisagez de porter la charge de l'histoire de la coque

J'ai une mauvaise hygiène de ligne de commande. Quand je rêve fiévreusement qu'un pipeline utile existe, je l'engage très rarement dans une configuration shell quelque part. Au lieu de cela, je laisse fzf le draguer un peu plus tard quand j'en ai besoin. Mes fonctions ne sont pas documentées, ont des noms et des variables horriblement courts parce que j'ai tendance à coder le golf, et sont spécifiques au cas d'utilisation du moment et non générales.

J'ai depuis décidé que c'était l'approche optimale.

Reprenez cette déclaration, espèce de déviant

Non! Je le crois vraiment. J'ai des raisons.

La notion d'histoire de commande ou de coquille dans notre profession est un mécanisme profondément sous-estimé.

Considérez le fait que - si vous conservez tout l'historique et exprimez toutes vos tâches opérationnelles sous la forme de commandes de terminal - vous pouvez avoir l'historique complet de votre travail (à l'exception des artefacts de codage) à portée de quelques secondes. Comment créez-vous des certificats x509 avec openssl ? Quel est le moyen le plus simple de vérifier la présence de Spectre parmi une flotte d'hôtes ? Si vous pouvez rappeler quelques sous-chaînes des commandes qui peuvent répondre à la question, une recherche dans l'historique peut mettre cette mémoire perdue à portée de main pour être réutilisée immédiatement.

Imaginez comment une autre profession peut valoriser ce type de rappel instantané, infiniment retenu, sans effort pour enregistrer, qui se traduit par une action immédiatement utilisable. Un avocat soumettant un type particulier de document juridique? Un enseignant notant une série de tests ? Vous pouvez probablement penser à plus, mais ce que je veux dire, c'est que le concept d'histoire du shell à l'intersection du travail d'ingénierie logicielle des cols blancs a un potentiel énorme.

Voici un exemple réel tiré de mon propre travail. Votre cas d'utilisation peut être différent, mais une situation que je rencontre parfois est de desceller une instance Vault pour un hôte que j'ai arrêté pour quelque chose comme une mise à jour du noyau. La boucle de rétroaction ressemble à ceci :

• Ah, je dois desceller cette instance de Vault. Où était ma clé de descellement encore ?

  • Oh ouais, c'est à Bitwarden. Je peux le saisir avec rbw :

     rbw get 'Vault Unseal Key'

• Et mince. Quelle instance doit être descellée ?

  • Je suppose que je peux demander au consul :

     http :8500/v1/health/state/critical

  • Oh. Puis-je obtenir ces nœuds sous forme de liste de points de terminaison que je peux utiliser avec autre chose ?

     http :8500/v1/health/state/critical \ | jq -r '.[].ServiceID' \ | awk -F: '{ print "http://" $2 ":" $3; }'

    Note : Ceci est un sous -exemple, car je ne connais pas ce pipeline par cœur. Je commence par la commande httpie , puis j'appuie sur la commande jq , puis sur le filtre awk de manière itérative, en exécutant la commande entre les canaux ajoutés pour voir ce que j'obtiens entre les deux.

• D'accord. J'ai ma clé de descellement et le ou les terminaux qui doivent être descellés. Je peux les coller ensemble avec une boucle zsh :

   http :8500/v1/health/state/critical \ | jq -r '.[].ServiceID' \ | awk -F: '{ print "http://" $2 ":" $3; }' \ | while read -rh do VAULT_HOST=$h vault operator unseal $(rbw get 'Vault Unseal Key') done

La commande finale ici est brusque et en quelque sorte obtuse. Il n'est pas difficile de voir comment vous pourriez nettoyer cela et le placer dans une fonction ou un script shell soigneusement codifié : une variable pour ma clé de descellement Vault, une fonction pour extraire une liste d'hôtes scellés, etc.

Mais je fais beaucoup ce genre de short-scripting. Et la "quantité de petits pipelines que j'écris ⨉ le temps qu'il faut pour les transformer en bons scripts shell et que je mets dans le bon fichier et que je m'engage dans mon repo dotfiles" serait vraiment non négligeable. Alors je m'en passe !

J'avais l'habitude de me juger pour cela. Cependant, au cours de nombreuses années, le nombre de fois où je me suis reproché de ne pas avoir enregistré mes nombreux pipelines dans un script quelque part par rapport à mon historique de shell est très faible, voire inexistant.

J'ai eu un gros regret : ne pas les avoir emmenés avec moi sur mes postes de travail. Mais saviez-vous qu'il existe des outils spécialement conçus pour vous aider à transporter votre historique de shell avec vous ? Ce n'est plus un gros problème !

Alors, que se passe-t-il lorsque vous concluez des actions importantes et parfois compliquées dans votre histoire de shell, que vous le faites souvent et que vous laissez votre .shell_history se transformer en un jardin magnifique et terrifiant ?

Vous pouvez faire tellement de choses , et les frais généraux pour a) enregistrer ces raccourcis et b) les utiliser sont essentiellement sans friction. Avec la puissance de quelque chose comme fzf à portée de main, l' historique complet de votre carrière professionnelle dans le travail en ligne de commande devient disponible à tout moment. Vous n'êtes pas contraint à ce que vous pensiez valoir la peine de surmonter tout obstacle à l'enregistrement pour la postérité. Tout est là, et vous n'avez pas eu à penser à documenter quoi que ce soit.

Par exemple : je n'ai pas travaillé directement avec des métriques S3 de bas niveau depuis longtemps. Mais je me souviens avoir eu besoin d'agréger le trafic total via un compartiment S3 dans le passé. Je peux trouver la commande pour répondre à cette question pour vous en environ deux secondes en tapant Ctrl-r aws s3 statistics <RET> :

 today="$(date +%s)" for bucket in $(aws s3 ls | awk '{ print $NF; }') do echo -n "$bucket " aws cloudwatch get-metric-statistics \ --namespace AWS/S3 \ --start-time "$(echo $today - 86400 | bc)" --end-time "$today" \ --period 86400 \ --statistics Average \ --region us-east-1 \ --metric-name BucketSizeBytes \ --dimensions Name=BucketName,Value=$bucket Name=StorageType,Value=StandardStorage \ | jq '.Datapoints[].Average' \ | gnumfmt --to=si done

Cela ne peut probablement pas être utilisé à 100% tel qu'il est écrit pour une tâche similaire quelques années plus tard, mais écrasez ce Ctrl-x Ctrl-e , modifiez-le rapidement et passez à autre chose. Pas trop difficile, et vous pouvez voir pourquoi s'engager dans quelque chose de très formel comme une fonction shell ne vaut tout simplement pas la surcharge. C'était spécifique à l'époque, il doit être adapté maintenant, et l'utiliser dans ce contexte est un très bon match pour "prenez-le de mon histoire et modifiez-le".¹

tl;dr

Essaye ça:

• Ajustez la configuration de l'historique de votre shell pour conserver beaucoup d'historique. Peut-être même configurer quelque chose comme atuin pour l'emporter partout où vous allez (ou au moins utiliser l'intégration de l'historique de fzf pour améliorer votre Ctrl-r )
• Là où vous le pouvez, essayez d'exprimer des tâches ou des unités de travail dans des commandes shell autonomes.² Cela signifie des commandes shell plus longues et plus enchaînées, mais c'est bien ! Votre objectif est d'accumuler progressivement une bibliothèque de petits programmes qui peuvent remplacer vos actions qui pourraient autrement être manuelles.
• Votre futur moi vous remerciera d'aujourd'hui lorsque vous pourrez réutiliser une commande qui fait quelque chose de difficile ou de compliqué en quelques frappes.

Notes de bas de page

¹ Je reconnaîtrai que des exemples comme une panne un peu dans une situation d'équipe. Bien que je puisse augmenter notre trafic S3 en une seconde, comment diffusez-vous ces connaissances et ces capacités aux autres ? De grands référentiels de documents et de scripts peuvent résoudre ce problème, mais mon objectif dans cet article est de souligner le fait que le faible coût de friction et le faible coût de barrière à l'entrée sont ce qui fait briller l'histoire. Il existe peut-être un bon moyen de faire en sorte que cela et le partage d'équipe fonctionnent en tandem.

² Il y a un autre article enfoui ici à propos du "premier travail en ligne de commande", mais il suffit de souligner que je pense qu'il y a de grands avantages à regrouper autant de travail que possible sous forme de ligne de commande. Les actions facilement rappelées sous forme d'historique du shell sont un avantage parmi de nombreux autres comme l'interopérabilité, la répétabilité, etc.

Également publié ici .