Guión de shell

Edición de un script de shell FreeBSD para configurar ipfirewall

Un script de shell es un programa de computadora diseñado para ser ejecutado por un shell de Unix, un intérprete de línea de comandos. Los diversos dialectos de los scripts de shell se consideran lenguajes de scripting. Las operaciones típicas realizadas por los scripts de shell incluyen la manipulación de archivos, la ejecución de programas y la impresión de texto. Una secuencia de comandos que configura el entorno, ejecuta el programa y realiza la limpieza o el registro necesarios se denomina contenedor.

El término también se usa de manera más general para referirse al modo automatizado de ejecutar el shell de un sistema operativo; cada sistema operativo usa un nombre particular para estas funciones, incluidos los archivos por lotes (MSDos-Win95 stream, OS/2), procedimientos de comando (VMS) y scripts de shell (Windows NT stream y derivados de terceros como 4NT; el artículo se encuentra en cmd. exe), y los sistemas operativos de mainframe están asociados con una serie de términos.

Los shells comúnmente presentes en Unix y sistemas similares a Unix incluyen el shell Korn, el shell Bourne y GNU Bash. Si bien un sistema operativo Unix puede tener un shell predeterminado diferente, como Zsh en macOS, estos shells suelen estar presentes para la compatibilidad con versiones anteriores.

Capacidades

Comentarios

El shell ignora los comentarios. Por lo general, comienzan con el símbolo hash (#) y continúan hasta el final de la línea.

Elección configurable de lenguaje de secuencias de comandos

El shebang, o hash-bang, es un tipo especial de comentario que el sistema usa para determinar qué intérprete usar para ejecutar el archivo. El shebang debe ser la primera línea del archivo y comenzar con "#!". En los sistemas operativos similares a Unix, los caracteres que siguen a "#!" prefix se interpretan como una ruta a un programa ejecutable que interpretará el script.

Atajos

Una secuencia de comandos de shell puede proporcionar una variación conveniente de un comando del sistema donde la configuración del entorno especial, las opciones de comando o el posprocesamiento se aplican automáticamente, pero de una manera que permite que la nueva secuencia de comandos aún actúe como un comando Unix completamente normal.

Un ejemplo sería crear una versión de ls, el comando para listar archivos, dándole un nombre de comando más corto de l, que normalmente se guardaría en el bin como /home/username/bin/l, y un conjunto predeterminado de opciones de comando suministrado previamente.

#/bin/shLC_COLLATE=C ls -FCas "$@"

Aquí, la primera línea usa un shebang para indicar qué intérprete debe ejecutar el resto del script, y la segunda línea hace una lista con opciones para indicadores de formato de archivo, columnas, todos los archivos (ninguno omitido) y un tamaño en bloques El LC_COLLATE=C establece el orden de intercalación predeterminado para no doblar mayúsculas y minúsculas juntas, no mezclar archivos de puntos con nombres de archivo normales como efecto secundario de ignorar la puntuación en los nombres (los archivos de puntos generalmente solo se muestran si una opción como se usa -a), y "$@" hace que cualquier parámetro dado a l pase como parámetros a ls, de modo que todas las opciones normales y otra sintaxis conocida por ls aún se pueden usar.

El usuario podría simplemente usar l para la lista breve más utilizada.

Otro ejemplo de un script de shell que podría usarse como acceso directo sería imprimir una lista de todos los archivos y directorios dentro de un directorio determinado.

#/bin/shclara
ls -al

En este caso, el script de shell comenzaría con su línea de inicio normal de #!/bin/sh. A continuación, la secuencia de comandos ejecuta el comando clear, que borra todo el texto de la terminal antes de pasar a la siguiente línea. La siguiente línea proporciona la función principal del script. El comando ls -al enumera los archivos y directorios que se encuentran en el directorio desde el que se ejecuta el script. Los atributos del comando ls podrían cambiarse para reflejar las necesidades del usuario.

Nota: si una implementación no tiene el comando borrar, intente usar el comando clr comando en su lugar.

Trabajos por lotes

Los scripts de Shell permiten que varios comandos que se ingresarían manualmente en una interfaz de línea de comandos se ejecuten automáticamente y sin tener que esperar a que un usuario active cada etapa de la secuencia. Por ejemplo, en un directorio con tres archivos de código fuente C, en lugar de ejecutar manualmente los cuatro comandos necesarios para crear el programa final a partir de ellos, se podría crear un script para shells compatibles con POSIX, aquí llamado build y guardado en el directorio con ellos, que los compilaría automáticamente:

#/bin/shprintf 'compilando... 'n 'cc-c foo. c
cc-c bar. c
cc -c qux. c
cc -o myprog foo.o bar.o qux.o
printf 'hecho. 'n '

La secuencia de comandos permitiría a un usuario guardar el archivo que se está editando, pausar el editor y luego simplemente ejecutar ./build para crear el programa actualizado, probarlo y luego regresar al editor. Sin embargo, desde la década de 1980, los scripts de este tipo han sido reemplazados por utilidades como make, que se especializan en la creación de programas.

Generalización

Los trabajos por lotes simples no son inusuales para tareas aisladas, pero el uso de bucles, pruebas y variables de shell brinda mucha más flexibilidad a los usuarios. Con este archivo se puede crear una secuencia de comandos POSIX sh para convertir imágenes JPEG a imágenes PNG, donde los nombres de las imágenes se proporcionan en la línea de comandos, posiblemente a través de comodines, en lugar de que cada uno se enumere dentro de la secuencia de comandos, normalmente se guarda en un archivo como /home/nombre de usuario/bin/jpg2png

#/bin/shpara jpg; do # use $jpg en lugar de cada nombre de archivo dado, a su vez png=${jpg%.jpg}.png # construir la versión PNG del nombre de archivo reemplazando. Jpg con.png printf 'convertir "%s"... 'n' "$jpg" # información de estado de salida al usuario que ejecuta el script si convertidor "$jpg" jpg.to.png; entonces # use convert (provided by ImageMagick) to create the PNG in a temp filemv jpg.to.png "$png" # Si funcionó, renombra la imagen PNG temporal al nombre correcto más #...otros se quejan y salen del guión printf ■"2 'jpg2png: error: falló la salida guardado en "jpg.to.png".n ' Salida 1 fi # the end of the "if" test constructhecho # the end of the "for" loopprintf 'todas las conversiones exitosasn ' # Dile al usuario las buenas noticias

El comando jpg2png se puede ejecutar en un directorio completo lleno de imágenes JPEG con solo /home/username/bin/jpg2png *.jpg

Programación

Muchos shells modernos también brindan varias características que generalmente se encuentran solo en lenguajes de programación de propósito general más sofisticados, como construcciones de flujo de control, variables, comentarios, matrices, subrutinas, etc. Con este tipo de funciones disponibles, es posible escribir aplicaciones razonablemente sofisticadas como scripts de shell. Sin embargo, todavía están limitados por el hecho de que la mayoría de los lenguajes de shell tienen poco o ningún soporte para sistemas de escritura de datos, clases, subprocesos, matemáticas complejas y otras características comunes del lenguaje completo, y también son generalmente mucho más lentos que el código compilado o los lenguajes interpretados escritos. con la velocidad como objetivo de rendimiento.

Las herramientas estándar de Unix sed y awk brindan capacidades adicionales para la programación de shell; Perl también se puede incrustar en scripts de shell al igual que otros lenguajes de scripting como Tcl. Perl y Tcl también vienen con kits de herramientas gráficas.

Lenguajes de secuencias de comandos POSIX típicos

Los lenguajes de secuencias de comandos que se encuentran comúnmente en las instalaciones de sistemas operativos compatibles con UNIX, Linux y POSIX incluyen:

• KornShell (KornShell)ksh) en varias versiones posibles como ksh88, Korn Shell '93 y otros.
• La cáscara de Bournesh), una de las conchas más antiguas aún comunes en uso
• La cáscara Ccsh)
• GNU Bashbash)
• tclsh, un shell que es un componente principal del lenguaje de programación Tcl/Tk.
• El deseo es una cáscara Tcl/Tk basada en GUI.

Los shells C y Tcl tienen una sintaxis bastante similar a la de dichos lenguajes de programación, y los shells Korn y Bash son desarrollos del shell Bourne, que se basa en el lenguaje ALGOL con elementos de varios otros agregados también. Por otro lado, los diversos shells más herramientas como awk, sed, grep y BASIC, Lisp, C, etc., contribuyeron al lenguaje de programación Perl.

Otros shells que pueden estar disponibles en una máquina o para descargar y/o comprar incluyen:

• Almquist shellash)
• PowerShellmsh)
• Z shell (Z shell)zsh, a particularly common enhanced KornShell)
• La Shell de Tenex Ctcsh).

Los programas relacionados, como shells basados en Python, Ruby, C, Java, Perl, Pascal, Rexx, etc., en diversas formas, también están ampliamente disponibles. Otro shell algo común es Old shell (osh), cuya página de manual indica que "es un puerto mejorado y compatible con versiones anteriores del intérprete de comandos estándar de Sixth Edition UNIX."

Los llamados shells remotos como

• un casco remoto (rsh)
• a Secure Shell (Segura)ssh)

son realmente solo herramientas para ejecutar un shell más complejo en un sistema remoto y no tienen 'shell' como características en sí mismas.

Otros lenguajes de programación

Se han introducido muchos lenguajes de secuencias de comandos potentes para tareas que son demasiado grandes o complejas para manejarlas cómodamente con secuencias de comandos de shell ordinarias, pero para las cuales las ventajas de una secuencia de comandos son deseables y la sobrecarga de desarrollo de un lenguaje de programación compilado completo. sería desventajoso. Los detalles de lo que separa a los lenguajes de secuencias de comandos de los lenguajes de programación de alto nivel es una fuente frecuente de debate, pero, en términos generales, un lenguaje de secuencias de comandos requiere un intérprete.

Ciclo de vida

Las secuencias de comandos de Shell a menudo sirven como una etapa inicial en el desarrollo de software y, a menudo, están sujetas a conversión posterior a una implementación subyacente diferente, más comúnmente convertida a Perl, Python o C. La directiva del intérprete permite que los detalles de implementación sean completamente oculto dentro de la secuencia de comandos, en lugar de estar expuesto como una extensión de nombre de archivo, y proporciona una reimplementación perfecta en diferentes idiomas sin impacto en los usuarios finales.

Mientras que los archivos con la extensión ".sh" La extensión de archivo suele ser un script de shell de algún tipo, la mayoría de los scripts de shell no tienen ninguna extensión de nombre de archivo.

Ventajas y desventajas

Quizás la mayor ventaja de escribir un script de shell es que los comandos y la sintaxis son exactamente los mismos que los que se ingresan directamente en la línea de comandos. El programador no tiene que cambiar a una sintaxis totalmente diferente, como lo haría si el script estuviera escrito en un idioma diferente o si se usara un lenguaje compilado.

A menudo, escribir un script de shell es mucho más rápido que escribir el código equivalente en otros lenguajes de programación. Las muchas ventajas incluyen una fácil selección de programas o archivos, inicio rápido y depuración interactiva. Se puede usar un script de shell para proporcionar un enlace de secuenciación y toma de decisiones en torno a los programas existentes, y para los scripts de tamaño moderado, la ausencia de un paso de compilación es una ventaja. La ejecución interpretativa facilita escribir código de depuración en un script y volver a ejecutarlo para detectar y corregir errores. Los usuarios no expertos pueden usar secuencias de comandos para adaptar el comportamiento de los programas, y las secuencias de comandos de shell brindan un alcance limitado para el multiprocesamiento.

Por otro lado, las secuencias de comandos de shell son propensas a errores costosos. Los errores de escritura involuntarios como rm -rf * / (en lugar del rm -rf */ previsto) son folklore en la comunidad de Unix; un solo espacio extra convierte el comando de uno que elimina todos los subdirectorios contenidos en el directorio actual, a uno que elimina todo del directorio raíz del sistema de archivos. Problemas similares pueden transformar cp y mv en armas peligrosas, y el mal uso de la redirección > puede eliminar el contenido de un archivo. Esto se vuelve más problemático por el hecho de que muchos comandos de UNIX difieren en el nombre por solo una letra: cp, cd, dd, df, etc.

Otra desventaja significativa es la baja velocidad de ejecución y la necesidad de iniciar un nuevo proceso para casi todos los comandos de shell ejecutados. Cuando el trabajo de un script se puede realizar mediante la configuración de una canalización en la que los comandos de filtro eficientes realizan la mayor parte del trabajo, la ralentización se mitiga, pero un script complejo suele ser varios órdenes de magnitud más lento que un programa compilado convencional que realiza una tarea equivalente.

También hay problemas de compatibilidad entre diferentes plataformas. Larry Wall, creador de Perl, escribió que "es más fácil portar un shell que un script de shell".

Del mismo modo, las secuencias de comandos más complejas pueden encontrarse con las limitaciones del propio lenguaje de secuencias de comandos del shell; los límites dificultan la escritura de código de calidad, y las extensiones de varios shells para mejorar los problemas con el lenguaje de shell original pueden empeorar los problemas.

Muchas desventajas de usar algunos lenguajes de secuencias de comandos se deben a defectos de diseño en la sintaxis o la implementación del lenguaje, y no se imponen necesariamente por el uso de una línea de comandos basada en texto; hay una serie de shells que usan otros lenguajes de programación de shell o incluso lenguajes completos como Scsh (que usa Scheme).

Interoperabilidad entre lenguajes de script

Diferentes lenguajes de secuencias de comandos pueden compartir muchos elementos comunes, en gran parte debido a que están basados en POSIX, y algunos shells ofrecen modos para emular diferentes shells. Esto permite que una secuencia de comandos de shell escrita en un lenguaje de secuencias de comandos se adapte a otro.

Un ejemplo de esto es Bash, que ofrece la misma gramática y sintaxis que el shell Bourne y que también proporciona un modo compatible con POSIX. Como tal, la mayoría de los scripts de shell escritos para Bourne Shell se pueden ejecutar en BASH, pero es posible que lo contrario no sea cierto, ya que BASH tiene extensiones que no están presentes en Bourne Shell. Como tal, estas características se conocen como bashisms.

Secuencias de comandos de Shell en otros sistemas operativos

Software de interoperabilidad como Cygwin, MKS Toolkit, Interix (que está disponible en Microsoft Windows Services para UNIX), Hamilton C shell, UWIN (AT&T Unix para Windows) y otros permiten que los programas de shell de Unix se ejecuten en máquinas que ejecutan Windows NT y sus sucesores, con alguna pérdida de funcionalidad en la rama MS-DOS-Windows 95, así como versiones anteriores de MKS Toolkit para OS/2. También están disponibles para estos sistemas al menos tres implementaciones de DCL para sistemas operativos de tipo Windows, además de XLNT, un paquete de lenguaje de secuencias de comandos de uso múltiple que se utiliza con el shell de comandos, Windows Script Host y programación CGI. Mac OS X y posteriores también son similares a Unix.

Además de las herramientas antes mencionadas, algunas funciones POSIX y OS/2 también se pueden usar con los subsistemas ambientales correspondientes de la serie de sistemas operativos Windows NT hasta Windows 2000. Un tercer subsistema de 16 bits, a menudo denominado subsistema MS-DOS, utiliza Command.com proporcionado con estos sistemas operativos para ejecutar los archivos por lotes de MS-DOS antes mencionados.

Las alternativas de consola 4DOS, 4OS2, FreeDOS, NDOS de Peter Norton y 4NT / Take Command que agregan funcionalidad a los archivos por lotes cmd.exe estilo Windows NT, MS-DOS/Windows 95 (ejecutados por Command. com), OS/2's cmd.exe y 4NT respectivamente son similares a los shells que mejoran y están más integrados con Windows Script Host, que viene con tres motores preinstalados, VBScript, JScript y VBA y al que se pueden agregar numerosos motores de terceros, con Rexx, Perl, Python, Ruby y Tcl con funciones predefinidas en 4NT y programas relacionados. PC DOS es bastante similar a MS-DOS, mientras que DR DOS es más diferente. Las versiones anteriores de Windows NT pueden ejecutar versiones contemporáneas de 4OS2 mediante el subsistema OS/2.

Los lenguajes de secuencias de comandos, por definición, pueden ampliarse; por ejemplo, un sistema de tipo MS-DOS/Windows 95/98 y Windows NT permite que los programas de shell/batch llamen a herramientas como KiXtart, QBasic, varias implementaciones de BASIC, Rexx, Perl y Python, Windows Script Host y sus motores instalados. En Unix y otros sistemas compatibles con POSIX, awk y sed se utilizan para ampliar la capacidad de procesamiento numérico y de cadenas de los scripts de shell. Tcl, Perl, Rexx y Python tienen kits de herramientas de gráficos y se pueden usar para codificar funciones y procedimientos para scripts de shell que representan un cuello de botella de velocidad (C, Fortran, lenguaje ensamblador y c son aún mucho más rápidos) y para agregar funcionalidad no disponible en el lenguaje shell, como sockets y otras funciones de conectividad, procesamiento de texto de alta resistencia, trabajo con números si el script de llamada no tiene esas capacidades, código de autoescritura y automodificación, técnicas como recursividad, acceso directo a memoria, varios tipos de clasificación y más, que son difíciles o imposibles en el guión principal, y así sucesivamente. Visual Basic for Applications y VBScript se pueden usar para controlar y comunicarse con elementos como hojas de cálculo, bases de datos, programas programables de todo tipo, software de telecomunicaciones, herramientas de desarrollo, herramientas gráficas y otro software al que se puede acceder a través del modelo de objetos componentes.