Casi todo lo que un foxero ha programado en su vida tiene ventanas: formularios, Grid, botones, informes. La consola, esa ventana negra donde se escriben órdenes, se queda para el técnico de sistemas o para el que viene de Linux. Y sin embargo cada vez hay más cosas que solo se hacen desde ahí: git, los programadores de tareas, los servidores sin escritorio y, desde hace poco, los agentes de IA, que trabajan lanzando órdenes y leyendo lo que devuelven.

Tutoriales de línea de comandos hay miles, pero los escribe gente que no ha abierto un .pjx en su vida. Este curso va al revés: parte de lo que tú ya sabes de VFP y lo usa de puente. Son cinco entregas cortas:

  1. Qué es una CLI (esta).
  2. Anatomía de una orden: comandos, argumentos, opciones y posicionales.
  3. Entrada, salida y error, y el código de salida.
  4. Leer y escribir una ayuda.
  5. Usar CLIs desde VFP, bien hecho.

Todo lo que sale aquí lo he ejecutado en un Windows 11 en español. Si el tuyo está en otro idioma, los textos cambian, pero las órdenes son las mismas.

Ya has usado una línea de comandos

Abre Visual FoxPro. Esa ventana que pone Command (o Comandos) es una línea de comandos: escribes una orden, pulsas Enter y sale el resultado.

Tres órdenes en la ventana de comandos de VFP
? DATE()
? VERSION()
DIR *.prg

No hay botones ni menús. Tú escribes texto, VFP lo interpreta, hace algo y te contesta con más texto. Una CLI (command-line interface, interfaz de línea de comandos) es eso mismo, pero fuera de VFP: un programa que se maneja escribiendo órdenes en lugar de pulsando en ventanas.

La primera orden en la consola de Windows

Pulsa Windows + R, escribe cmd y pulsa Enter. Se abre una ventana con algo parecido a C:\Users\tunombre> y un cursor parpadeando. Ese texto es el prompt: te dice en qué carpeta estás y que espera una orden, como el cursor de la ventana de comandos de VFP.

Escribe esto y pulsa Enter:

ping -n 2 127.0.0.1

Tiene que salir algo así:

La consola de Windows después de ejecutar ping -n 2 127.0.0.1: dos respuestas de 127.0.0.1 y las estadísticas, con 0 paquetes perdidos

ping comprueba si otra máquina contesta por la red. 127.0.0.1 es tu propio equipo, así que siempre contesta, y -n 2 le dice que lo intente dos veces en lugar de las cuatro que hace por defecto. Qué es cada pieza de esa orden lo vemos en la entrega 2.

Prueba también ver (la versión de Windows) y dir (los ficheros de la carpeta). El dir de la consola y el DIR de VFP se parecen mucho: los dos listan ficheros y los dos aceptan comodines como *.prg.

Consola, terminal e intérprete

Estas tres palabras se usan como sinónimos, y conviene separarlas desde el principio porque las vas a leer en todas partes.

El intérprete (en inglés, shell) es el programa que lee lo que escribes y lo ejecuta. En Windows hay dos:

  • cmd.exe, el de toda la vida, heredero del COMMAND.COM del MS-DOS. Es el que abriste con Windows + R.
  • PowerShell, más moderno. El que viene con Windows es el 5.1; el mío dice 5.1.26100. Hay una versión 7 que se instala aparte y se llama pwsh.

Los dos entienden órdenes sencillas como ping o dir, pero cada uno tiene su propio lenguaje para lo demás: variables, bucles, comillas. En este curso uso los dos y digo siempre cuál.

La consola o terminal es la ventana donde escribes y lees. En Windows 11 esa ventana es, por defecto, la aplicación Terminal (wt.exe), que tiene pestañas y puede abrir un cmd, un PowerShell u otro intérprete en cada una. La ventana solo pinta texto y recoge teclas; quien entiende las órdenes es el intérprete que corre dentro.

El programa que ejecutas es otra cosa más. ping es un fichero normal y corriente:

where ping
C:\Windows\System32\PING.EXE

Un .exe como el que tú generas al compilar un proyecto de VFP. En esa carpeta de mi Windows hay 663 ficheros .exe, y 270 de ellos son programas de consola como este.

Si lo llevas a VFP: la ventana Command es la terminal, el motor de VFP que interpreta ? DATE() es el intérprete, y DATE() es lo que ejecutas. La diferencia es que en la consola de Windows casi todo lo que ejecutas son programas .exe separados, y cada uno hace una sola cosa.

Desde VFP ya lanzas programas de consola

RUN (y su abreviatura !) existe en FoxPro desde los tiempos del DOS. Lanza una orden como si la escribieras en cmd:

Lanzar una orden de consola desde VFP y leer su resultado
RUN ver > version.txt
? FILETOSTR("version.txt")

Funciona, y ya tienes ahí dos ideas del curso: RUN lanza un programa de consola, y > manda lo que ese programa escribe a un fichero en lugar de a la pantalla. Hay tres cosas de RUN que tienes que saber:

  1. RUN espera a que el programa termine. Un ping -n 4 tardó 4,03 segundos, y VFP se quedó parado todo ese tiempo.
  2. RUN /N no espera. La misma orden volvió en 0,04 segundos, y el ping siguió por su cuenta.
  3. Con /N, el > no hace nada. RUN /N ping -n 1 127.0.0.1 > salida.txt no crea el fichero. Sin /N, la orden pasa por cmd.exe (el intérprete que dice la variable COMSPEC), que es quien entiende el >. Con /N, esa redirección no se hace.

Y un detalle que vas a ver en cuanto leas ese version.txt desde VFP: en el mío pone Versi¢n en lugar de Versión. La consola de Windows escribe con una página de códigos distinta de la de VFP (la 850 frente a la 1252), y las vocales con tilde salen cambiadas. Tiene arreglo, y lo vemos en la entrega 3.

La entrega 5 va entera de esto: lanzar programas de consola desde VFP, esperar o no, recoger lo que escriben y saber si han ido bien.

Por qué siguen vivas

Las CLIs son de los años setenta y siguen en todas partes porque hacen cosas que una ventana no puede:

  • Se pueden automatizar. Una orden es texto, y el texto se guarda en un .bat, se programa en el Programador de tareas de Windows para que corra a las tres de la mañana o se lanza desde otro programa. Un formulario necesita a alguien delante que pulse el botón.
  • Se pueden encadenar. La salida de un programa puede ser la entrada del siguiente, y así se montan tareas grandes con piezas pequeñas. Es lo que hace el > de antes, y hay más (entrega 3).
  • Funcionan sin escritorio. Un servidor al que te conectas en remoto, un proceso que corre como servicio, una máquina virtual en la nube: ahí no siempre hay nadie mirando una pantalla, y la consola es lo que hay.

Quién las usa hoy

Tú, aunque no lo sepas, cada vez que tu aplicación hace un RUN. Además:

  • Los scripts: los .bat y los .ps1 que alguien escribió para copiar las copias de seguridad, desplegar una versión o limpiar temporales.
  • El Programador de tareas: cada tarea programada es un programa más sus argumentos, o sea, una línea de comandos.
  • Las herramientas de programador: git, los compiladores, los instaladores silenciosos. Casi todas tienen su CLI, y muchas solo tienen eso.
  • Los agentes de IA, que es lo más nuevo. Un agente que programa contigo trabaja lanzando órdenes en una consola y leyendo lo que devuelven. Si tu herramienta tiene una CLI que escribe su resultado en un formato que se puede leer (JSON, por ejemplo), un agente la sabe usar sin que nadie le programe nada.

Para practicar

Abre un cmd con Windows + R y prueba estas órdenes. Ninguna cambia nada en tu equipo:

ver
dir C:\Windows\System32\*.exe
where notepad
ping -n 2 127.0.0.1
hostname

Luego, en la ventana de comandos de VFP:

Lo mismo, lanzado desde VFP
RUN hostname > equipo.txt
? FILETOSTR("equipo.txt")

Y fíjate en una cosa para la próxima entrega: en dir C:\Windows\System32\*.exe, ¿qué parte es el programa y qué parte es lo que le dices que haga? De eso va la entrega 2, la anatomía de una orden.