English

Write Terminal Commands In Plain English

Nadie recuerda todos los flags. Sabes perfectamente lo que quieres que haga la shell —listar las imágenes de un directorio, renombrar un lote de archivos, encontrar lo que más ocupa en disco— y aun así pierdes cuatro minutos con un resultado de búsqueda que lo responde a medias. La terminal de Cursor elimina ese desvío: presiona el atajo de edición en línea, escribe la petición en lenguaje natural y él escribe el comando ahí mismo. Lo más importante viene después: lees el comando antes de presionar enter.

Qué hace realmente

La terminal de Cursor tiene un prompt de edición en línea, la misma idea que la edición en línea del editor, pero conectada a la shell en lugar de a un archivo. Lo activas y aparece un cuadro de texto sobre la línea de comandos. Escribe lo que quieres con el lenguaje que usarías para explicárselo a un colega —"lista todas las imágenes del directorio public"— y Cursor reemplaza tu frase por un comando real, listo para ejecutar.

En el recorrido de la fuente el flujo es exactamente ese: la petición se escribe como una frase corriente, aparece el comando, enter lo ejecuta y se listan las imágenes del directorio public. Sin buscar sintaxis, sin cazar flags.

El atajo en sí merece una nota de precisión. El recorrido lo describe solo como "presionando control": en Cursor y en los editores de la familia VS Code la combinación de edición en línea es convencionalmente Ctrl-K en Windows y Linux y Cmd-K en macOS, pero la fuente no deletrea la letra, y los atajos cambian entre versiones y mapas de teclado personalizados. Si la combinación no te abre un prompt, revisa los atajos de teclado de tu editor buscando la acción de edición en línea o de generar comando, en vez de asumir que la función no existe.

Tolera errores de escritura

No tienes que escribir la petición con cuidado. La fuente es explícita: un error ortográfico en la petición en lenguaje natural igual produjo el comando correcto. Parece un detalle menor, pero cambia cómo se siente la función en la práctica: puedes escribir rápido, a media idea, sin revisar una frase que solo va a leer un modelo. La intención sobrevive al error de tecleo.

Por eso también funciona bien para los comandos que usas poco. No necesitas recordar si el flag era -name o --name; solo necesitas poder describir el resultado.

Cuando escribe un comando para la shell equivocada

Los comandos generados no son agnósticos de la shell, y este es el fallo que de verdad te vas a encontrar. bash y zsh comparten casi toda su superficie. PowerShell no: distinta semántica de tuberías, distintos nombres de comandos, distinto entrecomillado. Un comando perfectamente correcto para una shell Unix simplemente falla en una terminal de Windows.

Eso pasó en el recorrido de la fuente: los comandos generados fallaron en Windows Terminal y hubo que modificarlos para que funcionaran con PowerShell, tras lo cual sí corrieron. La receta práctica:

1. Ejecuta el comando y deja que falle o, mejor, detecta el desajuste antes de ejecutarlo.
2. Copia el texto del error.
3. Vuelve a abrir el prompt en línea y pega el error, o di directamente cuál es tu shell: "esto es PowerShell, reescríbelo".
4. Lee el comando nuevo y ejecútalo.

Decirle tu shell desde el principio es la versión barata del mismo ciclo. "En PowerShell, lista todas las imágenes del directorio public" te ahorra la ida y vuelta.

Lee el comando antes de ejecutarlo

Esta parte no es negociable. Un comando de shell no es una sugerencia que puedas deshacer: se ejecuta con tus permisos, sobre tu sistema de archivos, de inmediato. La generación de texto es muy buena produciendo algo que parece correcto, y "parece correcto" y "hace lo que yo quería" son propiedades distintas. Un rm generado con un glob ligeramente equivocado, un mv que aplana un árbol de directorios, un comando que alcanza más allá de la carpeta en la que estabas pensando: todo eso tiene aspecto plausible.

La fuente lo dice sin rodeos: deberías entender lo que estás haciendo, y al final del día lo que tú sabes es lo que cuenta. Trata el comando generado como un borrador escrito por alguien rápido y seguro de sí mismo que nunca ha visto tu máquina. En concreto, antes de presionar enter:

• Revisa el verbo. ¿Lee o escribe? Cualquier cosa que borre, mueva, sobrescriba o haga force push merece una segunda lectura.
• Revisa el destino. ¿La ruta apunta a donde crees, y está acotada, o hay un comodín que abarca más de lo que querías?
• Busca sudo y -f/--force. Si no pediste permisos elevados ni una operación forzada, pregúntate por qué están ahí.
• Haz una pasada en seco cuando la herramienta lo permita. --dry-run, -n, o listar antes de borrar cuesta segundos y salva tardes enteras.

Si no puedes decir qué hace un comando, esa es la señal para pedir una explicación —en el mismo cuadro de texto— en lugar de ejecutarlo para averiguarlo.

Dónde vale la pena

• Herramientas que usas poco. find, tar, ffmpeg, awk: comandos cuyos flags reaprendes cada vez que los necesitas.
• Operaciones puntuales por lotes. Renombrar o reorganizar un conjunto de archivos donde la forma de la operación es obvia pero la sintaxis no.
• Trabajo multiplataforma. Cuando conoces la operación pero no el modismo de la shell en la que estás hoy.
• Aprender. Generar un comando y después leerlo es una forma decente de aprender la sintaxis de verdad, siempre que lo leas.