Una interfaz de línea de comandos ( CLI ) es un medio para interactuar con un programa informático mediante la introducción de líneas de texto llamadas líneas de comandos . Las interfaces de línea de comandos surgieron a mediados de la década de 1960, en terminales de ordenador , como una alternativa interactiva y más fácil de usar a la interfaz no interactiva disponible con tarjetas perforadas .
En la actualidad, la mayoría de los usuarios de computadoras dependen de interfaces gráficas de usuario ("GUI") en lugar de CLI. Sin embargo, muchos programas y utilidades del sistema operativo carecen de GUI y están diseñados para usarse a través de CLI.
El conocimiento de las CLI también es útil para escribir scripts . Los programas que tienen CLI generalmente son fáciles de automatizar mediante scripts, ya que las líneas de comando, al ser meras líneas de texto, son fáciles de especificar en el código.
Las CLI son posibles gracias a los intérpretes de línea de comandos o procesadores de línea de comandos , que son programas que leen líneas de comandos y ejecutan los comandos.
Las alternativas a las CLI incluyen GUI (especialmente metáforas de escritorio con un puntero de mouse , como Microsoft Windows ), menús de interfaz de usuario basados en texto (como DOS Shell e IBM AIX SMIT ) y atajos de teclado .
En comparación con una interfaz gráfica de usuario, una interfaz de línea de comandos requiere menos recursos del sistema para su implementación. Dado que las opciones de los comandos se proporcionan en unos pocos caracteres en cada línea de comandos, un usuario experimentado suele encontrar que las opciones son más fáciles de acceder. La automatización de tareas repetitivas se simplifica mediante la edición de líneas y mecanismos de historial para almacenar secuencias utilizadas con frecuencia; esto puede extenderse a un lenguaje de programación que pueda aceptar parámetros y opciones variables. Se puede mantener un historial de la línea de comandos, lo que permite revisar o repetir los comandos.
Un sistema de línea de comandos puede requerir manuales impresos o en línea para referencia del usuario, aunque a menudo una opción de ayuda proporciona una revisión concisa de las opciones de un comando. El entorno de línea de comandos puede no proporcionar mejoras gráficas como fuentes diferentes o ventanas de edición extendidas que se encuentran en una GUI. Puede resultar difícil para un usuario nuevo familiarizarse con todos los comandos y opciones disponibles, en comparación con los íconos y menús desplegables de una interfaz gráfica de usuario, sin referencia a los manuales.
Las interfaces de línea de comandos del sistema operativo (OS) suelen ser programas distintos que se suministran con el sistema operativo. Un programa que implementa una interfaz de texto de este tipo suele denominarse intérprete de línea de comandos, procesador de comandos o shell .
Entre los ejemplos de intérpretes de línea de comandos se incluyen Nushell , el lenguaje de comandos digitales (DCL) de DEC en OpenVMS y RSX-11 , los diversos shells de Unix ( sh , ksh , csh , tcsh , zsh , Bash , etc.), CCP de CP/M , COMMAND.COM de DOS , así como los programas CMD.EXE de OS/2 y Windows , estos últimos grupos se basan en gran medida en las CLI RSX-11 y RSTS de DEC . En la mayoría de los sistemas operativos, es posible reemplazar el programa de shell predeterminado con alternativas; los ejemplos incluyen 4DOS para DOS, 4OS2 para OS/2 y 4NT / Take Command para Windows.
Aunque el término "shell" se utiliza a menudo para describir un intérprete de línea de comandos, en sentido estricto, un "shell" puede ser cualquier programa que constituya la interfaz de usuario, incluidos los totalmente orientados a gráficos. Por ejemplo, la GUI predeterminada de Windows es un programa de shell llamado EXPLORER.EXE , tal como se define en la línea SHELL=EXPLORER.EXE del archivo de configuración WIN.INI. Estos programas son shells, pero no CLI.
Los programas de aplicación (a diferencia de los sistemas operativos) también pueden tener interfaces de línea de comandos.
Un programa de aplicación puede admitir ninguno, alguno o todos estos tres tipos principales de mecanismos de interfaz de línea de comandos:
Algunas aplicaciones admiten una CLI, presentando su propio mensaje al usuario y aceptando líneas de comandos. Otros programas admiten tanto una CLI como una GUI. En algunos casos, una GUI es simplemente un contenedor alrededor de un archivo ejecutable CLI independiente . En otros casos, un programa puede proporcionar una CLI como una alternativa opcional a su GUI. Las CLI y las GUI a menudo admiten diferentes funciones. Por ejemplo, todas las características de MATLAB , un programa informático de análisis numérico , están disponibles a través de la CLI, mientras que la GUI de MATLAB expone solo un subconjunto de características.
En Colossal Cave Adventure de 1975, el usuario usa una CLI para ingresar una o dos palabras para explorar un sistema de cuevas.
La interfaz de línea de comandos evolucionó a partir de una forma de comunicación realizada por personas a través de máquinas de teletipo (TTY). En ocasiones, estas implicaban enviar una orden o una confirmación mediante télex . Los primeros sistemas informáticos solían utilizar el teletipo como medio de interacción con un operador.
El teletipo mecánico fue reemplazado por un "tty de cristal" , un teclado y una pantalla que emulaban al teletipo. Los terminales "inteligentes" permitían funciones adicionales, como el movimiento del cursor por toda la pantalla o la edición local de datos en el terminal para su transmisión al ordenador. A medida que la revolución de los microordenadores sustituyó a la arquitectura tradicional de tiempo compartido (miniordenador + terminales) , los terminales de hardware fueron reemplazados por emuladores de terminal (software de PC que interpretaba las señales de terminal enviadas a través de los puertos serie del PC ). Estos se utilizaban normalmente para interconectar los nuevos PC de una organización con sus minicomputadoras o mainframes existentes, o para conectar PC con PC. Algunos de estos PC ejecutaban el software Bulletin Board System .
Las primeras interfaces de línea de comandos de los sistemas operativos se implementaron como parte de los programas de monitorización residentes y no se podían reemplazar fácilmente. La primera implementación del shell como un componente reemplazable fue parte del sistema operativo de tiempo compartido Multics . [1] En 1964, Louis Pouzin, miembro del personal del Centro de Computación del MIT, desarrolló la herramienta RUNCOM para ejecutar scripts de comandos al tiempo que permitía la sustitución de argumentos. [2] Pouzin acuñó el término shell para describir la técnica de usar comandos como un lenguaje de programación y escribió un artículo sobre cómo implementar la idea en el sistema operativo Multics . [3] Pouzin regresó a su Francia natal en 1965 y Glenda Schroeder desarrolló el primer shell de Multics . [2]
El primer shell de Unix , el shell V6 , fue desarrollado por Ken Thompson en 1971 en Bell Labs y se basó en el shell Multics de Schroeder. [4] [5] El shell Bourne se introdujo en 1977 como reemplazo del shell V6. Aunque se utiliza como un intérprete de comandos interactivo, también fue pensado como un lenguaje de script y contiene la mayoría de las características que se consideran comúnmente para producir programas estructurados. El shell Bourne condujo al desarrollo del KornShell (ksh), el shell Almquist (ash) y el popular shell Bourne-again (o Bash). [5]
Los primeros microordenadores se basaban en una interfaz de línea de comandos como CP/M , DOS o AppleSoft BASIC . Durante los años 1980 y 1990, la introducción de Apple Macintosh y de Microsoft Windows en los PC vio cómo la interfaz de línea de comandos como interfaz de usuario principal fue reemplazada por la Interfaz Gráfica de Usuario . [6] La línea de comandos siguió estando disponible como una interfaz de usuario alternativa, a menudo utilizada por administradores de sistemas y otros usuarios avanzados para la administración del sistema, la programación informática y el procesamiento por lotes .
En noviembre de 2006, Microsoft lanzó la versión 1.0 de Windows PowerShell (anteriormente con el nombre en código Monad ), que combinaba las características de los shells tradicionales de Unix con su .NET Framework orientado a objetos propietario . MinGW y Cygwin son paquetes de código abierto para Windows que ofrecen una interfaz de línea de comandos (CLI) similar a Unix. Microsoft proporciona la implementación ksh de MKS Inc. de MKS Korn Shell para Windows a través de su complemento Servicios para UNIX .
Desde 2001, el sistema operativo Macintosh macOS se ha basado en un sistema operativo similar a Unix llamado Darwin . [7] En estas computadoras, los usuarios pueden acceder a una interfaz de línea de comandos similar a Unix ejecutando el programa emulador de terminal llamado Terminal , que se encuentra en la subcarpeta Utilidades de la carpeta Aplicaciones, o iniciando sesión remotamente en la máquina usando ssh . Z shell es el shell predeterminado para macOS; Bash, tcsh y KornShell también se proporcionan. Antes de macOS Catalina , Bash era el predeterminado.
Una CLI se utiliza siempre que un amplio vocabulario de comandos o consultas, junto con una amplia (o arbitraria) gama de opciones, se puede introducir más rápidamente como texto que con una GUI pura. Este suele ser el caso de los shells de comandos del sistema operativo . Las CLI también se utilizan en sistemas con recursos insuficientes para soportar una interfaz gráfica de usuario. Algunos sistemas de lenguaje de programación (como Python , [8] Forth , LISP , Rexx y muchos dialectos de BASIC ) proporcionan un modo de línea de comandos interactivo para permitir una rápida evaluación del código.
Las CLI suelen ser utilizadas por programadores y administradores de sistemas, en entornos científicos y de ingeniería, y por usuarios de computadoras personales con conocimientos técnicos avanzados. Las CLI también son populares entre las personas con discapacidades visuales, ya que los comandos y las respuestas se pueden mostrar mediante pantallas Braille actualizables .
El patrón general de una interfaz de línea de comandos [9] [10] es:
Comando de solicitud param1 param2 param3 … paramN
En este formato, los delimitadores entre los elementos de la línea de comandos son caracteres de espacio en blanco y el delimitador de fin de línea es el delimitador de nueva línea . Se trata de una convención muy utilizada (pero no universal).
En general, se puede considerar que una CLI consta de sintaxis y semántica . La sintaxis es la gramática que deben seguir todos los comandos. En el caso de los sistemas operativos , DOS y Unix definen cada uno su propio conjunto de reglas que deben seguir todos los comandos. En el caso de los sistemas integrados , cada proveedor, como Nortel , Juniper Networks o Cisco Systems , define su propio conjunto de reglas patentadas. Estas reglas también dictan cómo un usuario navega por el sistema de comandos. La semántica define qué tipo de operaciones son posibles, en qué tipo de datos se pueden realizar estas operaciones y cómo la gramática representa estas operaciones y datos: el significado simbólico en la sintaxis.
Dos CLI diferentes pueden estar de acuerdo en la sintaxis o la semántica, pero solo cuando están de acuerdo en ambas pueden considerarse suficientemente similares para permitir a los usuarios usar ambas CLI sin necesidad de aprender nada, así como para permitir la reutilización de scripts.
Una CLI simple mostrará un mensaje, aceptará una línea de comando ingresada por el usuario y finalizada con la tecla Enter , luego ejecutará el comando especificado y proporcionará una visualización textual de los resultados o mensajes de error. Las CLI avanzadas validarán, interpretarán y ampliarán los parámetros de la línea de comando antes de ejecutar el comando especificado y, opcionalmente, capturarán o redirigirán su salida.
A diferencia de un botón o elemento de menú en una GUI, una línea de comandos normalmente se autodocumenta, indicando exactamente lo que el usuario quiere que se haga. Además, las líneas de comandos suelen incluir muchos valores predeterminados que se pueden cambiar para personalizar los resultados. Las líneas de comandos útiles se pueden guardar asignando una cadena de caracteres o un alias para representar el comando completo, o se pueden agrupar varios comandos para realizar una secuencia más compleja (por ejemplo, compilar el programa, instalarlo y ejecutarlo), creando una sola entidad, llamada procedimiento de comando o secuencia de comandos, que en sí misma puede tratarse como un comando. Estas ventajas significan que un usuario debe descubrir un comando complejo o una serie de comandos solo una vez, porque se pueden guardar para usarlos nuevamente.
Los comandos dados a un shell CLI suelen tener una de las siguientes formas:
donde doSomething es, en efecto, un verbo , how un adverbio (por ejemplo, ¿debe ejecutarse el comando de forma verbosa o silenciosa ?) y toFiles un objeto u objetos (normalmente uno o más archivos) sobre los que debe actuar el comando. El >del tercer ejemplo es un operador de redirección, que le indica al intérprete de línea de comandos que envíe la salida del comando no a su propia salida estándar (la pantalla) sino al archivo nombrado. Esto sobrescribirá el archivo. El uso >>redirigirá la salida y la agregará al archivo. Otro operador de redirección es la barra vertical ( |), que crea una tubería donde la salida de un comando se convierte en la entrada del siguiente comando. [14]
Se puede modificar el conjunto de comandos disponibles modificando las rutas que aparecen en la variable de entorno PATH . En Unix, los comandos también deben marcarse como archivos ejecutables . Los directorios de la variable path se buscan en el orden en que se proporcionan. Al reordenar la ruta, se puede ejecutar, por ejemplo, \OS2\MDOS\E.EXE en lugar de \OS2\E.EXE, cuando el valor predeterminado es el opuesto. Cambiar el nombre de los ejecutables también funciona: la gente suele cambiar el nombre de su editor favorito a EDIT, por ejemplo.
La línea de comandos permite restringir los comandos disponibles, como el acceso a comandos internos avanzados. El CMD.EXE de Windows hace esto. A menudo, los programas shareware limitan el rango de comandos, incluida la impresión del comando "su administrador ha deshabilitado la ejecución de archivos por lotes" desde el indicador. [ Aclaración necesaria ]
Algunas CLI, como las de los enrutadores de red , tienen una jerarquía de modos , con un conjunto diferente de comandos admitidos en cada modo. El conjunto de comandos se agrupa por asociación con seguridad, sistema, interfaz, etc. En estos sistemas, el usuario puede atravesar una serie de submodos. Por ejemplo, si la CLI tuviera dos modos llamados interfaz y sistema , el usuario podría usar el comando interfaz para ingresar al modo interfaz. En este punto, es posible que los comandos del modo sistema no sean accesibles hasta que el usuario salga del modo interfaz e ingrese al modo sistema.
Un símbolo del sistema (o simplemente símbolo del sistema ) es una secuencia de (uno o más) caracteres que se utiliza en una interfaz de línea de comandos para indicar que se está listo para aceptar comandos. Literalmente, solicita al usuario que realice una acción. Un símbolo del sistema generalmente termina con uno de los caracteres $, %, #, [15] [16] : o >[ -17] y, a menudo, incluye otra información, como la ruta del directorio de trabajo actual y el nombre de host .
En muchos sistemas Unix y derivados , el mensaje normalmente termina en $o %si el usuario es un usuario normal, pero en #si el usuario es un superusuario ("root" en la terminología de Unix).
Los usuarios finales pueden modificar los mensajes de aviso. Según el entorno, pueden incluir colores, caracteres especiales y otros elementos (como variables y funciones para la hora actual, el usuario, el número de shell o el directorio de trabajo) para, por ejemplo, hacer que el mensaje de aviso sea más informativo o visualmente más agradable, para distinguir sesiones en varias máquinas o para indicar el nivel actual de anidamiento de comandos. En algunos sistemas, se pueden utilizar tokens especiales en la definición del mensaje de aviso para hacer que el intérprete de línea de comandos llame a programas externos mientras se muestra el mensaje de aviso.
En COMMAND.COM de DOS y en cmd.exe de Windows NT , los usuarios pueden modificar el indicador emitiendo un PROMPTcomando o cambiando directamente el valor de la %PROMPT% variable de entorno correspondiente . El valor predeterminado de la mayoría de los sistemas modernos, el C:\>estilo se obtiene, por ejemplo, con PROMPT $P$G. El valor predeterminado de los sistemas DOS más antiguos, C>se obtiene simplemente con PROMPT, aunque en algunos sistemas esto produce el estilo más nuevo C:\>, a menos que se use en las unidades de disquete A: o B:; en esos sistemas PROMPT $N$Gse puede usar para anular el valor predeterminado automático y cambiar explícitamente al estilo más antiguo.
Muchos sistemas Unix cuentan con la $PS1variable (Cadena de aviso 1), [18] aunque otras variables también pueden afectar al aviso (dependiendo del shell utilizado). En el shell Bash, un aviso con la forma:
[ tiempo ] usuario@host: work_dir $se puede configurar emitiendo el comando
exportar PS1 = '[\t] \u@\H: \W $' En zsh, la variable controla un mensaje$RPROMPT opcional en el lado derecho de la pantalla. No es un mensaje real, ya que la ubicación de la entrada de texto no cambia. Se utiliza para mostrar información en la misma línea que el mensaje, pero justificada a la derecha.
En RISC OS, el símbolo del sistema es un *símbolo y, por lo tanto, los comandos CLI (del sistema operativo) a menudo se denominan comandos estrella . [19] También se puede acceder a los mismos comandos desde otras líneas de comando (como la línea de comando BBC BASIC ), anteponiendo el comando con un *.
Un argumento o parámetro de línea de comandos es un elemento de información proporcionado a un programa cuando se inicia. [20] Un programa puede tener muchos argumentos de línea de comandos que identifican fuentes o destinos de información, o que alteran el funcionamiento del programa.
Cuando un procesador de comandos está activo, normalmente se invoca un programa escribiendo su nombre seguido de los argumentos de la línea de comandos (si los hay). Por ejemplo, en entornos Unix y similares , un ejemplo de argumento de la línea de comandos es:
archivo rm.sfile.ses un argumento de línea de comando que le dice al programa rm que elimine el archivo llamado file.s.
Algunos lenguajes de programación, como C , C++ y Java , permiten que un programa interprete los argumentos de la línea de comandos al manejarlos como parámetros de cadena en la función principal . [21] [22] Otros lenguajes, como Python , exponen API (funcionalidad) específicas del sistema operativo a través de sys módulo , y en particular sys.argvpara argumentos de la línea de comandos .
En sistemas operativos tipo Unix , un solo guión utilizado en lugar de un nombre de archivo es un valor especial que especifica que un programa debe manejar datos que provienen de la entrada estándar o enviar datos a la salida estándar .
Una opción de línea de comandos o simplemente opción (también conocida como bandera o interruptor ) modifica el funcionamiento de un comando; el efecto lo determina el programa del comando. Las opciones siguen al nombre del comando en la línea de comandos, separadas por espacios. No siempre se requiere un espacio antes de la primera opción, como Dir/?y DIR /?en DOS, que tienen el mismo efecto [17] de enumerar las opciones disponibles del comando DIR, mientras que dir --help(en muchas versiones de Unix) sí requiere que la opción esté precedida por al menos un espacio (y distingue entre mayúsculas y minúsculas).
El formato de las opciones varía ampliamente entre los distintos sistemas operativos. En la mayoría de los casos, la sintaxis se basa en una convención y no en un requisito del sistema operativo; la línea de comandos completa es simplemente una cadena que se pasa a un programa, que puede procesarla de cualquier forma que desee el programador, siempre que el intérprete pueda determinar dónde termina el nombre del comando y dónde comienzan sus argumentos y opciones.
Algunos ejemplos representativos de opciones de línea de comandos, todas relacionadas con el listado de archivos en un directorio, para ilustrar algunas convenciones:
En Multics , las opciones de línea de comandos y las palabras clave del subsistema se pueden abreviar. Esta idea parece derivar del lenguaje de programación PL/I , con sus palabras clave abreviadas (por ejemplo, STRG para STRINGRANGE y DCL para DECLARE). Por ejemplo, en el subsistema del foro de Multics, el parámetro -long_subject se puede abreviar como -lgsj . También es común que los comandos de Multics se abrevien, lo que normalmente corresponde a las letras iniciales de las palabras que se unen con guiones bajos para formar los nombres de los comandos, como el uso de did para delete_iacl_dir .
En algunos otros sistemas, las abreviaturas son automáticas, por ejemplo, al permitir que haya suficientes primeros caracteres de un nombre de comando para identificarlo de forma única (como SUuna abreviatura para SUPERUSER), mientras que otros pueden tener algunas abreviaturas específicas preprogramadas (por ejemplo, MDpara MKDIRen COMMAND.COM) o definidas por el usuario a través de scripts por lotes y alias (por ejemplo, alias md mkdiren tcsh ).
En DOS, OS/2 y Windows, los distintos programas llamados desde su COMMAND.COM o CMD.EXE (o desde sus comandos internos) pueden utilizar una sintaxis diferente dentro del mismo sistema operativo. Por ejemplo:
/, -, o bien, cualquiera de ellos puede estar permitido. Véase a continuación.:o =; por lo tanto Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename.-fApuede significar lo mismo que -f -A, [17] o puede ser incorrecto, o incluso puede ser un parámetro válido pero diferente.En DOS , OS/2 y Windows , la barra diagonal ( /) es la más frecuente, aunque a veces también se utiliza el guión-menos. En muchas versiones de DOS (MS-DOS/PC DOS 2.xx y superiores, todas las versiones de DR-DOS desde 5.0, así como PTS-DOS , Embedded DOS , FreeDOS y RxDOS ), el carácter de cambio (a veces abreviado switchar o switchchar ) que se utilizará se define mediante un valor devuelto de una llamada del sistema ( INT 21h /AX=3700h). El carácter predeterminado devuelto por esta API es /, pero se puede cambiar a un guión-menos en los sistemas mencionados anteriormente, excepto en Datalight ROM-DOS y MS-DOS/PC DOS 5.0 y superiores, que siempre devuelven /de esta llamada (a menos que se cargue uno de los muchos TSR disponibles para volver a habilitar la función SwitChar). En algunos de estos sistemas (MS-DOS/PC DOS 2.xx, DOS Plus 2.1, DR-DOS 7.02 y superiores, PTS-DOS, Embedded DOS, FreeDOS y RxDOS), la configuración también se puede preconfigurar mediante una directiva SWITCHAR en CONFIG.SYS . El Embedded DOS de General Software proporciona un comando SWITCH para el mismo propósito, mientras que 4DOS permite cambiar la configuración mediante SETDOS /W:n. [23] Bajo DR-DOS, si la configuración se ha cambiado de /, el primer separador de directorio \en la pantalla del parámetro PROMPT$G cambiará a una barra diagonal /(que también es un separador de directorio válido en DOS, FlexOS, 4680 OS, 4690 OS, OS/2 y Windows) sirviendo así como una pista visual para indicar el cambio. [17] Además, la configuración actual también se refleja en las pantallas de ayuda integradas. [17] Algunas versiones de DR-DOS COMMAND.COM también admiten un token PROMPT $/para mostrar la configuración actual. COMMAND.COM desde DR-DOS 7.02 también proporciona una variable de entorno pseudo denominada %/%para permitir la escritura de trabajos por lotes portátiles. [24] [25] Varios comandos externos de DR-DOS también admiten una variable de entorno %SWITCHAR% para anular la configuración del sistema.
Sin embargo, muchos programas están programados para utilizar /únicamente el carácter de cambio, en lugar de recuperarlo antes de analizar los argumentos de la línea de comandos. Un número muy pequeño, principalmente los puertos de sistemas tipo Unix, están programados para aceptar "-" incluso si el carácter de cambio no está configurado en él (por ejemplo, netstatand ping, que se proporciona con Microsoft Windows , aceptará la opción /? para enumerar las opciones disponibles y, sin embargo, la lista especificará la convención "-").
En sistemas tipo Unix , las opciones comienzan con un guión-menos ASCII ; la nueva convención (y GNU ) es usar dos guiones y luego una palabra (por ejemplo, --create) para identificar el uso de la opción, mientras que la convención anterior (y aún disponible como opción para opciones de uso frecuente) es usar un guión y luego una letra (por ejemplo, -c); si un guión es seguido por dos o más letras, puede significar que se están especificando dos opciones, o puede significar que la segunda letra y las subsiguientes son un parámetro (como el nombre del archivo o la fecha) para la primera opción. [26]
Dos caracteres con guión negativo sin letras siguientes ( --) pueden indicar que los argumentos restantes no deben tratarse como opciones, lo que resulta útil, por ejemplo, si el nombre de un archivo comienza con un guión o si los argumentos adicionales están destinados a un comando interno (por ejemplo, sudo ). Los guiones negativos dobles también se utilizan a veces para anteponer opciones largas donde se utilizan nombres de opciones más descriptivos. Esta es una característica común del software GNU . La función y el programa getopt y el comando getopts se utilizan habitualmente para analizar opciones de la línea de comandos.
Los nombres de comandos, argumentos y opciones de Unix distinguen entre mayúsculas y minúsculas (excepto en unos pocos ejemplos, principalmente cuando comandos populares de otros sistemas operativos se han portado a Unix).
Uso de FlexOS , 4680 OS y 4690 OS- .
CP/M normalmente utilizado [.
El sistema de monitorización conversacional (CMS) utiliza un único paréntesis izquierdo para separar las opciones al final del comando de los demás argumentos. Por ejemplo, en el siguiente comando, las opciones indican que se debe reemplazar el archivo de destino si existe y que se deben conservar la fecha y la hora del archivo de origen en la copia:COPY source file a target file b (REPLACE OLDDATE)
La CLI de Data General bajo sus sistemas operativos RDOS , AOS , etc., así como la versión de CLI que viene con su Business Basic , utiliza solo /como carácter de cambio, no distingue entre mayúsculas y minúsculas, y permite cambios locales en algunos argumentos para controlar la forma en que se interpretan, como MAC/U LIB/S A B C $LPT/Ltiene la opción global Upara el comando de ensamblador de macros para agregar símbolos de usuario, pero dos cambios locales, uno para especificar que LIB debe omitirse en el paso 2 y el otro para dirigir la lista a la impresora, $LPT.
Una de las críticas a una CLI es la falta de indicaciones para el usuario sobre las acciones disponibles. [ cita requerida ] Por el contrario, las GUI generalmente informan al usuario sobre las acciones disponibles con menús, íconos u otras indicaciones visuales. [ cita requerida ] Para superar esta limitación, muchos programas CLI muestran un mensaje de uso , generalmente cuando se invoca sin argumentos o con uno de los siguientes: ?, -?, -h, -H, /?, /h, /H, /Help, -help, o --help. [17] [27] [28]
Sin embargo, ingresar un nombre de programa sin parámetros con la esperanza de que muestre ayuda de uso puede ser peligroso, ya que los programas y scripts para los cuales los argumentos de la línea de comandos son opcionales se ejecutarán sin previo aviso.
Aunque es deseable al menos para el parámetro de ayuda, los programas pueden no soportar todos los caracteres de introducción de opciones ejemplificados anteriormente. En DOS, donde el carácter de opción de línea de comandos predeterminado puede cambiarse de /a -, los programas pueden consultar la API SwitChar para determinar la configuración actual. Por lo tanto, si un programa no está programado para soportarlos todos, un usuario puede necesitar saber la configuración actual incluso para poder solicitar ayuda de manera confiable. Si el SwitChar ha sido cambiado a -y, por lo tanto, el /carácter es aceptado como delimitador de ruta alternativo también en la línea de comandos DOS, los programas pueden malinterpretar opciones como /ho /Hcomo rutas en lugar de parámetros de ayuda. [17] Sin embargo, si se proporciona como primer o único parámetro, la mayoría de los programas DOS, por convención, lo aceptarán como solicitud de ayuda independientemente de la configuración actual de SwitChar. [17] [23]
En algunos casos, se pueden seleccionar distintos niveles de ayuda para un programa. Algunos programas que lo admiten permiten dar un nivel de verbosidad como argumento opcional al parámetro de ayuda (como en /H:1, /H:2, etc.) o dan solo una ayuda breve sobre los parámetros de ayuda con un signo de interrogación y una pantalla de ayuda más larga para las otras opciones de ayuda. [29]
Dependiendo del programa, a veces se encuentra disponible ayuda adicional o más específica sobre los parámetros aceptados, ya sea proporcionando el parámetro en cuestión como un argumento para el parámetro de ayuda o viceversa (como en /H:Wo en /W:?(asumiendo /Wque sería otro parámetro compatible con el programa)). [30] [31] [28] [27] [29] [nb 1]
De manera similar al parámetro de ayuda, pero mucho menos común, algunos programas proporcionan información adicional sobre sí mismos (como modo, estado, versión, autor, licencia o información de contacto) cuando se invocan con un parámetro about como -!, /!, -about, o --about. [27]
Dado que los caracteres ?y !normalmente también cumplen otras funciones en la línea de comandos, es posible que no estén disponibles en todos los escenarios; por lo tanto, no deberían ser las únicas opciones para acceder a la información de ayuda correspondiente.
Si se necesita ayuda más detallada que la proporcionada por la ayuda interna incorporada de un programa, muchos sistemas admiten un comando externo dedicado (o similar), que acepta un nombre de comando como parámetro de llamada e invocará un sistema de ayuda externo.help command
En la familia DR-DOS, al escribir /?o /Hen el indicador de COMMAND.COM en lugar de un comando en sí, se mostrará una lista generada dinámicamente de comandos internos disponibles; [17] 4DOS y NDOS admiten la misma característica al escribir ?en el indicador [23] (que también es aceptado por las versiones más nuevas de DR-DOS COMMAND.COM); los comandos internos se pueden deshabilitar o volver a habilitar individualmente mediante SETDOS /I. [23] Además de esto, algunas versiones más nuevas de DR-DOS COMMAND.COM también aceptan un comando para mostrar una lista de variables de pseudoentorno?% integradas disponibles . Además de su propósito como referencia de ayuda rápida, esto se puede usar en trabajos por lotes para consultar las funciones del procesador de línea de comandos subyacente. [17]
La ayuda de uso incorporada y las páginas del manual suelen emplear una sintaxis pequeña para describir la forma válida del comando: [32] [33] [34] [nb 2]
ping <hostname>mkdir [-p] <dirname>cp <source1> [source2…] <dest>netstat {-t|-u}Tenga en cuenta que estos caracteres tienen significados diferentes a los que se utilizan directamente en el shell. Los corchetes angulares se pueden omitir cuando no es probable que se confunda el nombre del parámetro con una cadena literal.
En muchas áreas de la informática, pero particularmente en la línea de comandos, el carácter de espacio puede causar problemas ya que tiene dos funciones distintas e incompatibles: como parte de un comando o parámetro, o como parámetro o separador de nombre . La ambigüedad se puede evitar ya sea prohibiendo los espacios incrustados en los nombres de archivos y directorios en primer lugar (por ejemplo, sustituyéndolos por guiones bajos _ ), o encerrando un nombre con espacios incrustados entre caracteres de comillas o utilizando un carácter de escape antes del espacio, generalmente una barra invertida ( \). Por ejemplo
Long path/Long program name Parameter one Parameter two…es ambiguo (¿ el nombre del programa es parte del nombre del programa o son dos parámetros?); sin embargo
Long_path/Long_program_name Parameter_one Parameter_two…,LongPath/LongProgramName ParameterOne ParameterTwo…,"Long path/Long program name" "Parameter one" "Parameter two"…y
Long\ path/Long\ program\ name Parameter\ one Parameter\ two…No son ambiguos. Los sistemas operativos basados en Unix minimizan el uso de espacios incrustados para minimizar la necesidad de comillas. En Microsoft Windows , a menudo hay que usar comillas porque los espacios incrustados (como en los nombres de directorios) son comunes.
Aunque la mayoría de los usuarios piensan en el shell como un intérprete de comandos interactivo, en realidad es un lenguaje de programación en el que cada instrucción ejecuta un comando. Como debe satisfacer tanto los aspectos interactivos como los de programación de la ejecución de comandos, es un lenguaje extraño, moldeado tanto por la historia como por el diseño.
- Brian W. Kernighan y Rob Pike [35]
El término intérprete de línea de comandos ( CLI ) se aplica a programas informáticos diseñados para interpretar una secuencia de líneas de texto que puede introducir un usuario, leer de un archivo u otro tipo de flujo de datos . El contexto de la interpretación suele ser el de un sistema operativo o lenguaje de programación determinado .
Los intérpretes de línea de comandos permiten a los usuarios emitir diversos comandos de una manera muy eficiente (y a menudo concisa). Para ello, es necesario que el usuario conozca los nombres de los comandos y sus parámetros, así como la sintaxis del lenguaje que se interpreta.
El mecanismo Unix #!y el comando EXTPROC de OS/2 facilitan el paso de archivos por lotes a procesadores externos. Se pueden utilizar estos mecanismos para escribir procesadores de comandos específicos para usos dedicados y procesar archivos de datos externos que residen en archivos por lotes.
Muchas interfaces gráficas, como el OS/2 Presentation Manager y las primeras versiones de Microsoft Windows, utilizan líneas de comandos para llamar a programas auxiliares que abran documentos y programas. Los comandos se almacenan en el shell gráfico [ aclaración necesaria ] o en archivos como el registro o el archivo OS/2 OS2USER.INI .
Las primeras computadoras no admitían dispositivos de entrada/salida interactivos, y a menudo dependían de interruptores de detección y luces para comunicarse con el operador de la computadora . Esto era adecuado para sistemas por lotes que ejecutaban un programa a la vez, a menudo con el programador actuando como operador. Esto también tenía la ventaja de una baja sobrecarga, ya que las luces y los interruptores se podían probar y configurar con una instrucción de máquina. Más tarde, se agregó una consola de sistema única para permitir que el operador se comunicara con el sistema.
A partir de la década de 1960, la interacción del usuario con las computadoras se realizó principalmente por medio de interfaces de línea de comandos, inicialmente en máquinas como el Teletype Model 33 ASR, pero luego en las primeras terminales de computadora basadas en CRT como el VT52 .
Todos estos dispositivos se basaban puramente en texto, sin capacidad de mostrar gráficos o imágenes. [nb 3] Para los programas de aplicaciones comerciales , se utilizaban menús basados en texto , pero para una interacción más general, la línea de comandos era la interfaz.
Alrededor de 1964, Louis Pouzin introdujo el concepto y el nombre shell en Multics , basándose en funciones anteriores y más simples del Sistema de tiempo compartido compatible (CTSS). [36] [ se necesita una mejor fuente ]
A principios de los años 70, el sistema operativo Unix adaptó el concepto de un potente entorno de línea de comandos e introdujo la capacidad de canalizar la salida de un comando como entrada a otro. Unix también tenía la capacidad de guardar y volver a ejecutar cadenas de comandos como scripts de shell que actuaban como comandos personalizados.
La línea de comandos también fue la interfaz principal de los primeros ordenadores domésticos, como el Commodore PET , el Apple II y el BBC Micro , casi siempre en forma de intérprete BASIC . Cuando llegaron microordenadores más potentes orientados a los negocios, como el CP/M y, posteriormente, los ordenadores DOS , como el IBM PC , la línea de comandos empezó a adoptar parte de la sintaxis y las características de los shells de Unix, como la distribución de salida en forma de globbing y canalización .
La línea de comandos fue cuestionada seriamente por primera vez por el enfoque GUI PARC utilizado en el Apple Lisa de 1983 y el Apple Macintosh de 1984. Unos pocos usuarios de computadoras usaron GUI como GEOS y Windows 3.1 , pero la mayoría de los usuarios de IBM PC no reemplazaron su shell COMMAND.COM con una GUI hasta que se lanzó Windows 95 en 1995. [37] [38]
Si bien la mayoría de los usuarios de computadoras no expertos ahora utilizan una GUI casi exclusivamente, los usuarios más avanzados tienen acceso a potentes entornos de línea de comandos:
La mayoría de los intérpretes de línea de comandos admiten la ejecución de scripts en diversos grados (después de todo, son intérpretes de un lenguaje de programación interpretado , aunque en muchos casos el lenguaje es exclusivo del intérprete de línea de comandos en particular). Interpretarán scripts (denominados de diversas formas scripts de shell o archivos por lotes ) escritos en el lenguaje que interpretan. Algunos intérpretes de línea de comandos también incorporan los motores de interpretación de otros lenguajes, como REXX , además del suyo propio, lo que permite la ejecución de scripts, en esos lenguajes, directamente dentro del propio intérprete de línea de comandos.
Por el contrario, los lenguajes de programación de scripts , en particular aquellos con una función eval (como REXX, Perl , Python , Ruby o Jython ), se pueden utilizar para implementar intérpretes y filtros de línea de comandos. Para algunos sistemas operativos , en particular DOS , un intérprete de comandos de este tipo proporciona una interfaz de línea de comandos más flexible que la suministrada. En otros casos, un intérprete de comandos de este tipo puede presentar una interfaz de usuario altamente personalizada que emplee la interfaz de usuario y las facilidades de entrada/salida del lenguaje.
La línea de comandos proporciona una interfaz entre los programas y el usuario. En este sentido, una línea de comandos es una alternativa a un cuadro de diálogo . Los editores y las bases de datos presentan una línea de comandos, en la que se pueden ejecutar procesadores de comandos alternativos. Por otro lado, se pueden tener opciones en la línea de comandos, que abren un cuadro de diálogo. La última versión de 'Take Command' tiene esta característica. DBase usaba un cuadro de diálogo para construir líneas de comandos, que se podían editar más antes de su uso.
Programas como BASIC, diskpart , Edlin y QBASIC ofrecen interfaces de línea de comandos, algunas de las cuales utilizan el shell del sistema. Basic está basado en la interfaz predeterminada para computadoras Intel de 8 bits. Las calculadoras se pueden ejecutar como interfaces de línea de comandos o de diálogo.
Emacs ofrece una interfaz de línea de comandos en forma de minibúfer. Se pueden introducir comandos y argumentos mediante el soporte de edición de texto estándar de Emacs y la salida se muestra en otro búfer.
Hay varios juegos en modo texto, como Adventure o King's Quest 1-3 , que dependían de que el usuario escribiera comandos en la parte inferior de la pantalla. Uno controla al personaje escribiendo comandos como 'obtener anillo' o 'mirar'. El programa devuelve un texto que describe cómo lo ve el personaje o hace que suceda la acción. La aventura de texto The Hitchhiker's Guide to the Galaxy , una pieza de ficción interactiva basada en el libro de Douglas Adams del mismo nombre, es un juego de línea de comandos de estilo teletipo.
La más notable de estas interfaces es la interfaz de flujos estándar , que permite que la salida de un comando se pase a la entrada de otro. Los archivos de texto también pueden cumplir cualquiera de estos dos propósitos. Esto proporciona las interfaces de canalización, filtros y redirección. En Unix, los dispositivos también son archivos , por lo que el tipo normal de archivo para el shell utilizado para stdin, stdout y stderr es un archivo de dispositivo tty .
Otra interfaz de línea de comandos permite que un programa de shell ejecute programas auxiliares, ya sea para ejecutar documentos o iniciar un programa. El comando es procesado internamente por el shell y luego se transmite a otro programa para ejecutar el documento. La interfaz gráfica de Windows y OS/2 se basa en gran medida en líneas de comandos que se transmiten a otros programas (de consola o gráficos), que luego suelen procesar la línea de comandos sin presentar una consola de usuario.
Programas como el editor OS/2 E y algunos otros editores de IBM pueden procesar líneas de comandos normalmente destinadas al shell, colocando la salida directamente en la ventana del documento.
El campo de entrada de URL de un navegador web se puede utilizar como una línea de comandos. Se puede utilizar para iniciar aplicaciones web , acceder a la configuración del navegador y realizar una búsqueda. Google , que se ha denominado "la línea de comandos de Internet", realizará una búsqueda específica de dominio cuando detecte parámetros de búsqueda en un formato conocido. [48] Esta funcionalidad está presente tanto si la búsqueda se activa desde un campo del navegador como en el sitio web de Google.
Existen bibliotecas de JavaScript que permiten escribir aplicaciones de línea de comandos en el navegador como aplicaciones web independientes o como parte de una aplicación más grande. [49] Un ejemplo de dicho sitio web es la interfaz CLI de DuckDuckGo . [50] También existen aplicaciones SSH basadas en la web que permiten dar acceso a la interfaz de línea de comandos del servidor desde un navegador.
Muchos videojuegos para PC cuentan con una interfaz de línea de comandos, a la que se suele denominar consola. Los desarrolladores de juegos suelen utilizarla durante el desarrollo y los desarrolladores de mods para depurar errores, así como para hacer trampas o saltear partes del juego.
????nn??DDLa idea de tener un "shell de comandos" reemplazable en lugar de un "monitor" estrechamente integrado con el núcleo del sistema operativo tiende a atribuirse a Multics.
, llamados PS1, P52, P53 y PS4. PS significa Prompt String (cadena de indicadores).
[…] CPI /H […] CPI [@] [@] [/?|/Help[:topic]] [/!|/About] […] [?|&] […] /?, /Help Muestra esta pantalla de ayuda o ayuda específica para un tema (+) […] /!, /About Muestra la pantalla de información 'Acerca de' […] /Cpifile (+) .CPI/.CP nombre de archivo <EGA.CPI>; extensión: <.CPI>; CPI.EXE=StdIn […] /Report Nombre de archivo de informe <'
'=StdOut>; extensión: <.RPT> […] /Style (+) Export <0>-6=BIN-raw/ROM/RAM/PSF0/1/SH/CHED; 7-12/13-18/19-24=ASM-hex/dec/bin/ip/il/p/l/mp/ml […] CPI /H:C […] Descripción general del uso de parámetros del archivo de página de códigos: […] CPI /H:S […] Descripción general de los parámetros /Style: […] ?, & Modo de edición en línea (solicita la entrada de parámetros adicionales) […]
[…] Dado que el
DEBUG de
DR-DOS 7.03
todavía se basa en el antiguo SID86.EXE, sugiero ejecutar DEBUG 1.51 e ingresar al sistema de ayuda extendido con ?? desde el indicador de depuración. Esto le proporcionará ocho pantallas llenas de ayuda sobre sintaxis y funciones. Algunas de estas funciones también eran compatibles con versiones anteriores. […]
?y una ayuda completa sobre ??.)La interfaz de línea de comandos (CLI) de Cisco IOS es la interfaz de usuario principal…