Notezbeta
Volver al blog

Cómo tomar notas desde la terminal

terminalDenis Povarov

Si pasas el día en una terminal, cambiar a una app de notas gráfica para apuntar una idea es un cambio de contexto que pagas dos veces: una para llegar y otra para recuperar la concentración al volver. Tomar notas directamente desde la línea de comandos te ahorra los dos pagos. Este artículo repasa los enfoques principales, desde archivos de texto sin dependencias hasta herramientas CLI dedicadas, y cuándo tiene sentido cada uno.

Por qué la terminal es un buen lugar para tomar notas

Tres propiedades hacen de la shell un lugar especialmente bueno para capturar:

  • Ya estás ahí. A mitad de una depuración, de un despliegue o de una revisión de código, el prompt tiene el foco y está esperando.

  • La salida es texto. Los mensajes de error, los tests que fallan y la salida de los comandos pueden ir por pipe directamente a una nota, en lugar de hacerles una captura de pantalla o teclearlos de nuevo.

  • Funciona en todas partes. Por SSH, dentro de tmux, en una máquina de CI: donde corre una shell, corre tu método de captura.

El punto débil habitual de tomar notas en la terminal está en el otro extremo: encontrarlas. Los archivos de texto se acumulan, y lo difícil es dar con la línea correcta tres meses después. Ten en cuenta esa contrapartida al elegir un enfoque.

Enfoque 1: un archivo plano en el que solo añades líneas

El sistema más simple que funciona:

Bash 
echo "$(date +%F) - use SIGTERM not SIGKILL in the entrypoint" >> ~/notes.md

Envuélvelo en una función de shell y se convierte en un hábito de un par de teclas:

Bash 
note() { echo "$(date +%F) $*" >> ~/notes.md; }

Para encontrar algo: grep -i keyword ~/notes.md. No cuesta nada, se sincroniza con lo que sea que sincronice tu directorio personal y nunca se rompe.

Sus límites aparecen con el volumen: un único archivo plano no tiene estructura, grep solo encuentra palabras exactas y las notas no pasan a una segunda máquina a menos que configures tú mismo la sincronización.

Enfoque 2: notas en tu editor, abierto desde la shell

vim ~/notes/$(date +%F).md o un pequeño script que abre la nota del día te da un editor de verdad y un archivo por día. Las herramientas de esta familia (scripts de notas diarias, nb, CLIs de diario) añaden la estructura justa — archivos con fecha, a veces etiquetas — sin dejar de ser locales y automatizables con scripts.

Funciona bien cuando las notas ocupan más de una línea. El precio es que abrir un editor ya no es una captura de dos segundos, sino una pequeña tarea en sí misma, y por SSH puede que tu configuración del editor no esté.

Enfoque 3: una CLI de captura con una bóveda sincronizada detrás

El tercer enfoque separa la captura del almacenamiento: una CLI pequeña cuyo único trabajo es tomar texto de tu shell y meterlo en un sistema de notas que se encarga, en otra parte, de la búsqueda, la sincronización y la organización.

Es el modelo que usa Notez CLI. Es un binario de 3 MB para macOS, Linux y Windows; después de un único notez login, capturar es así:

Bash 
notez "the flaky test is timezone-dependent — freeze the clock"
echo "worth keeping" | notez
notez --title "Postmortem notes" "timeline starts 14:02 UTC"

Las notas llegan a un espacio de trabajo al que también accedes desde una app web, así que encontrarlas no depende de grep: la búsqueda funciona por significado (buscar "flaky tests" encuentra la nota de la zona horaria), y lo capturado puede etiquetarse más tarde, enlazarse con otras notas o ampliarse en un editor completo. Las URL se detectan solas y se guardan como marcadores, y la salida --json hace que la CLI sirva en scripts y en hooks de git.

La contrapartida es la imagen especular de los archivos de texto: ganas búsqueda, sincronización y estructura, y a cambio tus notas viven en un servicio en lugar de en un único archivo local. Si eso te importa, comprueba que haya una salida: Notez, por ejemplo, exporta un espacio de trabajo entero como un .zip de archivos Markdown con sus adjuntos, un listón razonable para exigirle a cualquier herramienta.

Patrones que funcionan en cualquier sistema

Elijas el enfoque que elijas, unos cuantos hábitos hacen que las notas de la terminal te sirvan de verdad más adelante:

Usa pipes, no vuelvas a teclear

El mejor argumento a favor de capturar en la terminal es que el material ya está delante de ti, en forma de texto:

Bash 
./run-tests.sh 2>&1 | tail -20 | notez --title "auth test failure"

Una nota con la salida real del error vale por diez que la parafrasean.

Captura soluciones, no solo problemas

La nota más valiosa en la bóveda de un desarrollador es "esto es lo que lo arregló". Cuando algo por fin funciona, escribe la causa en una línea. Dentro de unos meses buscarás el mensaje de error y encontrarás la respuesta.

La fecha, automática; el título, solo si hace falta

Deja que la herramienta registre cuándo se creó la nota. Los títulos son opcionales en las capturas rápidas: una nota que tardaste dos segundos en escribir ya es una victoria aunque no tenga título, y la búsqueda por significado no necesita títulos para encontrarla.

Una sola bandeja de entrada

Manda todas las capturas rápidas a un solo lugar y clasifícalas después (o nunca). En cuanto te obligas a elegir un destino al capturar, vuelves a meter la fricción que intentabas quitar.

Cómo elegir entre los enfoques

  • Archivo plano: no quieres ninguna dependencia y tus notas son memoria de trabajo de corta vida.

  • Editor + archivos con fecha: tus notas son más largas y trabajas en una sola máquina.

  • CLI de captura + bóveda sincronizada: capturas a menudo, desde varias máquinas, y encontrar importa tanto como capturar.

Los enfoques también se combinan. Mucha gente tiene un archivo borrador para lo efímero y una bóveda sincronizada para todo lo que valga la pena volver a encontrar. La única regla real es que capturar sea lo bastante barato como para que lo hagas de verdad: un sistema de notas que usas a diario gana a uno elaborado que no usas.

Sigue leyendo