Higiene de linha de comando ruim? Considere carregar a história do Shell

Eu tenho pouca higiene na linha de comando. Quando sonho febrilmente com a existência de um pipeline útil, raramente o comprometo com uma configuração de shell em algum lugar. Em vez disso, deixo fzf -lo algum tempo depois, quando preciso. Minhas funções não são documentadas, têm nomes e variáveis terrivelmente curtos porque tendo a codificar golfe e são específicas para o caso de uso no momento e não gerais.

Desde então, decidi que esta é a abordagem ideal.

Retire essa afirmação, seu desviante

Não! Eu realmente acredito nisso. eu tenho motivos.

A noção de um comando ou histórico de shell em nossa profissão é um mecanismo profundamente subestimado.

Considere o fato de que – se você mantiver todo o histórico e expressar todas as suas tarefas operacionais na forma de comandos de terminal – poderá ter todo o histórico do seu trabalho (além dos artefatos de codificação) ao alcance de alguns segundos. Como você cria certificados x509 com openssl ? Qual é a maneira mais fácil de verificar o Spectre entre uma frota de hosts? Se você conseguir recuperar algumas substrings dos comandos que podem responder à pergunta, uma pesquisa no histórico pode trazer essa memória perdida para a ponta dos dedos para ser reutilizada imediatamente.

Imagine como outra profissão pode valorizar esse tipo de recordação instantânea, infinitamente retida e sem esforço para registrar, que se traduz em uma ação imediatamente utilizável. Um advogado apresentando um determinado tipo de documento legal? Um professor marcando um conjunto de testes? Você provavelmente pode pensar em mais, mas meu ponto é que o conceito de história de shell na interseção do trabalho de engenharia de software de colarinho branco tem um potencial tremendo.

Aqui está um exemplo real retirado do meu próprio trabalho. Seu caso de uso pode ser diferente, mas uma situação que encontro às vezes é abrir uma instância do Vault para um host que derrubei para algo como uma atualização do kernel. O loop de feedback é mais ou menos assim:

• Ah, eu tenho que abrir esta instância do Vault. Onde estava minha chave de desbloqueio de novo?

  • Ah, sim, é em Bitwarden. Eu posso pegá-lo com rbw :

     rbw get 'Vault Unseal Key'

• Porcaria. Qual instância precisa ser deslacrada?

  • Acho que posso perguntar ao Cônsul:

     http :8500/v1/health/state/critical

  • Oh. Posso obter esses nós como uma lista de pontos de extremidade que posso usar com outra coisa?

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

    Nota : Este é um sub -exemplo, porque não conheço esse pipeline de cor. Começo com o comando httpie , em seguida, coloco o comando jq e, em seguida, filtro awk iterativamente, executando o comando entre os canais adicionados para ver o que obtenho entre eles.

• OK. Eu tenho minha chave de desbloqueio e o(s) ponto(s) de extremidade que precisam ser deslacrados. Posso colá-los com um loop 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

O comando final aqui é brusco e meio obtuso. Não é difícil ver como você poderia limpar isso e colocá-lo em uma função ou script de shell bem codificado: uma variável para minha chave de abertura do Vault, uma função para extrair uma lista de hosts selados e assim por diante.

Mas eu faço muito esse tipo de script curto. E a “quantidade de pequenos pipelines que escrevo ⨉ o tempo que leva para transformá-los em bons scripts de shell e coloco no arquivo certo e confirmo em meu repositório de dotfiles” seria realmente não trivial. Então eu simplesmente pulo!

Eu costumava me julgar por isso. No entanto, ao longo de muitos anos, o número de vezes que me repreendi por não registrar meus muitos pipelines em um script em algum lugar versus no meu histórico de shell é muito pequeno ou inexistente.

Eu tive um grande arrependimento: quando não os levei comigo em minhas estações de trabalho. Mas você sabia que existem ferramentas projetadas especificamente para ajudá-lo a carregar seu histórico de shell com você? Isso não é mais um grande problema!

Então, o que acontece quando você agrupa ações grandes e às vezes complicadas em seu histórico de shell, faz isso com frequência e deixa seu histórico de .shell_history crescer em um belo e assustador jardim?

Você pode fazer muito , e a sobrecarga para a) registrar esses atalhos eb) usá-los é essencialmente sem atrito. Com o poder de algo como fzf na ponta dos dedos, toda a história de sua carreira profissional no trabalho de linha de comando fica disponível a qualquer momento. Você não está limitado ao que sentiu que valeu a pena superar qualquer barreira para registrá-lo para a posteridade. Tudo está lá, e você não teve que pensar em documentar nada disso.

Por exemplo: não trabalho diretamente com métricas S3 de baixo nível há muito tempo. Mas eu me lembro de precisar agregar o tráfego total por meio de um balde S3 no passado. Posso encontrar o comando para responder a essa pergunta para você em cerca de dois segundos digitando 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

Isso provavelmente não pode ser usado 100% conforme escrito para uma tarefa semelhante alguns anos depois, mas esmague aquele Ctrl-x Ctrl-e , faça uma edição rápida e siga em frente. Não é muito difícil, e você pode ver porque comprometer isso com algo muito formal como uma função de shell simplesmente não vale a pena. Era específico na época, precisa ser adaptado agora, e usá-lo nesse contexto é uma combinação muito boa para “pegar na minha história e ajustá-lo”.¹

tl;dr

Tente isto:

• Ajuste sua configuração de histórico de shell para reter muito histórico. Talvez até configure algo como atuin para levá-lo aonde quer que você vá (ou pelo menos use a integração do histórico do fzf para tornar seu Ctrl-r melhor)
• Onde puder, tente expressar tarefas ou unidades de trabalho dentro de comandos de shell independentes.² Isso significa comandos de shell mais longos e mais encadeados, mas tudo bem! Seu objetivo é acumular gradualmente uma biblioteca de pequenos programas que possam substituir quaisquer ações suas que, de outra forma, seriam manuais.
• Seu eu futuro agradecerá ao eu atual quando você puder reutilizar um comando que faz algo difícil ou complicado com apenas alguns toques no teclado.

notas de rodapé

¹ Reconheço que exemplos como quebrar um pouco em uma situação de equipe. Embora eu possa aumentar nosso tráfego S3 em um segundo, como você distribui esse conhecimento e capacidade para outras pessoas? Grandes repositórios de documentos e scripts podem resolver isso, mas meu objetivo neste post é enfatizar o fato de que baixo custo de fricção e baixo custo de entrada é o que faz a história brilhar. Talvez haja uma boa maneira de fazer isso e o compartilhamento de equipe funcionar em conjunto.

² Há outro post enterrado aqui sobre “primeiro trabalho de linha de comando”, mas basta enfatizar que acho que há grandes benefícios a serem obtidos ao consolidar o máximo de trabalho possível no formato de linha de comando. Ações facilmente lembradas na forma de histórico de shell são um benefício ao lado de muitos outros, como interoperabilidade, repetibilidade e muito mais.

Publicado também aqui .