




























































































Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Prepara tus exámenes
Prepara tus exámenes y mejora tus resultados gracias a la gran cantidad de recursos disponibles en Docsity
Prepara tus exámenes con los documentos que comparten otros estudiantes como tú en Docsity
Encuentra los documentos específicos para los exámenes de tu universidad
Estudia con lecciones y exámenes resueltos basados en los programas académicos de las mejores universidades
Responde a preguntas de exámenes reales y pon a prueba tu preparación
Consigue puntos base para descargar
Gana puntos ayudando a otros estudiantes o consíguelos activando un Plan Premium
Comunidad
Pide ayuda a la comunidad y resuelve tus dudas de estudio
Ebooks gratuitos
Descarga nuestras guías gratuitas sobre técnicas de estudio, métodos para controlar la ansiedad y consejos para la tesis preparadas por los tutores de Docsity
Articulo Programación Bash_Shell
Tipo: Apuntes
1 / 168
Esta página no es visible en la vista previa
¡No te pierdas las partes importantes!





























































































En este tutorial pretendemos enseñar el manejo de Bash, el Bourne Again Shell de GNU. Este shell es el que proporcionan por defecto muchos sistemas UNIX entre ellos Mac OS X o Linux. Los ejemplos se explicarán sobre Mac OS X, pero debido a la interoperatividad que caracteriza a Bash, estos ejemplos deberían ser exactamente igual de útiles en otros sistemas UNIX. Cuando existan diferencias las indicaremos para que usuarios de otros sistemas puedan seguir correctamente este documento. El tutorial asume que el lector conoce los aspectos más básicos de qué es, y para qué sirve un terminal. No pretendemos enseñar cuales son los muchos y útiles comandos a los que podemos acceder, sólo pretendemos centrarnos en el manejo, personalización y programación de scripts con el shell Bash. Aun así, a lo largo del documento comentaremos gran cantidad de comandos que están relacionados con el shell, y que ayudan a hacer que los ejemplos resulten útiles. Al acabar este tutorial el lector debería de haber aprendido a usar las principales teclas rápidas, personalizar mucho más su terminal para hacerlo más manejable, y modificar o crear los scripts que configuran su sistema.
Este tutorial ha sido escrito por Fernando López Hernández para MacProgramadores, y de acuerdo a los derechos que le concede la legislación española e internacional el autor prohíbe la publicación de este documento en cualquier otro servidor web, así como su venta, o difusión en cualquier otro medio sin autorización previa. Sin embargo el autor anima a todos los servidores web a colocar enlaces a este documento. El autor también anima a cualquier persona interesada en conocer el shell Bash, y que ventajas que aporta tanto al usuario como al programador, a bajarse o imprimirse este tutorial. Madrid, Enero 2009 Para cualquier aclaración contacte con: [email protected]
Sinopsis: Como se justifica en el acerca de, este tutorial va a omitir los aspectos más básicos del shell que es normal conocer por parte de cualquier persona que haya usado mínimamente un shell UNIX. En este primer tema vamos a repasar un conjunto de aspectos fundamentales que, aunque en parte puede conocer el lector, creemos que conviene aclarar antes de profundizar. Por consiguiente, recomendamos empezar leyendo este primer tema, ya que sino pueden quedar ciertos aspectos sin concretar que luego podrían hacer falta para seguir más cómodamente las explicaciones. Debido a sus objetivos, este tema está escrito avanzando de forma considerablemente más rápida y superficial que en resto de temas.
Mac OS X trae preinstalado el shell Bash desde la versión 10.2, antes traía instalado el shell tcsh, pero debido a que Bash es el shell que GNU eligió para el software libre, Apple decidió dar el salto. Linux lógicamente también usa este shell, con lo cual parece ser que Bash es el shell de los sistemas UNIX más utilizados, y tiene un futuro muy prometedor. Si queremos saber que versión de shell tenemos instalado podemos usar el comando: $ echo $SHELL /bin/bash Este comando nos indica que shell estamos usando y en que directorio está instalado. Si queremos conocer la versión de Bash podemos usar el comando: $ echo $BASH_VERSION 2.05b.0(1)-release También podemos saber donde está instalado Bash con el comando: $ whereis bash /bin/bash Puede conocer todos los shell de que dispone su máquina con el comando: $ cat /etc/shells /bin/bash /bin/csh /bin/sh /bin/tcsh /bin/zsh Si por alguna razón no está usando Bash, pero lo tiene instalado (o lo acaba de instalar) en su máquina, puede hacer que Bash sea el shell por defecto de su cuenta usando el comando: $ chsh - s /bin/bash Si prefiere usar una versión más moderna de shell que la que viene preinstalada con Mac OS X puede bajársela del proyecto Fink^1 : (^1) Si no tiene Fink instalado puede bajárselo de http://fink.sourceforge.net/
Para referirnos a varios ficheros es muy típico usar los comodines de la Tabla
serían todos los caracteres ASCII excepto los dígitos, y [a-zA-Z0-9] serían todas las letras mayúsculas, minúsculas y los dígitos. La razón por la que este comodín no ha sido tan usado como se esperaba es que expande por un, y sólo un dígito, por ejemplo programa.[co] encontraría programa.c y programa.o, pero no programa.cpp. Es importante tener en cuenta que los comandos cuando se ejecutan no ven los comodines sino el resultado de la expansión. Por ejemplo si ejecutamos el comando: $ cp g /tmp* g* se expande por todos los ficheros que cumplen el patrón, y esto es lo que se pasa al comando cp, pero si no existiera ningún fichero cuyo nombre cumpliese el patrón g, este valor no se expande sino que se pasa tal cual al comando, y éste será el que fallará: $ cp g /tmp/ cp: g*: No such file or directory Es decir, como podríamos pensar, al fallar no se pasa una lista vacía al comando. Piense por un momento lo que ocurriría con algunos comandos si se hubiese diseñado así. Este funcionamiento es ligeramente distinto al de tcsh, donde si no se expande el comodín no se ejecuta el comando, en Bash se ejecuta el comando aunque luego éste produzca un error.
El comodín tilde ~ se usa para referirse al directorio home de los usuarios (/Users en Mac OS X o /home en la mayoría de las máquinas UNIX), por ejemplo si usamos ~carol/carta.txt nos lo expande por /Users/carol/carta.txt. Además podemos usar el comodín tilde para referirnos a nuestro propio directorio, el cuyo caso debemos de precederlo por una barra, p.e. ~/carta.txt se expande por el nombre de mi directorio, en mi caso /Users/fernando/carta.txt. Observe la diferencia entre poner la barra y no ponerla, si no la hubiera puesto (hubiera puesto ~carta.txt), me habría expandido por la ruta /Users/carta.txt, y si no existe un usuario con el nombre carta.txt hubiera producido un error indicando que no existe el directorio.
cl[e-i]ve.h Por último comentar que la llave debe contener al menos dos cadenas, sino no se realiza la expansión: $ echo ca{a}sa ca{a}sa De nuevo este comportamiento difiere con el de tcsh, donde la expansión se realiza aunque haya una sola cadena dentro de las llaves.
Bash permite usar un conjunto de comodines extendidos, pero para poder usarlos debemos de activar la opción ext_glob de Bash (véase el apartado 3 del Tema 3) con el comando: $ shopt - s extglob En este caso se pueden usar uno de estos cinco nuevos tipos de patrones: ?( pattern-list ) Cero o una ocurrencia de pattern-list *( pattern-list ) Cero o más ocurrencias de pattern-list +( pattern-list ) Una o más ocurrencias de pattern-list @( pattern-list ) Exactamente uno de los patrones de la lista !( pattern-list ) Cualquier cosa excepto uno de los patrones de la lista pattern-list recibe uno o más patrones separados por |. Cada patrón de esta lista puede contener comodines, por ejemplo +([0-9]) busca cadenas formadas por uno o más dígitos. En el apartado 2.1 vimos que un problema que presentaba el comodín? era que carta?.txt listaría ficheros como carta1.txt, carta2.txt, pero no carta10.txt. Esto lo podemos solucionar con el comodín extendido +( pattern-list ) de la forma: carta+([0..9]).txt
También vimos en el apartado 2.1 que .[cho] encontraría los ficheros con extensión .c, .o y .h, pero no había forma de encontrar los .cpp ya que el corchete sólo aceptaba un carácter. Ahora podemos usar el comodín @( pattern-list ) para indicar la lista de extensiones a aceptar. Por ejemplo .@(c|o|h|cpp) encontraría correctamente estos ficheros: $ ls .@(c|o|h|cpp) clave.cpp clave.h También hubiera sido equivalente usar @(.c|.o|.h|.cpp) ya que los patrones pueden estar anidados. Si lo que hubiéramos querido es encontrar todos los ficheros excepto los .gif, los .jpg y los .html podríamos haber usado el patrón !(.html|gif|jpg). Sin embargo, en este caso no podríamos haber usado *.!(html|gif|jpg) Un último ejemplo, si queremos borrar todos los ficheros excepto los que empiezan por vt seguido por uno o más dígitos podemos usar el comando: $ rm !(vt+([0-9]))
UNIX está basado en una idea muy simple pero muy útil: Tratar todos las entrada y salidas como streams (flujos) de bytes. Cada programa va a tener asociadas siempre una entrada estándar (por defecto el teclado), una salida estándar (por defecto la consola), y una salida de errores estándar (por defecto también la consola). Si queremos, podemos cambiar la entrada estándar para que el programa reciba datos de un fichero usando el operador de redirección <. Por ejemplo el comando cat, si no recibe argumentos, lee del teclado por la entrada estándar y lo pasa a la salida estándar: $ cat Esto es una linea acabada en intro Esto es una linea acabada en intro ^D Podemos indicar el final de un stream desde el teclado con la combinación de teclas Ctrl+D como se muestra en el ejemplo. Podemos cambiar la entrada estándar de cat para que lea de un fichero con: $ cat < clave.h #ifndef CLAVE_H_ ····· En el caso concreto del comando cat, también puede recibir como argumento el nombre del fichero a pasar a la salida estándar, con lo que en el caso del comando cat nos podríamos haber ahorrado el operador <: $ cat clave.h #ifndef CLAVE_H_ ····· UNIX dispone de un gran número de comandos que leen de la entrada estándar, realizan una operación con el texto, y escriben en la salida estándar (o en la salida de errores si se produce un error): cat, grep, soft, cut, sed, tr,... El operador de redirección de salida > permite cambiar la salida estándar de un comando, por ejemplo:
$ date > ahora Envía el día y hora actuales al fichero ahora. También podemos cambiar a la vez la entrada y salida estándar de un programa usando ambos operadores de redirección. Por ejemplo: $ cat < ficheroa > ficherob También podemos cambiar la salida de errores estándar con el operador de redirección 2>. Por ejemplo: $ cat < ficheroa > ficherob 2>errores Copia el ficheroa en el ficherob, y si se produce algún error lo escribe en el fichero errores. Si no queremos sobrescribir un fichero de salida sino añadir el contenido al final podemos usar el operador de redirección >> para la salida estándar o 2>> para los errores estándar. Por ejemplo: $ ls p >>ficheros 2>>errores* Añadiría los ficheros que lista ls al fichero ficheros, y si se produjesen errores los añadiría al fichero errores. El operador de redirección 2>> es especialmente útil para almacenar los conocidos logs de errores. Muchas veces no se quiere que un programa muestre mensajes en la consola del usuario, en este caso es muy común redirigir su salida estándar y salida de errores estándar al fichero /dev/null: $ *gcc .cpp > /dev/null 2> /dev/null
Es posible redirigir la salida estándar de un programa a la entrada estándar de otro usando el operador | (pipeline). more es uno de los comandos típicos que lo usan. Este comando lo que hace es recoger la entrada estándar y irla mostrando poco a poco (página a página), luego si por ejemplo tenemos un directorio con muchos ficheros podemos hacer: $ ls - la | more y se irán mostrando página a página los ficheros.
Podemos ejecutar un comando que tarde mucho en ejecutarse y dejarlo ejecutando en background precediéndolo por &. Por ejemplo para compilar un conjunto de ficheros fuente de un programa C++ podemos hacer: $ *gcc .cpp & Aunque el proceso se sigue ejecutando en background, los mensajes que produce salen en la consola impidiéndonos trabajan cómodamente. Para evitarlo podemos enviar los mensajes a /dev/null: $ *gcc .cpp > /dev/null & Aunque si se produce un error, éste irá a la salida de errores estándar, con lo que seguiría saliendo en consola. Podríamos evitarlo redirigiendo también la salida de errores estándar, pero quizá sea mejor que se nos informase del error. Otras veces lo que queremos es esperar a que se acabe de ejecutar un comando para ejecutar el siguiente, en este caso podemos usar el operador ; (punto y coma), por ejemplo, podríamos querer compilar el comando clave para luego ejecutarlo: $ gcc clave.cpp - o clave ; clave Este comando primero compila el programa, y cuando acaba de compilarlo lo ejecuta.
Los caracteres <, >, |, & *,? , ~, [, ], {, } son ejemplos de caracteres especiales para Bash que ya hemos visto. La Tabla 1. 2 muestra todos los caracteres especiales de Bash. Más adelante veremos otros comandos tienen sus propios caracteres especiales, como puedan ser los comandos que usan expresiones regulares o los operadores de manejo de cadenas. Carácter Descripción ~ (^) Directorio home ` (^) Sustitución de comando
$ (^) Variable & (^) Proceso en background ; (^) Separador de comandos
Aunque los caracteres especiales son muy útiles para Bash, a veces queremos usar un carácter especial literalmente, es decir sin su significado especial, en este caso necesitamos entrecomillarlo (quoting). Por ejemplo si queremos escribir en consola el mensaje: 2*3>5 es una expresión cierta, podemos usar el comando echo así: