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   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. fzf  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   l'historique et exprimez   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   ? Quel est le moyen le plus simple de vérifier la présence de   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. tout toutes openssl Spectre  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   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 : parfois est de desceller une instance Vault  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; }'    : Ceci est un   -exemple, car je ne connais pas ce pipeline par cœur. Je commence par la commande   , puis j'appuie sur la commande   , puis sur le filtre   de manière itérative, en exécutant la commande entre les canaux ajoutés pour voir ce que j'obtiens entre les deux. Note sous httpie jq awk  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   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   non négligeable. Alors je m'en passe ! beaucoup ⨉ vraiment  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   pour vous aider à transporter votre historique de shell avec vous ? Ce n'est plus un gros problème ! des outils spécialement conçus  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   se transformer en un jardin magnifique et terrifiant ? .shell_history  Vous pouvez faire   , 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   à portée de main, l'   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. tellement de choses fzf historique complet de votre carrière professionnelle dans le travail en ligne de commande  Par exemple : je n'ai pas travaillé directement avec des métriques S3 de bas niveau depuis longtemps. Mais je   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   : me 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   , 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".¹ Ctrl-x Ctrl-e  tl;dr  Essaye ça:  Ajustez la configuration de l'historique de votre shell pour conserver   d'historique. Peut-être même configurer quelque chose comme   pour l'emporter partout où vous allez (ou au moins utiliser l'intégration de l'historique   pour améliorer votre   ) beaucoup atuin de fzf 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

Alongside

Glue

2022 - HackerNoon Contributor of the Year - Freelancing

2022 - HackerNoon Contributor of the Year - Linux

Nominated for 2022 - HackerNoon Contributor of the Year - Freelancing

Nominated for 2022 - HackerNoon Contributor of the Year - Linux

Freelance Writer & Consultant

Cet audio est produit dans la langue originale de l'histoire !

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

About Author

COMMENTAIRES

ÉTIQUETTES

CET ARTICLE A ÉTÉ PARU DANS

Related Stories

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Valhalla de Floki se joint en tant que sponsor associé de la tournée indienne au Sri Lanka

La fuite de l'invite du système Claude Sonnet 3.5 : une analyse médico-légale

Les couches invisibles : pourquoi les entretiens avec les utilisateurs sont un atout irremplaçable

Naviguer sur les eaux : développer des applications RAG de qualité production avec des lacs de données

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps