C shell

El intérprete de comandos C ( csh o su versión mejorada, tcsh ) es un intérprete de comandos de Unix creado por Bill Joy mientras era estudiante de posgrado en la Universidad de California, Berkeley, a finales de la década de 1970. Ha tenido una amplia distribución, comenzando con la versión 2BSD de la Berkeley Software Distribution (BSD), que Joy distribuyó por primera vez en 1978. ^{[ 1 ] [ 2 ]} Otros colaboradores iniciales en las ideas o el código fueron Michael Ubell, Eric Allman , Mike O'Brien y Jim Kulp. ^{[ 3 ]}

El intérprete de comandos C es un procesador de comandos que normalmente se ejecuta en una ventana de texto, permitiendo al usuario escribir y ejecutar comandos. También puede leer comandos desde un archivo, llamado script . Al igual que todos los intérpretes de comandos de Unix, admite comodines en los nombres de archivo , tuberías , documentos aquí , sustitución de comandos , variables y estructuras de control para la comprobación de condiciones e iteración . Lo que diferenció al intérprete de comandos C de otros, especialmente en la década de 1980, fueron sus características interactivas y su estilo general. Sus nuevas características lo hicieron más fácil y rápido de usar. El estilo general del lenguaje se parecía más a C y se consideraba más legible.

En muchos sistemas, como macOS y Red Hat Linux , csh es en realidad tcsh , una versión mejorada de csh. A menudo, uno de los dos archivos es un enlace físico o simbólico al otro, de modo que ambos nombres se refieren a la misma versión mejorada del intérprete de comandos C. El código fuente original de csh, en src/bin/csh/, y el binario forman parte de NetBSD y OpenBSD .

En Debian y algunos derivados (incluido Ubuntu ), existen dos paquetes diferentes: csh y tcsh. El primero se basa en la versión original de csh de BSD ^{[ 4 ] [ 5 ]} y el segundo es la versión mejorada de tcsh. ^{[ 6 ] [ 7 ]}

tcsh añadió autocompletado de nombres de archivo y comandos, así como conceptos de edición de línea de comandos tomados del sistema Tenex , que es la fuente de la "t". ^{[ 8 ]} Debido a que solo añadió funcionalidad y no cambió lo que ya existía, tcsh se mantuvo compatible con versiones anteriores ^{[ 9 ]} con el shell C original. Aunque comenzó como una rama secundaria del árbol de código fuente original que Joy había creado, tcsh es ahora la rama principal para el desarrollo continuo. tcsh es muy estable, pero siguen apareciendo nuevas versiones aproximadamente una vez al año, que consisten principalmente en correcciones de errores menores. ^{[ 10 ]}

Los principales objetivos de diseño para el intérprete de comandos C eran que se pareciera más al lenguaje de programación C y que fuera más adecuado para el uso interactivo.

#!/bin/sh if [ $days -gt 365 ] then echo Esto es más de un año. fi

#!/bin/csh if ( $days > 365 ) then echo Esto es más de un año. endif

#!/bin/sh i = 2 j = 1 while [ $j -le 10 ] do echo '2 **' $j = $i i = ` expr $i '*' 2 ` j = ` expr $j + 1 ` done   

#!/bin/csh establecer i = 2 establecer j = 1 mientras ( $j < = 10 ) echo '2 **' $j = $i @ i * = 2 @ j++ fin

#!/bin/sh for i in d* do case $i in d? ) echo $i es corto ;; * ) echo $i es largo ;; esac done

#!/bin/csh foreach i ( d* ) switch ( $i ) case d?: echo $i es corto breaksw  default : echo $i es largo endsw end

El intérprete de comandos C opera línea por línea. Cada línea se divide en un conjunto de palabras separadas por espacios u otros caracteres con significado especial, como paréntesis, operadores de redirección de entrada/salida y tuberías, puntos y comas y signos de ampersand.

set filter = "$home" '/filter' mkfifo "$filter" cat "$filter" & ( ( ls /root/ || echo Sin acceso. ) > "$filter" ) >& /dev/null 

( ( ( echo ok ; '' ) > /dev/fd/0 ) >& /dev/null < /dev/fd/1 ) | ( echo "$<" adiós )

echo "`echo " \"\` "echo " \"\\\"\\\`\" "echo " \"\\\"\\\\\\\"\\\\\\\`\\\"\" "echo " \"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\`\\\\\\\"\\\"\" "eco " \"\\\"\\\\\\\"\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\"\\\\\\\"\\\"\" "pwd" \"\\\"\\\\\\\"\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\"\\\\\\\\\\\\\\\`\\\\\\\\\\\\\\\"\\\\\\\\"\\\\\\\`\\\\\\\"\\\"\\\"\\\`\\\"\"\"` \"

si ( expresión ) comando 

si ( expresión1 ) entonces comandos sino si ( expresión2 ) entonces comandos ... si no , comandos fin si

interruptor ( cadena ) caso patrón1: comandos breaksw patrón  de caso2 : comandos descansos ... por defecto : comandos rupturasw terminaw

mientras ( expresión ) comandos fin

para cada variable de bucle ( lista de valores ) comandos fin

repetir comando entero 

# Crea una variable lo suficientemente grande como para contener 1024 elementos. set fixed = { , }{ , }{ , } { , }{ , }{ , }{ , }{ , } { , }

// C agrupa desde la izquierda int i = 10 / 5 * 2 ; printf ( "%d \n " , i ); // imprime 4 i = 7 - 4 + 2 ; printf ( "%d \n " , i ); // imprime 5 i = 2 >> 1 << 4 ; printf ( "%d \n " , i ); // imprime 16

# Grupos de shell C desde la derecha @ i = 10 / 5 * 2 echo $i # imprime 1 @ i = 7 - 4 + 2 echo $i # imprime 1 @ i = ( 2 >> 1 << 4 ) echo $i # imprime 0

¡ Salida ! ! 256 # Devuelve 1.

Aunque el propio Stephen Bourne reconoció que csh era superior a su shell para uso interactivo, ^{[ 14 ]} nunca ha sido tan popular para la creación de scripts.

En 1983, tanto csh como Bourne shell estaban disponibles para el sistema operativo UNOS de Charles River Data Systems , entre otras herramientas UNIX, bajo licencia de Bell Laboratories . ^{[ 15 ]}

Inicialmente, y durante la década de 1980, no se podía garantizar la presencia de csh en todos los sistemas Unix y similares, pero sí la de sh, lo que lo convertía en una mejor opción para cualquier script que debiera ejecutarse en otras máquinas. A mediados de la década de 1990, csh estaba ampliamente disponible, pero su uso para scripts recibió nuevas críticas por parte del comité POSIX , ^{[ 16 ]} que especificó que solo debería haber un intérprete de comandos preferido, KornShell , tanto para fines interactivos como de scripting. El intérprete de comandos C también recibió críticas de otros ^{[ 17 ] [ 18 ]} por supuestos defectos de sintaxis, características faltantes y mala implementación.

• Defectos de sintaxis: eran inconsistencias generalmente simples pero innecesarias en la definición del lenguaje. Por ejemplo, los comandos set, setenvy aliashacían básicamente lo mismo, es decir, asociar un nombre con una cadena o conjunto de palabras. Pero los tres tenían diferencias leves pero innecesarias. Se requería un signo de igual para setpero no para setenvo alias; se requerían paréntesis alrededor de una lista de palabras para setpero no para setenvo alias, etc. De manera similar, las construcciones de bucle if, switchy usan palabras clave innecesariamente diferentes ( endif, endswy end) para terminar los bloques anidados.
• Funcionalidades faltantes: las más citadas son la falta de capacidad para manipular los descriptores de archivo de stdio de forma independiente y la falta de compatibilidad con funciones. Aunque carece de compatibilidad con funciones, los alias sirven como solución alternativa. Para varias líneas de código, los alias deben estar entre comillas simples, y cada final de línea debe ir precedido de una barra invertida (el final de la última línea debe ir precedido de una comilla simple para delimitar el final del alias). La recursión es preferible a los alias en los scripts como solución alternativa para las funciones (se proporciona un ejemplo a continuación).
• La implementación, que utilizó un analizador ad hoc , ha recibido las críticas más severas. A principios de la década de 1970, la tecnología de compiladores estaba suficientemente madura ^{[ 19 ]} como para que la mayoría de las nuevas implementaciones de lenguajes utilizaran un analizador descendente o ascendente capaz de reconocer una gramática completamente recursiva . Se desconoce por qué se optó por un diseño ad hoc para el intérprete de comandos C. Puede deberse simplemente a que, como Joy expresó en una entrevista en 2009, «Cuando comencé a trabajar en Unix, no era un programador muy bueno». ^{[ 20 ]} El diseño ad hoc implicaba que el lenguaje C no era completamente recursivo. Existía un límite en la complejidad de los comandos que podía manejar.

Funcionaba para la mayoría de los comandos escritos interactivamente, pero para los comandos más complejos que un usuario podría escribir en un script, podía fallar fácilmente, produciendo solo un mensaje de error críptico o un resultado no deseado. Por ejemplo, el intérprete de comandos C no admitía la redirección de salida entre estructuras de control. Intentar redirigir la salida de un foreachcomando grepsimplemente no funcionaba. (La solución alternativa, que funciona para muchas de las quejas relacionadas con el analizador, consiste en dividir el código en scripts separados. Si foreachse mueve a un script separado, la redirección funciona porque los scripts se ejecutan mediante la creación de una nueva copia de csh que hereda los identificadores stdio correctos. También es posible dividir el código en un solo archivo. A continuación se muestra un ejemplo de cómo dividir el código en un solo archivo).

Otro ejemplo es el comportamiento anómalo que se observa en los siguientes fragmentos. Ambos parecen significar: "Si 'myfile' no existe, créalo escribiendo 'mytext' en él". Sin embargo, la versión de la derecha siempre crea un archivo vacío porque el orden de evaluación del intérprete de comandos C consiste en buscar y evaluar los operadores de redirección de E/S en cada línea de comandos a medida que la lee, antes de examinar el resto de la línea para comprobar si contiene una estructura de control.

# Funciona como se esperaba si ( ! -e myfile ) entonces echo mytext > myfile fin si 

# Siempre crea un archivo vacío if ( ! -e myfile ) echo mytext > myfile 

# Solución alternativa (solo para tcsh) if ( ! -e myfile ) eval "echo mytext > myfile"

# Segunda solución alternativa (para csh y tcsh) ( exit ( -e myfile ) && ( ( echo mytext > myfile ) >& /dev/null || echo No se puede crear el archivo. ) || echo El archivo ya existe. 

La implementación también es criticada por sus mensajes de error notoriamente deficientes, por ejemplo, "0: Evento no encontrado", que no proporciona información útil sobre el problema.

Sin embargo, mediante la práctica, es posible superar esas deficiencias (lo que permite al programador adoptar enfoques mejores y más seguros al implementar un script).

El error "0: Evento no encontrado" indica que no hay comandos guardados en el historial. Es posible que el historial no funcione correctamente en los scripts, pero tener un conjunto predefinido de comandos en una variable sirve como solución alternativa.

#!/bin/csh -f set cmdlist = ( 'date # 1' \ 'uname # 2' \ 'tty # 3' \ 'id # 4' ) echo -n 'Introduzca un número para ejecutar un comando del historial: ' set cmdexec = "$<" ( exit ( ! ( "$cmdexec" > 0 && \ "$cmdexec" < = "$#cmdlist" ) ) ) >& /dev/null if ( "$status" ) then echo 'Número de evento no válido.' foreach cmd ( $cmdlist :q ) echo "$cmd" end exit -1 endif eval "$cmdlist[$cmdexec]"

Prefiero romper el código recursivamente en el script como solución alternativa para las funciones.

#!/bin/csh -f if ( ! "$?main" ) then  if ( ! "$?0" ) then echo 'Debes ejecutar este script llamando explícitamente a su archivo.' exit -1 endif alias function 'set argv = ( \!* ) ; source "$main"' set main = "$0" set ret = "`function myfunc`" echo "$ret" exit endifir a "$1" ; cambio mifunción: función myfunc2 echo "Una función." salir mifunc2: echo "Otra función." salir

El intérprete de comandos C tuvo un éxito rotundo al introducir numerosas innovaciones, como el mecanismo de historial , los alias , la notación con tilde , el autocompletado interactivo de nombres de archivo, una gramática de expresiones integrada y otras más, que posteriormente fueron copiadas por otros intérpretes de comandos de Unix. Sin embargo, a diferencia de sh , que ha generado una gran cantidad de clones desarrollados de forma independiente, como ksh y bash , solo se conocen dos clones de csh. (Dado que tcsh se basó en el código de csh escrito originalmente por Bill Joy, no se considera un clon).

En 1986, Allen Holub escribió On Command: Writing a Unix-Like Shell for MS-DOS , ^{[ 21 ]} un libro que describía un programa que había escrito llamado "SH", pero que en realidad copiaba el diseño del lenguaje y las características de csh, no de sh. Los disquetes complementarios que contenían el código fuente completo de SH y de un conjunto básico de utilidades tipo Unix (cat, cp, grep, etc.) estaban disponibles por 25 y 30 dólares, respectivamente, del editor. Las estructuras de control, la gramática de expresiones, el mecanismo de historial y otras características del SH de Holub eran idénticas a las del intérprete de comandos C.

En 1988, Hamilton Laboratories comenzó a distribuir Hamilton C shell para OS/2 . ^{[ 22 ]} Incluía tanto un clon de csh como un conjunto de utilidades tipo Unix. En 1992, Hamilton C shell se lanzó para Windows NT . ^{[ 23 ]} La versión de Windows continúa recibiendo soporte activo, pero la versión de OS/2 se descontinuó en 2003. ^{[ 23 ]} Una referencia rápida de principios de 1990 ^{[ 24 ]} describía la intención como "cumplimiento total con todo el lenguaje C shell (excepto el control de trabajos )", pero con mejoras en el diseño del lenguaje y adaptación a las diferencias entre Unix y una PC. La mejora más importante fue un analizador sintáctico descendente que permitía anidar o canalizar estructuras de control , algo que el C shell original no podía soportar, dado su analizador sintáctico ad hoc. Hamilton también agregó nuevas características de lenguaje, incluyendo procedimientos integrados y definidos por el usuario, variables locales estructuradas en bloques y aritmética de punto flotante. La adaptación a un PC incluyó la compatibilidad con el nombre de archivo y otras convenciones propias de un PC, así como el uso de subprocesos en lugar de bifurcaciones (que no estaban disponibles ni en OS/2 ni en Windows) para lograr el paralelismo , por ejemplo, al configurar una tubería.

En 2026, Tropibyte lanzó C Shell para Windows (cshw), una implementación nativa de csh para Win32 distribuida sin dependencias de Cygwin ni WSL. Al igual que Hamilton C shell, evita el paralelismo basado en fork, utilizando corrutinas y primitivas de sincronización de Windows en su lugar. ^{[ 25 ]}

• Intérprete de línea de comandos
• Comparación de intérpretes de comandos

• Anderson, Gail; Paul Anderson (1986). The UNIX C Shell Field Guide . Prentice-Hall. ISBN 0-13-937468-X.
• Wang, Paul (1988). Introducción a Berkeley UNIX . Wadsworth Pub. Co. ISBN 0-534-08862-7.
• DuBois, Paul (1995). Uso de csh y tcsh . O'Reilly & Associates. ISBN 1-56592-132-1.
• Arick, Martin R. (1993). UNIX C Shell Desk Reference . John Wiley & Sons. ISBN 0-471-55680-7.
• "Introducción a la programación en C Shell" . Departamento de Ciencias de la Computación de Canisius College. Archivado del original el 19 de agosto de 2011. Consultado el 23 de junio de 2010 .

• Introducción al intérprete de comandos C, por William Joy .
• Linux en pocas palabras: Capítulo 8. csh y tcsh .
• Código fuente histórico de csh de 2BSD con fecha del 2 de febrero de 1980.
• El Árbol Unix , distribuciones históricas completas de Unix.
• La programación en Csh se considera dañina .
• Diez razones principales para no usar el intérprete de comandos C.