¿Pobre higiene de la línea de comandos? Considere la posibilidad de soportar la carga de la historia de Shell

Tengo poca higiene en la línea de comandos. Cuando sueño febrilmente con una tubería útil, rara vez la confío a una configuración de shell en alguna parte. Más bien, dejo que fzf lo extraiga más tarde cuando lo necesite. Mis funciones no están documentadas, tienen nombres y variables horriblemente cortos porque tiendo a codificar golf, y son específicas para el caso de uso en ese momento y no son generales.

Desde entonces he decidido que este es el enfoque óptimo.

Retira esa afirmación, desviado

¡No! De hecho, creo esto. tengo razones

La noción de un comando o historial de proyectiles en nuestra profesión es un mecanismo profundamente subestimado.

Considere el hecho de que, si conserva todo el historial y expresa todas sus tareas operativas en forma de comandos de terminal, puede tener el historial completo de su trabajo (aparte de los artefactos de codificación) al alcance de unos pocos segundos. ¿Cómo se crean certificados x509 con openssl ? ¿Cuál es la forma más fácil de buscar Spectre entre una flota de hosts? Si puede recordar algunas subcadenas de los comandos que pueden responder a la pregunta, una búsqueda en el historial puede traer esta memoria perdida a su alcance para reutilizarla de inmediato.

Imagínese cómo otra profesión puede valorar este tipo de recuperación instantánea, infinitamente retenida y sin esfuerzo para grabar que se traduce en una acción de uso inmediato. ¿Un abogado que presenta un tipo particular de documento legal? ¿Un maestro calificando una serie de pruebas? Probablemente pueda pensar en más, pero mi punto es que el concepto de la historia de shell en la intersección del trabajo de ingeniería de software de cuello blanco tiene un potencial tremendo.

Aquí hay un ejemplo real tomado de mi propio trabajo. Su caso de uso puede ser diferente, pero una situación con la que me encuentro a veces es abrir una instancia de Vault para un host que desactivé para algo como una actualización del kernel. El bucle de retroalimentación se parece a esto:

• Ah, tengo que abrir esta instancia de Vault. ¿Dónde estaba mi llave de apertura otra vez?

  • Oh sí, está en Bitwarden. Puedo agarrarlo con rbw :

     rbw get 'Vault Unseal Key'

• Tonterías. ¿Qué instancia necesita ser desbloqueada?

  • Supongo que puedo preguntarle al Cónsul:

     http :8500/v1/health/state/critical

  • Vaya. ¿Puedo obtener esos nodos como una lista de puntos finales que puedo usar con otra cosa?

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

    Nota : este es un subejemplo , porque no me sé esa canalización de memoria. Comienzo con el comando httpie , luego aplico el comando jq y luego filtro awk de forma iterativa, ejecutando el comando entre las canalizaciones agregadas para ver qué obtengo en el medio.

• Bueno. Tengo mi clave de desellado y los puntos finales que necesitan ser desellados. Puedo pegarlos con un bucle 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

El comando final aquí es brusco y algo obtuso. No es difícil ver cómo podría limpiar esto y colocarlo en una función o script de shell perfectamente codificado: una variable para mi clave de desbloqueo de Vault, una función para extraer una lista de hosts sellados, etc.

Pero hago mucho este tipo de guiones cortos. Y el número de "cantidad de pequeñas canalizaciones que escribo ⨉ el tiempo que se tarda en convertirlos en buenos scripts de shell y los coloco en el archivo correcto y me comprometo con mi repositorio de dotfiles " no sería trivial. ¡Así que me lo salto!

Solía juzgarme a mí mismo por esto. Sin embargo, en el transcurso de muchos años, la cantidad de veces que me he criticado por no registrar mis muchas canalizaciones en un script en algún lugar en lugar de en mi historial de shell es muy pequeña o inexistente.

Tuve un gran arrepentimiento: cuando no los llevé conmigo a través de mis estaciones de trabajo. Pero, ¿sabía que existen herramientas diseñadas específicamente para ayudarlo a llevar consigo su historial de shell? ¡Eso ya no es un gran problema!

Entonces, ¿qué sucede cuando envuelve acciones grandes y, a veces, complicadas dentro de su historial de shell, lo hace con frecuencia y deja que su .shell_history se convierta en un jardín hermoso y aterrador?

Puede hacer muchas cosas , y la sobrecarga tanto para a) registrar esos accesos directos como b) usarlos es esencialmente sin fricciones. Con el poder de algo como fzf al alcance de su mano, la historia completa de su carrera profesional en el trabajo de la línea de comandos está disponible en cualquier momento. No estás limitado a lo que sentiste que valía la pena superar ninguna barrera para registrarlo para la posteridad. Todo está ahí, y no tenías que pensar en documentar nada de eso.

Como ejemplo: no he trabajado directamente con métricas S3 de bajo nivel en mucho tiempo. Pero sí recuerdo haber tenido que agregar el tráfico total a través de un depósito S3 en el pasado. Puedo encontrar el comando para responder esa pregunta en unos dos segundos escribiendo 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

Esto probablemente no se pueda usar al 100% tal como está escrito para una tarea similar unos años más tarde, pero destruya ese Ctrl-x Ctrl-e , edítelo rápidamente y continúe. No es demasiado difícil, y puede ver por qué comprometer esto con algo muy formal como una función de shell no vale la pena. Era específico entonces, necesita ser adaptado ahora, y usarlo en este contexto es una muy buena combinación para "tomarlo de mi historial y modificarlo".¹

tl; dr

Prueba esto:

• Modifique la configuración de su historial de shell para retener una gran cantidad de historial. Tal vez incluso configure algo como atuin para llevarlo a donde quiera que vaya (o al menos use la integración de historial de fzf para mejorar su Ctrl-r )
• Siempre que pueda, intente expresar tareas o unidades de trabajo dentro de comandos de shell autónomos.² Esto significa comandos de shell más largos y más encadenados, ¡pero está bien! Tu objetivo es acumular gradualmente una biblioteca de pequeños programas que puedan reemplazar cualquier acción tuya que, de lo contrario, podría ser manual.
• Tu yo del futuro agradecerá a tu yo del presente cuando puedas reutilizar un comando que hace algo difícil o complicado con unas pocas pulsaciones de teclas.

notas al pie

¹ Reconozco que ejemplos como romperse un poco en una situación de equipo. Aunque puedo aumentar nuestro tráfico de S3 en un segundo, ¿cómo distribuyen ese conocimiento y capacidad a otros? Los grandes repositorios de documentos y scripts pueden resolver esto, pero mi propósito en esta publicación es resaltar el hecho de que el bajo costo de fricción y el bajo costo de barrera de entrada es lo que hace que la historia brille. Tal vez haya una buena manera de hacer que eso y el equipo compartido funcionen en conjunto.

² Hay otra publicación enterrada aquí sobre "el primer trabajo de la línea de comandos", pero basta con enfatizar que creo que se pueden obtener grandes beneficios al consolidar tanto trabajo como sea posible en forma de línea de comandos. Las acciones fáciles de recordar en forma de historial de shell son un beneficio junto con muchos otros, como la interoperabilidad, la repetibilidad y más.

También publicado aquí .