Una interfaz de línea de comandos ( CLI ) es un medio para interactuar con un programa de computadora ingresando líneas de texto llamadas líneas de comando . Las interfaces de línea de comandos surgieron a mediados de la década de 1960, en terminales de computadora , como una alternativa interactiva y más fácil de usar a la interfaz no interactiva disponible con tarjetas perforadas .
Hoy en día, 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 destinados a utilizarse a través de CLI.
El conocimiento de las CLI también es útil para escribir guiones . Los programas que tienen CLI generalmente son fáciles de automatizar mediante secuencias de comandos, 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 intérpretes o procesadores de línea de comandos , que son programas que leen las líneas de comandos y ejecutan los comandos.
Las alternativas a las CLI incluyen GUI (sobre todo 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 implementarse. Dado que las opciones de los comandos se proporcionan en unos pocos caracteres en cada línea de comando, un usuario experimentado a menudo encuentra que es más fácil acceder a las opciones. 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 secuencias de comandos que pueda aceptar parámetros y opciones variables. Se puede mantener un historial de línea de comandos, lo que permite revisar o repetir comandos.
Un sistema de línea de comandos puede requerir manuales en papel 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. Es posible que el entorno de línea de comandos no proporcione mejoras gráficas, como diferentes fuentes o ventanas de edición extendidas que se encuentran en una GUI. Puede resultar difícil para un nuevo usuario familiarizarse con todos los comandos y opciones disponibles, en comparación con los iconos y menús desplegables de una interfaz gráfica de usuario, sin consultar los manuales.
Las interfaces de línea de comandos del sistema operativo (SO) suelen ser programas distintos que se suministran con el sistema operativo. Un programa que implementa dicha interfaz de texto a menudo se denomina intérprete de línea de comandos, procesador de comandos o shell .
Ejemplos de intérpretes de línea de comandos incluyen el lenguaje de comandos DIGITAL (DCL) de DEC en OpenVMS y RSX-11 , los distintos shells de Unix ( sh , ksh , csh , tcsh , zsh , Bash , etc.), CCP de CP/M , DOS ' COMMAND.COM , así como los programas OS/2 y Windows CMD.EXE , 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 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, estrictamente hablando, un 'shell' puede ser cualquier programa que constituya la interfaz de usuario, incluidos los totalmente orientados gráficamente. Por ejemplo, la GUI predeterminada de Windows es un programa shell llamado EXPLORER.EXE , tal como se define en la línea SHELL=EXPLORER.EXE en el 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, que presenta su propio mensaje al usuario y acepta líneas de comando. Otros programas admiten tanto una CLI como una GUI. En algunos casos, una GUI es simplemente un contenedor de un archivo ejecutable CLI independiente . En otros casos, un programa puede proporcionar una CLI como alternativa opcional a su GUI. Las CLI y GUI a menudo admiten diferentes funciones. Por ejemplo, todas las funciones 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 funciones.
En Colossal Cave Adventure de 1975, el usuario utiliza 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). A veces se trataba de enviar un pedido o una confirmación mediante télex . Los primeros sistemas informáticos solían utilizar el teleimpresor como medio de interacción con un operador.
El teleimpresor mecánico fue sustituido por un "glass tty" , un teclado y una pantalla que emulaban al teleimpresor. Los terminales "inteligentes" permitían funciones adicionales, como el movimiento del cursor sobre toda la pantalla o la edición local de datos en el terminal para su transmisión a la computadora. A medida que la revolución de las microcomputadoras reemplazó la arquitectura tradicional de tiempo compartido (minicomputadora + terminales) , las terminales de hardware fueron reemplazadas por emuladores de terminales : software de PC que interpretaba las señales de terminal enviadas a través de los puertos serie de la PC . Por lo general, se usaban para interconectar las nuevas PC de una organización con sus computadoras mini o mainframe existentes, o para conectar una PC a otra. Algunas de estas PC ejecutaban el software Bulletin Board System .
Las primeras CLI de los sistemas operativos se implementaron como parte de los programas de monitores residentes y no podían reemplazarse fácilmente. La primera implementación del shell como 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 y al mismo tiempo permitir 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 proyectil Multics . [2]
El primer shell Unix , el shell V6 , fue desarrollado por Ken Thompson en 1971 en Bell Labs y fue modelado a partir del shell Multics de Schroeder. [4] [5] El shell Bourne se introdujo en 1977 como reemplazo del shell V6. Aunque se utiliza como intérprete de comandos interactivo, también fue pensado como un lenguaje de secuencias de comandos y contiene la mayoría de las características que comúnmente se consideran para producir programas estructurados. El shell Bourne condujo al desarrollo de KornShell (ksh), Almquist shell (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 las décadas de 1980 y 1990, la introducción de Apple Macintosh y Microsoft Windows en las PC vio la interfaz de línea de comandos como la interfaz de usuario principal reemplazada por la interfaz gráfica de usuario . La línea de comando permaneció disponible como una interfaz de usuario alternativa, utilizada a menudo por administradores de sistemas y otros usuarios avanzados para la administración del sistema, programación de computadoras y 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 características de los shells tradicionales de Unix con su propietario .NET Framework orientado a objetos . MinGW y Cygwin son paquetes de código abierto para Windows que ofrecen una CLI similar a Unix. Microsoft proporciona la implementación ksh de MKS Korn shell de MKS Inc. para Windows a través de su complemento Servicios para UNIX .
Desde 2001, el sistema operativo Macintosh macOS se basa en un sistema operativo similar a Unix llamado Darwin . 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; También se proporcionan Bash, tcsh y KornShell . Antes de macOS Catalina , Bash era el valor predeterminado.
Una CLI se utiliza siempre que se puede ingresar un gran vocabulario de comandos o consultas, junto con una amplia (o arbitraria) gama de opciones, 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 las utilizan sistemas con recursos insuficientes para admitir una interfaz gráfica de usuario. Algunos sistemas de lenguajes informáticos (como Python , Forth , LISP , Rexx y muchos dialectos de BASIC ) proporcionan un modo de línea de comandos interactivo para permitir una evaluación rápida del código.
Los programadores y administradores de sistemas suelen utilizar las CLI, en entornos científicos y de ingeniería, y por usuarios de computadoras personales técnicamente avanzados. Los CLI también son populares entre las personas con discapacidad visual, 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 comando [6] [7] es:
Comando rápido param1 param2 param3… paramN
En este formato, los delimitadores entre elementos de la línea de comandos son caracteres de espacio en blanco y el delimitador de final de línea es el delimitador de nueva línea . Esta es una convención ampliamente utilizada (pero no universal).
Generalmente 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 todos los comandos deben seguir. En el caso de los sistemas integrados , cada proveedor, como Nortel , Juniper Networks o Cisco Systems , define su propio conjunto de reglas. 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, sobre 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 coincidir en sintaxis o semántica, pero solo cuando coinciden en ambas pueden considerarse lo suficientemente similares como para permitir a los usuarios utilizar 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" escrita por el usuario terminada con la tecla Intro , 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 redireccionarán su salida.
A diferencia de un botón o elemento de menú en una GUI, una línea de comando suele autodocumentarse y establece exactamente lo que el usuario quiere que se haga. Además, las líneas de comando suelen incluir muchos valores predeterminados que se pueden cambiar para personalizar los resultados. Se pueden guardar líneas de comando útiles asignando una cadena de caracteres o 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. , denominado procedimiento de comando o script que a su vez puede tratarse como un comando. Estas ventajas significan que un usuario debe descifrar un comando complejo o una serie de comandos solo una vez, porque pueden guardarse y usarse nuevamente.
Los comandos proporcionados a un shell CLI suelen tener una de las siguientes formas:
donde doSomething es, en efecto, un verbo , how un adverbio (por ejemplo, el comando debe ejecutarse "de manera detallada" o "silenciosamente") y toFiles un objeto u objetos (normalmente uno o más archivos) sobre los cuales 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 canalización donde la salida de un comando se convierte en la entrada del siguiente comando.
Se puede modificar el conjunto de comandos disponibles modificando qué rutas aparecen en la variable de entorno PATH . En Unix, los comandos también deben marcarse como archivos ejecutables . Los directorios en la variable de ruta se buscan en el orden en que aparecen. Al reordenar la ruta, se puede ejecutar, por ejemplo, \OS2\MDOS\E.EXE en lugar de \OS2\E.EXE, cuando el valor predeterminado es lo contrario. Cambiar el nombre de los ejecutables también funciona: la gente suele cambiar el nombre de su editor favorito a EDITAR, por ejemplo.
La línea de comando permite restringir los comandos disponibles, como el acceso a comandos internos avanzados. El CMD.EXE de Windows hace esto. A menudo, los programas shareware limitarán la gama de comandos, incluida la impresión de un comando "su administrador ha deshabilitado la ejecución de archivos por lotes" desde el mensaje. [ se necesita aclaración ]
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 de interfaz. En este punto, es posible que no se pueda acceder a los comandos del modo de sistema hasta que el usuario salga del modo de interfaz y entre en el modo de sistema.
Un símbolo del sistema (o simplemente un símbolo del sistema ) es una secuencia de (uno o más) caracteres utilizados en una interfaz de línea de comandos para indicar que está listo para aceptar comandos. Literalmente solicita al usuario que actúe. Un mensaje generalmente termina con uno de los caracteres $, %, #, [8] [9] : o [10]> y , a menudo, incluye otra información, como la ruta del directorio de trabajo actual y el nombre del host .-
En muchos sistemas Unix y derivados , el mensaje comúnmente 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 a menudo pueden modificar las indicaciones. Dependiendo del entorno, pueden incluir colores, caracteres especiales y otros elementos (como variables y funciones para la hora actual, usuario, número de shell o directorio de trabajo) para, por ejemplo, hacer que el mensaje sea más informativo o visualmente 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 para hacer que el intérprete de línea de comandos llame a programas externos mientras se muestra el mensaje.
En COMMAND.COM de DOS y en cmd.exe de Windows NT , los usuarios pueden modificar el mensaje emitiendo un PROMPTcomando o cambiando directamente el valor de la %PROMPT% variable de entorno correspondiente . El C:\>estilo predeterminado de la mayoría de los sistemas modernos se obtiene, por ejemplo, con PROMPT $P$G. El valor predeterminado de los sistemas DOS más antiguos C>se obtiene con solo PROMPT, aunque en algunos sistemas esto produce el C:\>estilo más nuevo, a menos que se use en unidades de disquete A: o B:; en esos sistemas PROMPT $N$Gse puede utilizar para anular el valor predeterminado automático y cambiar explícitamente al estilo anterior.
Muchos sistemas Unix cuentan con la $PS1variable (Cadena de mensaje 1), [11] aunque otras variables también pueden afectar el mensaje (dependiendo del shell utilizado). En el shell Bash, un mensaje del formulario:
[ hora ] usuario@host: work_dir $podría configurarse emitiendo el comando
exportar PS1 = '[\t] \u@\H: \W $' En zsh, la $RPROMPTvariable controla un "mensaje" opcional en el lado derecho de la pantalla. No es un aviso real en el sentido de que la ubicación de 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 (OS) a menudo se denominan "comandos en estrella". [12] También se puede acceder a los mismos comandos desde otras líneas de comando (como la línea de comando BBC BASIC ), precediendo el comando con un *.
Un argumento o parámetro de línea de comandos es un elemento de información que se proporciona a un programa cuando se inicia. 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 línea de comandos es:
archivo rm.s"file.s" es un argumento de línea de comando que le dice al programa rm que elimine el archivo "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 manejándolos como parámetros de cadena en la función principal . Otros lenguajes, como Python , exponen la API (funcionalidad) específica del sistema operativo a través sys del módulo y, en particular, sys.argvpara los "argumentos de línea de comandos".
En los sistemas operativos tipo Unix , un guión único utilizado en lugar de un nombre de archivo es un valor especial que especifica que un programa debe manejar datos provenientes de la entrada estándar o enviar datos a la salida estándar .
Una opción de línea de comando o simplemente opción (también conocida como indicador o interruptor ) modifica la operación de un comando; el efecto está determinado por el programa del comando. Las opciones siguen al nombre del comando en la línea de comando, 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 [10] de enumerar las opciones disponibles del comando DIR, mientras que dir --help(en muchas versiones de Unix) requiere que la opción esté precedida por al al menos un espacio (y distingue entre mayúsculas y minúsculas).
El formato de las opciones varía ampliamente entre los sistemas operativos. En la mayoría de los casos, la sintaxis es más una convención que un requisito del sistema operativo; toda la línea de comando es simplemente una cadena pasada a un programa, que puede procesarla de cualquier manera que el programador desee, siempre y cuando el intérprete pueda decir 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, todos relacionados con la lista de archivos en un directorio, para ilustrar algunas convenciones:
En Multics , las opciones de la línea de comandos y las palabras clave del subsistema pueden abreviarse. 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 "foro" de Multics, el parámetro -long_subject se puede abreviar -lgsj . También es común que los comandos Multics sean abreviados, generalmente correspondientes a las letras iniciales de las palabras que se unen con guiones bajos para formar nombres de comandos, como el uso de did para eliminar_iacl_dir .
En algunos otros sistemas, las abreviaturas son automáticas, como permitir suficientes primeros caracteres de un nombre de comando para identificarlo de forma única (como SUuna abreviatura de SUPERUSER), mientras que otros pueden tener algunas abreviaturas específicas preprogramadas (por ejemplo, MDen MKDIRCOMMAND.COM). o definido por el usuario mediante scripts por lotes y alias (por ejemplo, alias md mkdiren tcsh ).
En DOS, OS/2 y Windows, diferentes programas llamados desde su COMMAND.COM o CMD.EXE (o sus comandos internos) pueden usar una sintaxis diferente dentro del mismo sistema operativo. Por ejemplo:
/, -, o cualquiera de ellos puede estar permitido. Vea abajo.:o =; de este modo Prog -fFilename, Prog -f Filename, Prog -f:Filename, Prog -f=Filename.-fApuede significar lo mismo que -f -A, [10] 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 por una llamada al 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 regresan /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 un SWITCHAR . directiva en CONFIG.SYS . El DOS integrado de General Software proporciona un comando SWITCH para el mismo propósito, mientras que 4DOS permite cambiar la configuración mediante SETDOS /W:n. [13] En DR-DOS, si se cambió la configuración 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 pista visual para indicar el cambio. [10] Además, la configuración actual se refleja también en las pantallas de ayuda integradas. [10] 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 pseudoentorno denominada %/%para permitir la escritura de trabajos por lotes portátiles. [14] [15] Varios comandos DR-DOS externos admiten además una variable de entorno %SWITCHAR% para anular la configuración del sistema.
Sin embargo, muchos programas están programados para usarse /únicamente, en lugar de recuperar la configuración del interruptor antes de analizar los argumentos de la línea de comandos. Un número muy pequeño, principalmente puertos de sistemas tipo Unix, están programados para aceptar "-" incluso si el carácter de cambio no está configurado (por ejemplo netstaty ping, suministrado con Microsoft Windows , aceptará la opción /? para enumerar las opciones disponibles , y aún así la lista especificará la convención "-").
En sistemas tipo Unix , las opciones de inicio con guión menos ASCII; la nueva convención (y GNU ) es usar dos guiones y luego una palabra (p. ej. --create) para identificar el uso de la opción, mientras que la convención antigua (y todavía disponible como opción para las opciones de uso frecuente) es usar un guión y luego una letra (p. ej. , -c); si un guión va seguido de dos o más letras, puede significar que se están especificando dos opciones, o puede significar que la segunda letra y las siguientes son un parámetro (como el nombre de archivo o la fecha) para la primera opción. [dieciséis]
Dos caracteres de guión menos sin letras siguientes ( --) pueden indicar que los argumentos restantes no deben tratarse como opciones, lo cual es ú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 (p. ej. , sudo ). A veces también se utilizan guiones dobles negativos para anteponer "opciones largas" cuando 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 generalmente para analizar las 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- .
Normalmente se utiliza CP/M[ .
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 el archivo de destino debe reemplazarse si existe, y la fecha y hora del archivo de origen deben conservarse en la copia:COPY source file a target file b (REPLACE OLDDATE)
La CLI de Data General en sus sistemas operativos RDOS , AOS , etc., así como la versión de CLI que viene con Business Basic , se 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 por ejemplo, MAC/U LIB/S A B C $LPT/Ltiene la opción global "U" al comando del macro ensamblador para agregar símbolos de usuario, pero dos modificadores locales, uno para especificar LIB, deben omitirse en el paso 2 y el otro para dirigir el listado 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 necesaria ] Por el contrario, las GUI generalmente informan al usuario de las acciones disponibles con menús, íconos u otras señales visuales. [ cita necesaria ] Para superar esta limitación, muchos programas CLI muestran un mensaje de uso , generalmente cuando se invoca sin argumentos o uno de ?, -?, -h, -H, /?, /h, , o . [10] [17] [18]/H/Help-help--help
Sin embargo, ingresar el nombre de un programa sin parámetros con la esperanza de que muestre ayuda para el uso puede ser peligroso, ya que los programas y scripts cuyos argumentos de línea de comando son opcionales se ejecutarán sin previo aviso.
Aunque es deseable al menos para el parámetro de ayuda, es posible que los programas no admitan todos los caracteres iniciales de opciones ejemplificados anteriormente. En DOS, donde el carácter de opción de línea de comando predeterminado se puede cambiar de /a -, los programas pueden consultar la API SwitChar para determinar la configuración actual. Por lo tanto, si un programa no está diseñado para admitirlos todos, es posible que un usuario necesite conocer la configuración actual incluso para poder solicitar ayuda de manera confiable. Si se cambió SwitChar -y, por lo tanto, el /carácter se acepta como delimitador de ruta alternativo también en la línea de comando de DOS, los programas pueden malinterpretar opciones como /ho /Hcomo rutas en lugar de parámetros de ayuda. [10] Sin embargo, si se proporciona como primer o único parámetro, la mayoría de los programas de DOS, por convención, lo aceptarán como solicitud de ayuda independientemente de la configuración actual de SwitChar. [10] [13]
En algunos casos, se pueden seleccionar diferentes niveles de ayuda para un programa. Algunos programas que admiten esto permiten dar un nivel de detalle como argumento opcional al parámetro de ayuda (como en /H:1, /H:2, etc.) o brindan solo una breve ayuda 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. [19]
Dependiendo del programa, a veces hay disponible ayuda adicional o más específica sobre los parámetros aceptados, ya sea proporcionando el parámetro en cuestión como argumento para el parámetro de ayuda o viceversa (como en /H:Wo en /W:?(suponiendo /Wque sea otro parámetro admitido por el programa)) . [20] [21] [18] [17] [19] [nota 1]
De manera similar al parámetro de ayuda, pero mucho menos común, algunos programas brindan información adicional sobre ellos mismos (como modo, estado, versión, autor, licencia o información de contacto) cuando se invocan con un parámetro "acerca de" como -!, /!, -abouto --about. [17]
Dado que los caracteres ?y !normalmente también sirven para otros propósitos en la línea de comando, 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 COMMAND.COM en lugar de un comando en sí, se mostrará una lista generada dinámicamente de comandos internos disponibles; [10] 4DOS y NDOS admiten la misma función escribiendo ?en el símbolo [13] (que también es aceptada por las versiones más recientes de DR-DOS COMMAND.COM); Los comandos internos se pueden desactivar o reactivar individualmente mediante SETDOS /I. [13] 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, se puede utilizar en trabajos por lotes para consultar las funciones del procesador de línea de comandos subyacente. [10]
Las páginas de manual y ayuda de uso integradas suelen emplear una pequeña sintaxis para describir la forma válida del comando: [22] [23] [24] [nb 2]
ping <hostname>mkdir [-p] <dirname>cp <source1> [source2…] <dest>netstat {-t|-u}Tenga en cuenta que estos caracteres tienen significados diferentes que cuando se usan directamente en el shell. Los corchetes angulares se pueden omitir cuando no sea probable confundir 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 nombres . La ambigüedad se puede evitar prohibiendo en primer lugar los espacios incrustados en los nombres de archivos y directorios (por ejemplo, reemplazándolos con guiones bajos _ ), o encerrando un nombre con espacios incrustados entre comillas o usando 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 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 integrados para minimizar la necesidad de cotizaciones. En Microsoft Windows , a menudo hay que utilizar comillas porque los espacios incrustados (como en los nombres de directorios) son comunes.
Aunque la mayoría de los usuarios piensan que el shell es un intérprete de comandos interactivo, en realidad es un lenguaje de programación en el que cada instrucción ejecuta un comando. Debido a que debe satisfacer tanto los aspectos interactivos como 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 [25]
El término intérprete de línea de comandos ( CLI ) se aplica a programas de computadora diseñados para interpretar una secuencia de líneas de texto que puede ingresar un usuario, leerse de un archivo u otro tipo de flujo de datos . El contexto de 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 varios comandos de una manera muy eficiente (y a menudo concisa). Esto requiere que el usuario conozca los nombres de los comandos y sus parámetros, y 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 OS/2 Presentation Manager y las primeras versiones de Microsoft Windows, utilizan líneas de comandos para llamar a programas auxiliares para abrir documentos y programas. Los comandos se almacenan en el shell gráfico [ se necesita aclaración ] o en archivos como el registro o el archivo OS/2 OS2USER.INI .
Las primeras computadoras no admitían dispositivos interactivos de entrada/salida, y a menudo dependían de interruptores sensoriales 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 reducir los gastos generales, ya que las luces y los interruptores podían probarse y configurarse con una sola instrucción de máquina. Posteriormente se agregó una única consola del sistema para permitir que el operador se comunique con el sistema.
A partir de la década de 1960, la interacción del usuario con las computadoras se realizó principalmente a través de interfaces de línea de comandos, inicialmente en máquinas como el Teletype Model 33 ASR, pero luego en los primeros terminales de computadora basados en CRT , como el VT52 .
Todos estos dispositivos se basaban exclusivamente en texto, sin capacidad para mostrar gráficos o imágenes. [nb 3] Para los programas de aplicaciones empresariales , se utilizaron 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 instalaciones anteriores y más simples del Sistema de tiempo compartido compatible (CTSS). [26] [ se necesita una mejor fuente ]
Desde principios de la década de 1970, 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 para las primeras computadoras domésticas, como Commodore PET , Apple II y BBC Micro , casi siempre en forma de intérprete BÁSICO . Cuando llegaron microcomputadoras más potentes orientadas a los negocios con CP/M y más tarde computadoras DOS , como la IBM PC , la línea de comandos comenzó a tomar prestada parte de la sintaxis y características de los shells de Unix, como globbing y canalización de salida.
La línea de comandos fue seriamente desafiada por primera vez por el enfoque PARC GUI utilizado en el Apple Lisa de 1983 y el Apple Macintosh de 1984 . Algunos usuarios de computadoras utilizaron GUI como GEOS y Windows 3.1 , pero la mayoría de los usuarios de PC IBM no reemplazaron su shell COMMAND.COM con una GUI hasta que se lanzó Windows 95 en 1995. [27] [28]
Mientras que la mayoría de los usuarios de ordenadores no expertos utilizan ahora casi exclusivamente una GUI, 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 secuencias de comandos , 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 interpretar. Algunos intérpretes de línea de comandos también incorporan motores de interpretación de otros lenguajes, como REXX , además del propio, permitiendo la ejecución de scripts, en esos idiomas, 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 de evaluación (como REXX, Perl , Python , Ruby o Jython ), se pueden utilizar para implementar filtros e intérpretes de línea de comandos. Para algunos sistemas operativos , sobre todo DOS , dicho intérprete de comandos proporciona una interfaz de línea de comandos más flexible que la suministrada. En otros casos, dicho intérprete de comandos puede presentar una interfaz de usuario altamente personalizada empleando la interfaz de usuario y las funciones de entrada/salida del idioma.
La línea de comando proporciona una interfaz entre los programas y el usuario. En este sentido, una línea de comando 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, es posible que tenga opciones en la línea de comando, que abre un cuadro de diálogo. La última versión de 'Take Command' tiene esta característica. DBase utilizó un cuadro de diálogo para construir líneas de comando, que podrían editarse más antes de su uso.
Programas como BASIC, diskpart , Edlin y QBASIC proporcionan interfaces de línea de comandos, algunas de las cuales utilizan el shell del sistema. Basic se basa 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 proporciona una interfaz de línea de comandos en forma de minibúfer. Se pueden ingresar comandos y argumentos utilizando 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 cómo hace que suceda la acción. La aventura de texto La guía del autoestopista galáctico , una pieza de ficción interactiva basada en el libro del mismo nombre de Douglas Adam , es un juego de línea de comandos estilo teletipo.
La más notable de estas interfaces es la interfaz de flujos estándar , que permite pasar la salida de un comando a la entrada de otro. Los archivos de texto también pueden servir para ambos propósitos. Esto proporciona las interfaces de tuberías, 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 shell inicie programas auxiliares, ya sea para iniciar documentos o iniciar un programa. El comando es procesado internamente por el shell y luego pasado a otro programa para iniciar el documento. La interfaz gráfica de Windows y OS/2 depende en gran medida de las líneas de comando que se pasan a otros programas (de consola o gráficos), que generalmente procesan la línea de comando 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, y la salida se coloca directamente en la ventana del documento.
El campo de entrada de URL de un navegador web se puede utilizar como línea de comando. Se puede utilizar para "iniciar" aplicaciones web , acceder a la configuración del navegador y realizar una búsqueda. Google , que ha sido llamado "la línea de comando de Internet", realizará una búsqueda de dominio específico cuando detecte parámetros de búsqueda en un formato conocido. [36] Esta funcionalidad está presente ya sea que la búsqueda se active desde un campo del navegador o 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. [37] Un ejemplo de un sitio web de este tipo es la interfaz CLI de DuckDuckGo . [38] También existen aplicaciones SSH basadas en web que permiten dar acceso a la interfaz de línea de comandos del servidor desde un navegador.
Muchos videojuegos de PC cuentan con una interfaz de línea de comandos a la que a menudo se hace referencia como consola. Normalmente lo utilizan los desarrolladores de juegos durante el desarrollo y los desarrolladores de mods con fines de depuración, así como para hacer trampa o saltarse partes del juego.
????nn??DDLa noción de tener un "shell de comando" reemplazable en lugar de un "monitor" estrechamente integrado con el kernel del sistema operativo tiende a atribuirse a Multics.
El shell tiene cuatro símbolos de comando diferentes, llamados PS1, P52, P53 y PS4. PS significa cadena de aviso.
[…] IPC /H […] IPC [@] [@] [/?|/Ayuda[:tema]] [/!|/Acerca de] […] [?|&] […] /?, /Ayuda Mostrar esta pantalla de ayuda o ayuda específica para un tema (+) […] /!, /Acerca de Mostrar la pantalla de información 'Acerca de' […] /Cpifile (+) .CPI/.CP nombre de archivo <EGA.CPI>;
extensión: <.CPI>;
CPI.EXE=StdIn […] /Report Nombre del archivo del informe <'
'=SalidaEstándar>; extensión: <.RPT> […] /Estilo (+) Exportar <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: […] ?, y 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 extendida con ??
desde el mensaje de depuración.
Esto le brindará ocho pantallas llenas de sintaxis y ayuda sobre funciones.
Algunas de estas funciones también eran compatibles con ediciones anteriores.
[…]
?y ayuda completa en ??.)La interfaz de línea de comandos (CLI) de Cisco IOS es la interfaz de usuario principal...