Con la disculpa de probar la D5200 me llevé a las chicas de paseo.

La que más ha salido ganando fue Ada, que ha ‘heredado’ la vieja D70.

Aunque me dejé el trípode en casa no pude resistir la tentación de intentar hacer un par de fotos del agua con velocidad lenta, pero no tanto como para que no salieran demasiado trepidadas a pulso. Un buen motivo para volver y recorrerla con más calma…

Ribeira Sacra creo que debe su nombre a la cantidad de monasterios y edificios religiosos de la zona, como el de San Esteban en las siguientes fotos:

Desde este embalse parten los catamaranes que hacen la ruta turística por el Sil.

Si hacemos el paseo en barco, a ambos lados del río podemos apreciar que en en las casi inaccesibles laderas hay multitud de viñas…

Esta semana, tristemente es noticia el devastador incendio que arrasó parte de este paraíso natural gallego, hace un par de años estuvimos allí, pero por falta de tiempo no publiqué las fotos, hoy he sacado tiempo para seleccionar algunas, y me gustaría compartirlas con vosotros.

Esta vez sólo pondré las fotos, porque creo que sobran las palabras…

Casi desde el aparcamiento hice esta panorámica de la Laguna de los Peces:

Ada, desde el camino afotando la Laguna.

En la presa de piedra un descansito…

Luego continuamos por el sendero y volviendo la vista atrás vemos la laguna de nuevo…

Remontamos una pequeña colina y perdemos de vista la Laguna de los peces pero al poco ya se puede divisar la Laguna de Yeguas.

En la laguna una familia de aves nadaba tranquilamente…

Mientras Ada se entretenía haciendo ondas con su bastón.

Hay que continuar la ruta y cruzar hacia el otro lado donde hay unas antiguas cabañas de pastores y un pequeño refugio de montañeros.

Ups, esta al lado de la cabaña de pastores la hizo Belén, aunque se me coló la firma…

La laguna, vista desde aquí, según me hizo observar Ada tiene forma de corazón.

Y estas fueron las dos caminatas más largas que hicimos. Otro año tengo que volver y subir a la presa rota del Tera para contaros la historia del pueblo de Ribadelago…

Una caminata muy chula es la de la Cascada de Sotillo, y se puede hacer aunque el sol apriete ya que prácticamente toda la ruta transcurre a la sombra de un robledal. Son poco más de 6 Km, circular, y de dificultad media. Se complica un poco en las fuertes pendientes cerca de la cascada, pero está acondicionada, así que es apta para niños (Duración estimada 3-4 horas). Y si estáis con fuerzas para caminar hay una variante que pasa por la laguna de Sotillo y la laguna de Carros, pero esa ya son 17Km…  

Bueno el camino como os decía transcurre casi siempre a la sombra lo cual es muy de agradecer en la subida, que es aconsejable comenzar por la parte izquierda, que es más suave, y bajar luego por la parte más pronunciada y rocosa bordeando el río truchas.

Hay que decir que está muy bien señalizado, con hitos de madera e incluso carteles.

A mitad del camino de subida Belén nos hizo esta foto junto a un árbol seco y pilló a Ada hurgándose la nariz…

En la parte más alta del recorrido hay este mirador natural. Ada no tuvo paciencia para esperar a que ajustara el flash para rellenar un poco el primer plano que estaba en la sombra y si no rellenaba con flash me salía el cielo muy quemado.

Un pequeño pero pronunciado descenso…

Y llegamos a la cascada de Sotillo, la caminata ha merecido la pena.

Una foto bajando un poco la velocidad, aunque no mucho porque estaba usando un poste del mirador como trípode improvisado…

Mi hija inmortalizó el momento ‘Fotolibre estuvo aquí’…

Una foto con mis dos preciosidades frente a la cascada.

Y solo queda bajar, que no es poco, porque la bajada en su primera parte es bastante pronunciada y rocosa. Aquí ya era algo más suave.

Espero que os haya gustado el paseo…

De Carnota, aparte de sus preciosas playas, que ya os enseñé en entregas anteriores, hay que visitar el hórreo. Es uno de los más grandes de Galicia, bueno los del lugar te dirán que es el más grande, y es que todo depende de según se mida, ya que el de Lira es unos centímetros más largo, pero si medimos la superficie gana el de Carnota ya que tiene 1,90 metros de ancho frente a los tan solo 1,60 del de Lira. Y ambos son superados en anchura y en longitud tan solo por el hórreo de Araño en Rianxo, pero aquí te dirán que ese no cuenta porque no está sustentado sobre ‘pies’ como estos si no que es de una construcción más parecida a la de las paneras Asturianas. El caso es que estos dos hórreos, el de Carnota y el de Lira fueron construidos casi simultáneamente y su gran tamaño es producto de la rivalidad entre pueblos vecinos, ya que cada uno quería tener el hórreo mayor que el otro.

Aunque titulo el reportaje “De Muros a Fisterra” un día nos acercamos a Vimianzo, a visitar el castillo, que queda un poco más al norte de Fisterra, pero merece la pena.

Y ya para finalizar este viaje fotográfico que mejor que hacerlo en el fin de la tierra, Fisterra es el cabo más al oeste de Galicia.

El Faro:

Un cruceiro cerca del faro:

La iglesia de Nosa Señora das Areas

Y hasta aquí mi visión pero también quería poner dos fotos que hicieron mis chicas en un puesto de ‘souvenirs’ junto al faro de Fisterra:

De las excursiones pedestres, creo que la que más nos gustó a todos fue la subida a la cumbre de ‘A Moa’ (traducido ‘La Muela’), el punto más alto del monte Pindo. Hay varias rutas que conducen a este lugar: se puede subir desde Quilmas, desde San Clemente en la aldea de Pindo o desde la aldea de ‘O Fieiro’ que se encuentra atravesando el embalse del Ézaro y continuando por la pista asfaltada.  Esta fue la variante que hicimos nosotros.

El monte Pindo, al fondo, visto desde el pueblo de Arcos:

Desde O Fieiro se toma un desvío por una pista de tierra a mano derecha, a partir de la cual comienza la ascensión bastante bien señalizada con algunos carteles, marcas de pintura y piedras amontonadas.

Iniciamos la ruta en dos ocasiones, la primera, tras ponernos en camino una amenazadora niebla empezó a hacer acto de presencia

Y hasta aquí pudimos llegar, que la niebla no es buena compañera y cada vez estaba más cerca. Así que nos dimos la vuelta y pospusimos la aventura para otro día.

Al día siguiente, volvimos al punto de partida y al bajar del coche me di cuenta de que me había dejado la cámara en casa, así que todas las fotos a partir de ahora están hechas con la Lumix  

Pasando la señal donde el día anterior dimos la vuelta a causa de la niebla, la ruta se empieza a hacer cada vez más empinada y pedregosa, pero merece la pena.

Volviendo la vista atrás, a pesar de la abundante bruma, se ve a lo lejos la serpenteante carretera que sube al mirador de Ézaro y las tuberías que llevan el agua a la central eléctrica, y en las cumbres vecinas una procesión de generadores eólicos.

Aquí exprimiendo al máximo el zoom de la lumix vemos el mirador de Ézaro.

A lo largo del camino rocas curiosas…

Ya se que también puede ser la huella de un perro grande, pero por lo largas y afiladas de las uñas a mi se me antojó que era de lobo…

Dos árboles secos que llamaron mi atención.

Más piedras…

Algo antes de llegar a la cima ya se puede divisar la playa de Carnota.

Y ya en la cumbre la foto de grupo, con la playa de Carnota al fondo.

Ada, con los pantalones rotos de tanto subir y bajar por las rocas, acercándose al mojón del vértice geodésico.

Unas mesitas estratégicamente colocadas al abrigo del fuerte viento que soplaba en la cumbre son el sitio ideal para merendar y coger fuerzas para el camino de bajada.

Disculpad que no ponga fotos del impresionante panorama que se veía desde arriba, las playas, y los pueblos que rodean al monte pero es que la bruma deslucía mucho el paisaje al nivel del mar, y además no llevaba mi cámara…  

Muy cerquita de este también hay otro que sube al pico de ‘Bico do Santo’

Para los interesados en el arte prehistórico hay algunas rutas en las que podemos ver petroglifos, como este que está en Louro y se le conoce por el nombre de Laxe das Rodas. Se trata de un grabado rupestres, tallado en rocas graníticas, de la época calcolítica.

Una de las nueve figuras grabadas sobre esta roca es una espiral con 45 hoyos a su alrededor, que se cree que se trataba de un calendario lunar.

Otro petroglifo interesante es el de Laxe Escrita:

Que a parte de varias figuras circulares que también hay quien interpreta como algún tipo de calendario o mapa astrológico,

Tiene también estas figuras que se me antojaban representaciones humanas, pero leyendo los carteles parece ser que se trata de barcos, con sus velas, quizá pueda representar una posible batalla.

Y no os aburro más con tanta piedra… 

Ézaro es un precioso pueblo del municipio de Dumbría. Tiene muy buenas playas, y unos preciosos paisajes con el mar a un lado y el monte Pindo al otro. Toda una delicia para el fotógrafo aficionado.

Al salir de Ézaro en dirección a Cee, donde termina la subida de la carretera hay un cruce a la izquierda, señalizado como camino sin salida. Pero os invito a adentraros por ese camino porque, al final, tras una bajada con espectaculares vistas, abajo de todo hay un mirador (¿Quien dijo que los miradores siempre tenían que estar en lo alto?) con unas mesitas de piedra por si apetece una merienda mirando al mar.

Desde el mirador en cuestión disparé unas cuantas fotos para hacer esta panorámica.

Pero lo más espectacular de este pueblo es la ruta de 'la luz', subiendo por una empinada y serpenteante carretera entre los tubos que bajan a la central eléctrica, se llega a este mirador (esta vez en una atalaya) de vistas espectaculares. En días sin bruma, que no era el caso, se divisa el cabo de Finisterre.

Casi en la playa de Ézaro desemboca el río Xallas. Dicen, aunque no sé si será cierto, que es el único río de Europa que desemboca en el mar en cascada. Pero como la mano del hombre todo lo destroza, este espectacular accidente geográfico se ve interrumpido por una presa que alimenta una central hidroeléctrica a través de unas gruesas tuberías.

Al fondo, a la derecha, la presa, vista desde el monte Pindo:

Normalmente, la cascada, luce más seca que un lagarto de museo, tal que así:

Pero si la estación ha sido abundante en lluvias, y para no defraudar al turismo, se abren las compuertas durante una hora los sábados por la noche y durante media los domingos por la mañana. Es mucho más bonito verla de noche iluminada por unos potentes faros halógenos, que deben alimentarse directamente de la central que le roba el agua el resto de la semana.

El mejor ángulo para verla es desde la pasarela de madera, pero la foto es complicada porque la gente no deja de pasar, haciendo trepidar la pasarela sobre la que asienta el trípode…

Desde las rocas al final de la pasarela, el trípode asienta mejor pero creo que no se ve tan bien la cascada. Lo suyo sería meterse en las rocas que hay a la derecha de la pasarela pero hay unas carteles de peligro que lo desaconsejan y uno es bastante prudente…

Creo que esta vez, hice caso de vuestros consejos y no me han quedado las fotos faltas de luz y contraste…

Pues nada, que el mes pasado estuve 15 días en Carnota, y quería mostraros unas fotos de mis pequeñas excursiones por los alrededores. Un sitio muy chulo cerquita de carnota es Louro.

El paisaje de este pueblo es admirable. Hay un cabo que se adentra en el mar formado por una pequeña montaña rocosa llamada Monte Louro, y a su pié una laguna bordeada por unas dunas. Tomando algo en un bar del pueblo me fijé en una foto panorámica que tenían colgada preciosa, estaba tomada desde el Monte Louro hacia la costa y se veía hacia un lado la playa y hacia el otro las dunas y la laguna y los pueblos de Louro y Lariño. Así que me propuse (sin demasiado éxito) hacer una foto parecida.

Desde el pueblo hay una carretera que lleva hasta el faro

y desde allí se puede ascender al monte por caminos que lo van rodeando en espiral hasta casi la cumbre, dónde hay una antena de telefonía.

Mi sobrino Rodrigo, Ada y Belén me acompañaban. Belén ya le va cogiendo el tranquillo a la Lumix, no como este despistao que parece que no se entera con la Nikon

Desde algunos puntos del camino se divisa desde arriba la Laguna y las dunas.

Pero la mejor vista es accediendo por otro lado, sin subir al monte, así se puede contemplar la laguna con el monte Louro al fondo, y las dunas.

Algunas rocas con expresivas formas parecen apuntarnos con un guiño por dónde se divisan las mejores vistas.

Otras en cambio en un increíble equilibrio desafían a la gravedad.

No es fácil intentar salirse del camino porque las zonas que no son rocosas están cubiertas de abundante vegetación, así que no supe encontrar un lugar desde el que se abarcase con la vista ambos lados del monte. Tuve que consolarme con sacar una panorámica de la playa y el pueblo de Louro.

Y ya puestos, tras las del monte Aloia, que queda casi casi lo más al sur de Galicia. ¿Porqué no poner algunas fotos de casi lo más al norte? Y digo casi, porque lo más al norte es Estaca de Bares justo al otro lado de la misma ría. Estoy hablando de Cabo Ortegal, en la ría de Ortigueira.

Después de comer un pulpo a feira y un bacalao al ajo pescador en Cariño,  nos acercamos hasta el faro.

Mirando hacia tierra se ve la carretera por la que llegamos…

Esta nos la hizo Ada….

Volviendo sobre nuestros pasos, a la derecha se coge una carretera que va hacia San Andrés de Teixido y que tiene unos miradores desde los que se divisa Cariño.

No me resistí a tirar una serie de 9 o 10 fotos en vertical para montar esta panorámica de 180º:

Ya cerca de San Andrés de Teixido hay otro mirador con una placa dedicada al actor Leslie Howard, o más bien al avión Ibis en el que falleció, junto con otros 16 pasajeros, cuando fue derribado por los alemanes en 1943.

La hilera de casitas cuesta abajo que se ven a lo lejos en el valle son el pueblo de San Andrés de Teixido, después de Santiago de Compostela el lugar de peregrinación de más renombre de Galicia.

Dice un dicho popular, 'A San Andres de Teixido vai de morto quen non foi de vivo.' ('A San Andrés de Teixido, va después de muerto el que no fué en vida'). Esta es la Capilla:

No hice fotos del interior porque estaban celebrando Misa.

Después de ver la Capilla, hay que bajar hasta la fuente de los tres Caños, pero no para beber, porque no es potable. La tradición dice que hay que pedir un deseo al santo y echar una miga de pan al agua, y que si el pan no se hunde, el deseo se cumplirá.

Un detalle de la fuente…

Ya sabéis que, más por falta de tiempo que por otra cosa, hace muuucho que no subo fotos. Eso no quiere decir que no las haga. Aunque tengo bastante material en la recámara, no voy a ir por orden. Estas son de los primeros días medianamente buenos de esta primavera… que llevamos un invierno que no para de llover…

El Monte Aloia es un parque natural cerca de Tui, al sur de Pontevedra que se presta a pasar una tarde o todo el día paseando entre naturaleza. Subiendo hacia la cumbre, encontramos el centro de interpretación del monte:

Algo más arriba hay unas impresionantes vistas de la ciudad de Tui y del río Miño.

Como siempre hay ciertos elementos que rompen un poco con el entorno, pero supongo que es precio que debemos pagar si queremos estar conectados…. 

En el monte hay varios miradores, al del Ingeniero Areses hay que subir más por ver el mirador en sí que por las vistas que se pueden ver desde él.

Y es que los árboles a su alrededor han crecido tanto que casi ha perdido su condición de 'mirador'

No aconsejable para personas con vértigo, (como mi mujer).

Por aquí subimos a otro mirador…

Que goza de mejores vistas…

En días claros se pueden ver tres rías, la de Vigo, La de Pontevedra y la de Arousa.

También se puede visitar la capilla de San Xiao, reconstruida en 1713 sobre una iglesia románica.

.

Hace tiempo que no pongo uno de mis reportajes, creo que ha llegado el momento de sacarle las telarañas a la página que ya tengo demasiadas fotos en la recámara esperando a ser procesadas, hoy me puse con estas de la pasada primavera…

De Pedro Madruga se cuentan todo tipo de mitos, incluso hay teorías que aseguran que era el mismísimo Cristóbal Colón. Se cuenta que el apodo de 'Madruga'  se lo ganó porque que ajusticiaba a sus enemigos a horas muy tempranas. Esta fortaleza fue testigo de su historia y de sus más sanguinarias batallas.

Lejos de lo que pudo haber sido su pasado hoy el castillo de Soutomaior es un sitio para visitar plácidamente y sobre todo darse un buen paseo por los jardines que lo rodean.

La entrada de este castillo conserva su puente levadizo:

con su maquinaria todavía intacta

Si vais en pareja es obligada la foto de la chica asomada a los arcos de la Galería de damas:

Si la visita por el interior es interesante

No lo es menos asomarse desde cualquiera de sus almenas a contemplar las maravillosas vistas…

Y como ya dije un recorrido por los alrededores hará las delicias de cualquier interesado en la botánica…

Estando en O Courel, hay que acercarse a Ancares, y si hay un pueblo pintoresco en Los Ancares de Lugo ese es Piornedo, en el municipio de Cervantes.

En estos pueblos de montaña acostumbrados a permanecer incomunicados por la nieve en invierno, hasta hace muy poco la vivienda más adecuada era la palloza, grandes construcciones de origen celta con techo de paja que tenían todo dentro, las cuadras de las vacas, el gallinero, el almacen de comida y forraje, el horno de pan… Así si nevaba tanto que no podías salir, siempre tenías la leche, los huevos frescos a mano. Hasta hace relativamente poco la gente de estos pueblos vivía en pallozas. Hoy las pallozas se conservan y conviven con construcciones más modernas pero ya no como vivienda, aparte de las que hacen de museo, la mayoría de ellas sirven de almacén para los productos y aperos agrícolas.

Dentro de la palloza generalmente había un pasillo central, y estancias separadas con tabiques de madera para el ganado, las alcobas, la cocina de 'lareira'

En lo más alto del pueblo está esta iglesia:

Y como no también en Ancares aprovechamos la nieve…

Si Galicia es todavía ese reducto de nuestra geografía no colonizado por las supuestas ventajas de la civilización moderna, el Caurel es sin duda el confín que lo demuestra.

Tuve la suerte de ver un paisaje que no supe retratar. Las montañas estaban tapizadas de diversos colores, entre los distintos verdes de la vegetación había retales de rosa fucsia de la flor de brezo, y de amarillo de la flor del tojo, y en las cumbres el blanco de la nieve… Una combinación supongo que no demasiado habitual. Todos los paisanos decían que no era muy normal que nevase en estas fechas. Pero el caso es que en los cuatro días que pasamos en Caurel, tuvimos lluvia, nieve y también algo de sol, así que no nos podemos quejar.

El monte de la izquierda que tiene como una depresión desde la cumbre hasta la carretera es una antigua mina aurífera romana de cielo abierto (ruina montium).

En los ratos que la lluvia cesaba un poco aprovechamos para dar alguna caminata, no demasiado larga, como esta hacia las ruinas del Castillo de Carbedo

Eso si, bien pertrechados con chubasqueros, porque a la mínima empezaba a llover.

Esto es lo que queda del castillo:

De visita obligada es Cebreiro, simpre me ha llamado la atención el nombre, porque dudo que jamás hubiese cebras por aquí  supongo que vendra de ciervos como Cervantes.

Cebreiro es un importante hito del camino de Santiago:

En el interior de esta Iglesia

hay una capilla con un antiguo cáliz legendario, el Santo Grial que aparece en el centro del escudo gallego.

El caso es que como Cebreiro estaba nevado y el museo etnográfico estaba cerrado aprovechamos para jugar un rato en la nieve.

Entre Sanroque de Riomiera y Vaga de Pas está Villacarriedo, me llamó la atención la cantidad de geranios que tenían por las aceras y colgados de todos los balcones.

El monumento más importante es el palacio de Soñanes:

Y la Iglesia, Creo que es la de San Martín.

Mirones es un pueblecito que queda entre Liérganes y San Roque de Riomiera

Esta es la iglesia de San Román, siglo XVII creo…

Hay una rutita para patear, cortita, que pasa por este puente romano.

Como estos días de invierno no son muy propicios para salir a afotar paisajes estuve desempolvando fotos de las vacaciones… A ver que os parecen

San roque de Riomiera:

Con GPS y todo nos costó dar con este camping pero solo por la vista y la tranquilidad creo que mereció la pena. Esto era lo que se veía desde el bungalow.

Según llegamos, nada más instalarnos, nos pusimos a dar un paseito hasta un mirador que había camino arriba saliendo desde el camping, hacia el lugar de Calseca.

Ese que se ve ahí arriba a la izquierda, salimos con buen tiempo, algo nublado pero no parecía amenazar lluvia y llegando al mirador empezó a llover, bueno más que llover a levantarse una niebla de esas que mojan, y ya ni fotos panorámicas ni nada. Y menos mal que llevávamos chubasqueros. Es lo que tiene el norte…

Esta fué otro día, en el barrio de la Concha, donde estaban preparando una especie de museo, la 'Casa del Pasiego' pero no podía visitarse todavía.

No sé si debería llamar Ribeira o Riveira al municipio coruñés cuya capital es Santa Uxia de Riveira. No tengo muy claro cual es el nombre oficial y lo tengo visto escrito de ambas formas, más con 'B' que con 'V' creo que el oficial es con V pero el más usado es con B.

Bueno en cualquier caso os propongo un recorrido por la península del Barbanza, que separa las rías de Noia/Muros al Norte y la de Arousa al Sur.

En Ribeira no hay que  perderse la visita al parque de San Roque, el el que podemos encontrar desde una reconstrucción de un poblado celta (no es un castro real, como los que tengo puesto en otros reportajes, es una réplica):

Pasando por agrupaciones megalíticas, vamos un Stonehenge en pequeño…

Un dólmen (también es una réplica), pero desde él hay preciosas vistas a la ría de Arousa.

Petrioglifos…

Y un sendero para dar un paseito hasta la capilla de San Roque….

Y si nos apetece seguir hasta el mirador de 'A Pedra Da Rá'.

Desde donde podemos ver a vista de pájaro las Dunas de Corrubedo.

Las Dunas serán la siguiente etapa de nuestro recorrido: Recuerdo que hace no muchos años la pasarela atravesaba las dunas, para acceder al a playa pero los muchos visitantes que acudían no respetaban los carteles que prohibían salirse de la pasarela. Ahora solo se puede acceder hasta el pié de la duna, hay vigilantes, y para llegar a la playa hay que rodearlas.

Desde las dunas podemos acercarnos al Dólmen de Axeitos. (Este es de verdad, eh, no una réplica)

Desde aquí podemos acercarnos a Xuño dónde hay otra ruta de senderismo no demasiado larga en la que podemos ver este antiguo puente medieval.

Y finalmente a Porto do Son, un bonito pueblo en el que podemos disfrutar de la playa, Y como no ver el castro de Baroña

Como ya os comentaba cuando hablaba del castro de Santa Tegra y del de San Cibrao de Lás, el Castro de Baroña, en Porto do Son es en mi opinión el más bello de los castros gallegos. Su situación, en una minúscula península es privilegiada.

El castro estaba protegido por murallas y se acede a él por una rampa y una escalera.

Desde el castro podemos ver la playa de Arealonga, la primera (y más polémica) playa nudista de Galicia.

Un sendero lleva al sector más alto del poblado, en el que también hay construcciones.

Si pasáis por Verín (Ourense) no dejéis de acercaros al Castillo de Monterrei.

Impresionante recinto amurallado en el que salvo que vayáis un Lunes o un Martes, que está cerrado, podréis subir a la Torre del Homenaje y contemplar unas vistas privilegiadas.

La Torre de las Damas, más pequeña y contigua al Palacio de los Condes no se puede visitar, pero si el palacio, habilitado como museo, y la Iglesia gótica de Santa María.

Sobre cada una de las columnas de la galería del palacio hay un escudo distinto.

Un retablo de piedra en la Iglesia.

Una de las riquezas naturales de las que creo que podemos presumir los gallegos es el "Parque Natural de las Islas Atlánticas", situado en las rías de Vigo, Pontevedra y Arousa y formado por las Islas Cíes, la Isla de Cortegada, la de Sálvora y las de Ons. Las Cíes son el reclamo turístico más usado, por su proximidad a Vigo, son las más publicitadas y las más visitadas. A parte de que se han pasado trescientos pueblos con el último lema 'Islas Cies, A mellor praia do Mundo'. No me cabe duda de que la playa de Rodas es un lugar paradisíaco pero de ahí a ser la mejor del mundo. Viene esto a cuento de que, personalmente, si tengo que elegir una isla para visitar de este parque sin duda elegiré Ons, entre otras cosas porque no está tan explotada turísticamente, y no tendréis que reservar el billete para dentro de unos días que (tratándose de Galicia) vete tu a saber que tiempo hará…

Para llegar a la Isla de Ons hay barcos desde Bueu, Marín, Portonovo, Sanxenxo y Aldán. Si vais desde Vigo os aconsejo coger el barco en Bueu.

Podéis pasar todo el día en la isla, y comer en uno de los tres restaurantes o en plan picnic. O incluso varios días, se alquilan habitaciones y apartamentos, y hay una zona donde se permite la acampada de forma gratuita (máximo 5 días), pero hay que reservar con antelación, pues el número de plazas es limitado.

¿Que hacer en la Isla? A parte de tomar el sol en las numerosas playas. La más bella es la de 'Melide', naturista. Al lado mismo del muelle está la 'das Dornas', y hacia el sur las de 'Area dos Cans', 'Canexol' y 'Pereiró', otra opción es pasear contemplando el paisaje.

Se nos ofrecen varias rutas de senderismo que se pueden hacer por libre o con guía. A destacar la ruta Naturista,  la Ruta del Faro y la Ruta Histórica. Las siguientes fotos son de ésta última. Es una ruta circular de unos 6 Km con poco desnivel y muy poca dificultad, que parte del muelle pasando junto a las playas de 'Area dos Cans', 'Canexol' y 'Pereiró', para llegar al mirador de Fedorentos desde dónde podemos contemplar la Ría de Pontevedra, desde Marín a Cabo Home, Si el día está claro alcanzaremos a ver las Islas Cíes en la boca de la vecina Ría de Vigo, y en primer plano veremos el deshabitado islote de Onza, que junto con otros islotes mucho más pequeños como el de Freitosa y Centolo, forma parte del archipiélago de Ons,

Y regresar por la otra parte de la Isla visitando el precipicio conocido como 'Burato do Inferno' (agujero del infierno),

Y la ensenada de Caniveliñas.

No hay verano si fiestas y no hay fiestas sin fuegos, de los más famosos de mi ciudad son los estos del barrio de Bouzas.

[

[

[

[

En el extremo más occidental de la península del Morrazo (Que separa las rías de Vigo y Pontevedra) en la parroquia de Hío se encuentra el espacio natural de Cabo Home.

En Cabo Home hay una playa a la que se accede por una carretera sin asfaltar, pero que merece la pena recorrer, porque para estar tan cerca de Vigo no está saturada de gente ni siquiera en pleno mes de agosto. Es de esas playas que me gustan que tienen sombra cerca, esta está rodeada por un extenso pinar, Y tiene duchas, vigilancia, y un chiringuito donde tomar un refresco.

Yo como soy más de monte que de playa, dejé a las mujeres tomando el sol y me fui a dar un paseito con la cámara, aunque la verdad es que el sol estába más de playa que de fotos.

Si el cielo está claro hay magníficas vistas de las islas Cies en la ría de Vigo.

Y también de la Isla de Ons en la ría de Pontevedra, es la isla que se vislumbra al fondo en las fotos del faro y del pueblo de Donón.

Después de estar en León tiramos hacia Cantabria, y acampamos en los valles pasiegos, como a Ada le gustan mucho los animales era de Visita obligada el parque de Cabárceno. Es el zoo más extenso que he visitado, Se recorre en coche, Los recintos de los animales son muy muy espaciosos, así que si queréis hacer fotos no os olvidéis el teleobjetivo.

No es que tenga mal el balance de blancos, esta cebra tiene la piel así seguramente de revolcarse en la tierra rojiza por el óxido de hierro que contiene (El parque era una antigua mina de hierro).

Hay muchos bichos con cuernos…

Estos se llaman cobos (Como el director de orquesta  )

Estos Elanes compartían habitat con las jirafas…

Parecen simpáticos este par de elefantes. Había una buena manada, en un recinto muy muy extenso.

¿En que estará pensando?

Estos hipopótamos son pequeñitos pero cuando abren esa bocaza meten miedo…

¿Que tal tiempo hace por las alturas señora jirafa?

Creo que he visto un lindo gatito…

No son focas, son Leones Marinos que hacen un espectáculo muy aplaudido por los niños…

El león enseñando los dientes.

Esta leona era ciega la pobre…

En el recinto de los osos había una gran familia de osos. Los oseznos vistos así jugando hasta parece que dan ganas de cogerlos….

A este le gusta ver el mundo desde lo alto…

Y a este también….

¡Ufff! que calor me apetece un bañito….

¡Que fresquita está!

Yo sé de una que se pasó pipa todo el día viendo animales, era ya la hora de cerrar y todavía quería seguir….

Partiendo de la estación Matallana de Torio hay una ruta fácil para dar un agradable paseo hasta Villafeide, al ladito mismo de Vegacervera, antiguamente era una vía de tren que llevaba carbón desde una mina a la estación de Matallana.

Una fuente de agua fresquita en el camino.

Este puente romano ya lo puse antes en el hilo de las Hoces de Vegacervera, aquí desde otro ángulo.

La iglésia de Villafeide estaba cerrada y no pude ver los dos cráneos humanos que decía un cartel que hay en uno de sus muros.

Si vais a visitarla no olvidéis llevar ropa de abrigo, aunque sea en pleno verano, porque dentro hace fresquito siempre, y calzado cómodo. Dejan hacer fotos, aunque no se puede usar trípode y te piden que no te entretengas demasiado ni te separes del grupo (todas las visitas son guiadas). Tampoco permiten grabar en vídeo, el guía nos explicó en petit comité que era para evitar accidentes, porque la gente suele ir grabando mientras camina mirando a la pantalla.

La cueva es bastante espectacular, hay dos tipos de visita, una más corta que otra, la larga dura unos 90 minutos.

Impresionantes formaciones calizas, algunas tienen formas curiosas que la imaginación de algunos le ha puesto nombres como 'la virgen con el niño', 'el fantasma', 'La columna solitaria'…

En fin un interesante paseo por las 'entrañas de la tierra' de unos dos kilómetros visitando siete salas (o cuatro si escoges la visita reducida).

De las fotos ya sé que me vais a decir que si ruido, que si trepidados, que si falta foco…. y tenéis razón pero a pulso,  sin poder pararte demasiado, y teniendo en cuenta que la iluminación, aunque suficiente para el ojo humano, es bastante escasa, no me quejo de los resultados.

El oro día os puse las fotos de las Hoces de Valdeteja, Hoy le toca el turno a las de Vegacervera. El principal reclamo turístico de esta preciosa zona de León es la cueva de Valporquero, pero la cueva la dejaremos para otro día.

Vegacervera es un pequeño municipio leonés cuyos principales atractivos son los impresionantes valles formados por el río Torio a su paso sobre las rocas calizas.

El pueblo de Vegacervera es un sitio tranquilo, con un bonito paseo fluvial, y un montón de sitios para hacer caminatas, ya pondré fotos de los paseos a pié.

Puentes romanos sobre el río Torio, en el que se puede practicar la pesca…

Alguna 'fauna' del lugar…

Pero lo más sobrecogedor es la montaña…

Y ese impresionante desfiladero por el que pasaremos camino de la cueva de Valporquero.

Este es el calero de Felmín, un horno donde fabricaban cal, y que no tengo muy claro si está en las hoces de Vegacervera o de Valdeteja, pero por el que habreís de pasar si vais de Vegacervara hacia la cueva de Valporquero o hacia Carmenes.

El próximo día pongo la cueva…

Estas vacaciones quería visitar la cueva de Valporquero, así que mi primera escala fué en Las Hoces de Vegacervera (León), nada más llegar, y después de acomodarnos en el camping fui a repostar y el dependiente de la gasolinera me aconsejó visitar una cascada que había en Nocedo de Curueño. Y para allá me fui, eso está en el valle del río Curueño, en las Hoces de Valdeteja, precioso paisaje para perderse con la cámara, vimos carteles de rutas de senderismo que parecían bastante interesantes, pero que no hicimos por falta de tiempo.

Para llegar a la cascada hay que dejar el coche en la carretera y pasear un ratito por entre rocas al lado y a veces sobre un riachuelo sobre el que han construido pasarelas metálicas.

Nos metemos por una grieta en la roca y allí dentro en una chimenea natural en medio de la roca caliza está la curiosa cola de caballo que en primavera, tras las lluvias debe ser impresionante…

Junto con el de Baroña este es uno de los castros más conocidos de Galicia. El castro de Santa Tegra (Santa Tecla) está en A Guarda, para llegar solo teneis que seguir esta ruta en google maps.

Como es bien conocido no voy a abundar demasiado en detalles, que seguro que mejor que contároslos yo podréis consultar en la wikipedia.

Una vista general:

Las construcciones son prácticamente todas circulares, y pequeñas. Muchas tienen una zona anexa delante de la puerta (vestíbulo). En la siguiente foto se aprecia la lareira, esa losa para hacer fuego en el suelo, en el centro de la casa y otra en el vestíbulo colocada a una cierta altura que se supone servía de horno.

Hay un par de casas reconstruidas totalmente:

Lo que más me gusta de estas escapadas, aparte de hacer fotos claro, es lo bien que se lo pasa Ada.

¡Ah! decir que ya que estáis en el castro hay que aprovechar para ver el museo que hay un poco más arriba, la capilla santuario de Santa Tecla, y las impresionantes vistas del estuario del Miño.

En Galicia existen muchos Castros, uno de las más grandes en extensión es el de San Cibrao de Las Está cerca de Orense, en el municipio de San Amaro

Se sabe que se llamaba Lansbricae cotejando el nombre aparecido en una inscripción con documentos de la época. Por lo que he leído este castro es del final de la etapa castreña, y se aprecia la romanización. Yo que aunque no entiendo mucho de esto si que noto que a diferencia de otros castros donde todas las edificaciones son circulares y pequeñas, en este se encuentran muchas de planta rectangular y más amplias, además la muralla que rodea a todo el recinto es más ancha de lo habitual, y transitable. Y las puertas de la muralla están flanqueadas por torreones circulares, cosa que no he visto en ningún otro castro.

En la segunda foto se ve la fuente a la derecha de la entrada:

La muralla es amplia y transitable con escaleras de acceso por la parte interior:

Hay amplias calles entre las edificaciones que posiblemente estuviesen empedradas.

La verdad es que vivían en unas casitas que ríanse ustedes de los mini-pisos de 30metros cuadrados

Esta debía ser una vivienda unifamiliar de lujo, con porche y terreno ajardinado

(Más fotos en el almacén)

En la comarca del Ribeiro, en Leiro, un pueblo a mitad de camino entre Ribadavia y Carballiño, hay una ruta de senderismo de unos 9Km que nos lleva hasta la 'Pena Corneira', un curioso peñasco que debe su nombre a que visto desde cierto ángulo tiene forma de cuerno.

La sierra de Pena Corneira fué declarada el año pasado Monumento Natural por la singularidad de sus formaciones rocosas de granito, (rocas graníticas hercínicas de época postcinematica, dice el decreto  ¿Debería ser pecado poner tantas palabras esdrújulas juntas ?). Sumándose así a otros lugares gallegos como la Carballedaa da Rocha, la Costa de Dexo, la Playa de las Catedrales, la Fraga de los Catasós o los soutos (bosques de castaños) de la Retorta y de Rozabales.

Resulta curioso pasear por entre los enormes bolos de granito que abundan por la zona, igual Tat conoce la zona porque aquí viene mucha gente a practicar Bulder.

La ruta comienza en Leiro, aunque, si como es mi caso, vamos con niños y 9Km de ida y vuelta nos parece excesivo, podemos subir en coche hasta el parque forestal y desde allí podemos seguir la ruta andando hasta la pena Corneira o todavía mejor retroceder un poco y tomar la desviación que nos lleva al mirador de Outeiral ambos tramos son cortitos (1Km más o menos), con bastante desnivel, eso sí.

Casi al lado del parque está la Iglesia románica de Lamas.

Si seguimos un poco podemos ver este cruceiro a la entrada mismo del parque, dónde hay una fuente, mesitas para comer, y barbacoas.

Y después de una comida campestre nada como un paseo entre las rocas para hacer la digestión:

Todo está muy bien indicadito

Y en los pasos difíciles han construído escaleras y pasarelas, así que el recorrido es apto para niños, que puedan andar (Abstenerse si vais con sillas ¡eh!).

Hay que ir con calma, parándonos a contemplar árboles centenarios:

O minúsculas plantas

A veces hay algún claro y podemos asomarnos a ver el paisaje:

Finalmente tras subir unas escaleritas llegamos a lo alto de una de las pelotas rocosas, sobre la que se asienta, un mirador, una cámara de vigilancia, un poste de esos que marcan un vértice geodésico… Un buen sitio para hacer una foto de grupo…

De haber llevado el trípode lo hubiese puesto para sacar la Pena Corneira detrás nuestra, al fondo…

Desde este mirador también vemos una cantera que afea un poco el paisaje… Pero no voy a poner fotos de eso.

En la peninsula del Morrazo , hay una interesante ruta de senderismo que transcurre a lo largo del "Río da Fraga". Este Ríachuelo, como podeis ver en la wikipedia, es el más largo y caudaloso del municipio de Moaña. Tiene varias pozas y un salto de agua. Hay 31 molinos que han sido restaurados e integrados en un paseo, 'a ruta dos muiños' que recorre, en 6 km, parte de sus riberas cubiertas por un frondoso bosque atlántico muy bien conservado. Todavía 3 de sus molinos están en activo.

Fraga, en gallego, es el nombre que se le da a un bosque de árboles mixto, de diversas especies. Enseguida entenderéis el porqué del nombre del río.

La ruta entera son unos 6 Kilómetros, en la primera parte hay varios molinos restaurados. Como hacerla entera era mucho tute para mi hija, decidimos hacer solo la segunda mitad dejando la parte de los molinos para otra ocasión. Si desde moaña subís por la carretera de Pombal (Po-1102) hasta aquí podéis comenzar la ruta en la mitad.

Es una ruta con mucha sombra, y no es difícil.

Empezamos cruzando este puente:

Para seguir casi todo el camino al lado del río:

Y a la sombra de los árboles, algunos de caprichosas formas…

Helechos, musgo, hiedras… tapizan el suelo, las rocas, incluso los árboles…

Hay que hidratarse mientras se camina

Si el suelo está mojado, hay que tener cuidado de no resbalar en las rocas humedas…

Hay algunos troncos caidos sobre el río, da la impresión de que el agua ha reblandecido el terreno en el que se sustentaban sus raíces. Supongo que el musgo, la humedad y los bichitos, acabarán convirtiendo estos troncos en sustrato para que otros árboles puedan seguir creciendo.

El río baja cantarín con un saltito aquí y una poza allá…

Y al final tras una subidita algo más pronunciada.

Encontramos esta pequeña cascada.

Otro día a ver si os pongo la parte de abajo.

La semana pasada, os puse una pizca de los molinos del Folón. Ayer por la tarde visitamos otro grupo de molinos, que hay en Barro, en la carretera de Pontevedra a Caldas de Reis (N550). Se trata del Parque natural del Río Barosa.

Se toma un desvío de la N550, que está bien señalizado, y a unos 500m tenemos que aparcar y continuar a pié, por la orilla del río. Enseguida vemos unos puentes de madera, la cascada y los primeros molinos.

Hay una docena de molinos, algunos restaurados y otros no. La mayoría están en un trecho de unos 400m de fuerte pendiente. Si recorremos este tramo, no nos resultará difícil hacer el resto mucho más llano, en total son unos 4Km subiendo por una margen del río y bajando por la otra para volver al punto de partida.


Antes de llegar a las cascadas el río canta así

En este primer tramo impresiona la fuerza del agua, y más si, como en esta época, hubo abundantes lluvias.

En la parte de las cascadas suena así, y así.

¿Ya mencioné que era un buen sitio para hacer fotos?

Un molino:

Luego el río se vuelve tan calmo, y tranquilo que parece otro.

En esta zona también hay algún molino pero, con el cauce más tranquilo, es necesario hacer presas artificiales y canalizar el agua.

El suave murmullo del agua, el canto de los pájaros, el olor a roble y a musgo, y la luz del sol tamizada por las ramas los árboles, dan una tranquilidad pasmosa, que nos anima a seguir el camino lentamente, como el río, contemplando el reflejo de cada árbol en el agua.

En esta parte del río solo se escuchan los pájaros.

Tras este puente, en el restaurado 'Muiño de Valerio', podemos tomar un tentenpié… o una cervecita antes de seguir camino. Nosotros preferimos hacer primero el recorrido y luego tomar unas tapas en el 'Muiño de Abaixo':

Este sábado pasado, tras las abundatens lluvias de días anteriores estuvo un tiempo espléndido y aprovechamos la tarde para revisitar estos pintorescos molinos.

En la comarca del 'Baixo Miño', en 'O Rosal', teniendo ganas de andar podemos recorrer la ruta de los molinos del Folón y del Picón. Son en total 67 molinos, la mayoría restaurados que están colocados 'en cascada' en la ladera del monte aprovechando el curso del agua. Yo creo que esta concentración de molinos tan próximos en un solo riachuelo es única en el mundo. La ruta hay que hacerla a pie y es de dificultad media, se puede hacer toda de un tirón, partiendo del puente 'das Penas'. El sendero está perfectamente marcado. Se recomienda comenzar por el grupo de los Muíños do Folón que ya nos orientan el camino hasta el que se encuentra en el lugar más elevado. Una vez aquí, podemos coger hacia la izquierda, visitando, entonces, la ermita de San Martiño o coger a la derecha, bajando por el Camino de Carro, así llamado por las marcas que sus ruedas tallaron sobre la roca granítica. Este Camiño do Carro nos llevará al grupo de los Muíños do Picón. Desde donde podemos regresar por la carretera hasta el punto de partida en 'A Ponte das Penas'. Decir que desde "O rosal'', la carretera hasta el principio de la ruta también está muy bien señalizada.

Peo no me enrollo más con literatura y pongo las fotos, que no hacen justicia al paisaje. Hay que verlo, olerlo y oirlo.

Aquí comienza la ruta, hay carteles con explicaciones, y fotos del recorrido, y luego solo hay que seguir las típicas marcas amarillas y blancas, perfectamente visibles que nos iremos encontrando. Y algún que otro cartel con más fotos, mapas, e información en ciertos puntos de interés.

El agua está presente en todo el camino pudiendo complicarlo un poco en algunos puntos, sobre todo si hubo abundantes lluvias y vamos con niños, ya que en algunos casos habrá que cruzar un arroyo saltando de roca en roca.

Ni el sonido del agua ni el aroma a eucalipto se pueden plasmar en las fotos, pero intentaré al menos poner el color amarillo de las flores de la retama.

Y en cuanto a los molinos, pues irémos encontrándolos a lo largo del camino mas dispersos al principio y más juntitos cuanto más arriba vamos subiendo y más pronunciada se vuelve la pendiente:

En fin una ruta aconsejable para relajarse.

Hace unos meses, os hablaba de la feria del Aceite de Quiroga en la que no pude sacar fotos de la almazara, bueno ya comenté que en esa zona prefieren llamarles 'Molinos' ¿como en Jaén?.

Todavía no tuve ocasión de hablar con el dueño para que me dejase hacer fotos, pero como lo prometido es deuda, el sábado pasado visité las ruinas de otra que hay en mi pueblo.

Se llega al molino dando un placentero paseo, y hacía un estupendo día para ello:

Como veis el molino, inicialmente de piedra de mampostería y con techo de pizarra, sufrió una burda reforma, a base de ladrillo y uralita, hará unos veinte años. Hoy está totalmente abandonado. Por la parte derecha, aunque no se ve en la foto, la pared y parte del techo están derrumbados.

Nos asomamos a la puerta:

En el interior, contra lo que cabía esperar, la muela y la prensa, se conservan en bastante buen estado.

Esta es la muela: En la pila que se ve al fondo se vaciaban los sacos de aceituna y tras una selección para retirar hojas o granos en mal estado se vaciaban en la tolva de madera de la muela, a cuyo mástil se enganchaba un borrico o una mula, que dando vueltas sin cesar iba machacando la aceituna.

La aceituna machacada se pasaba a los 'Capachos', estos discos de esparto, para luego ser prensada:

La prensa es una sencilla palanca de segundo género, una enorme viga con un huso y un peso en un extremo. Y cerca del otro, dónde está el punto de apoyo se colocaban apilados los capachos, rellenos con las olivas previamente machacadas en la muela, y sobre ellos una tapa redonda y unos maderos, hasta llegar a la viga. Al apretar el huso la fuerza de la gravedad y el peso de la piedra hacen el resto. Se ayuda a la extracción del 'oro líquido' echando agua caliente que luego se separa fácilmente, dejandolo decantar en un recipiente, ya que el aceite por su menor densidad flota en el agua.

Aquí vemos la prensa, que es esa viga que hay detrás de mi mujer y mi hija, y de esa horrible columna de ladrillos que sujeta el techo.

Un detalle del huso y del contrapeso:

Y al fondo se ve la otra parte de la prensa, con un capacho, y el caño por el que sale el aceite, hacia el recipiente donde se decanta:

¡Ah! por lo que me cuentan, estos molinos, al igual que los de grano, eran de maquila. Todos los vecinos llevaban allí su molienda, y el dueño del molino cobraba en especies, es decir se quedaba una parte del aceite por el trabajo.

Silleda es conocida por su ganadería, por su buena carne, y por la celebración de esa feria anual que llaman 'La semana Verde' muy cerquita de Silleda pasa el río Toxa, y si algo hay que ver de ese río es su cascada. Si queréis visitarla solo hay que acercarse al pueblo y preguntar, especialmente ahora que están con las obras del AVE de Orense a Santiago, y el acceso habitual está cortado y hay que dar un rodeo que no está señalizado.

Se puede llegar con el coche prácticamente hasta la cascada, pero personalmente aconsejo dejarlo junto a este cartelito y hacer el resto del recorrido a pié.

Si vamos hacia arriba llegaremos a este mirador:

Desde él se puede ver la cascada desde arriba:

Desde allí hice esta panorámica desde la que además de la cascada se pueden ver los pilares de lo que será un viaducto del AVE Ourense-Santiago, que esperemos que no destroce demasiado el entorno:

De vuelta al cartel pero esta vez bajamos por un serpenteante camino entre árboles:

Y llegamos a la poza:

Veo que no soy el único que ha decidido hacer fotos a la cascada. ¿No querrá presentar la foto al juego del mes de fotolibre?

Por cierto al lado de la cascada mismo hay unas mesitas de piedra por si quereis llevaros la merienda y comerla cómodamente sentados. Yo busqué una posición un poco más complicada para hacer la foto desde encima de las rocas que hay en medio del cauce, mientras colocaba el trípode Belén me pilló con su cámara…

Desde allí hice tres tomas para luego montar esta ¿Panorámica vertical? que presenté al juego del mes de Marzo:

La ganadería fue una práctica del hombre en la prehistoria, y con la necesidad de contar el ganado surgió el cálculo. La palabra cálculo en si proviene del latín ‘calculus’, piedra pequeña. Se dice que para contar el ganado se usaban inicialmente piedrecitas, por cada cabeza de ganado que salía a pastar se guardaba una piedra, y cuando la res volvía al redil se tiraba una de las piedras guardadas. Cuando ya no quedaban más piedras todos los animales estaban a buen recaudo.


Las cosas han cambiado mucho pero nuestra necesidad de ‘contar’ sigue ahí, solo que ahora los métodos son algo más sofisticados. Bash puede manejar números enteros y realizar con ellos operaciones aritméticas simples (o no tanto). Bash no maneja números reales, sólo enteros

let

El comando (interno) let se utiliza básicamente para realizar operaciones aritméticas simples y generalmente asignar el resultado a una variable, de esta forma:

$ let a=3+2
$ echo $a
5
$ let b=a+1 c=b+2
$ echo $a $b $c
5 6 8

En cada comando let se pueden evaluar varias expresiones. Cada expresión tiene que ser una sola palabra, si se dejan espacios hay que entrecomillarlos.

$ let "a = 3 + 2" "b = a + 1"
$ echo $a $b
5 6

Fíjate que en las expresiones puede haber nombres de variables, que siempre se evaluarán como el valor de esta variable. No es necesario que se utilice la expansión de parámetros del bash ($variable o ${variable}) para que la variable se sustituya por su valor, pero en caso de usarla hay que tener en cuenta que la expansión se hace de forma previa a la evaluación.

$ a=5
$ let a=a+1 b=a*2
$ echo $a $b
6 12

Cuando se evalúa la segunda expresión la variable a contiene el valor modificado por la primera expresión, en cambio si usamos la expansión de parámetros de bash, primero se expanden todas las $a por su valor que es 5 y luego se evalúan las expresiones:

$ a=5
$ let a=$a+1 b=$a*2
$ echo $a $b
6 10

Asignación de valores

La asignación de valores en let se hace de forma similar a la asignación de variables normales, indicando un nombre de variable seguida de un signo igual y de una exporesión, se asigna el valor de esa expresión a la variable. Con valores simples no es necesario el let:

$ a=5
$ echo $a
5
$ let a=5
$ echo $a
5

Pero si queremos que se evalúen las expresiones es necesario poner el let:

$ a=8**2
echo $a
8**2
$ let a=8**2
echo $a
64

Operaciones aritméticas

Let puede realizar las siguientes operaciones aritméticas:

• + Suma
• - Resta
• * Producto
• / División entera
• % Resto de la división entera
• ** Potencia

Ejemplo:

$ let X=3+2 Y=4*7 RESTO=7%2 DIV=345/6 CUADRADO=5**2
$ echo $X $Y $RESTO $DIV $CUADRADO
5 28 1 57 25

Modificación del valor de una variable in situ (Asignación compuesta)

Cuando necesitamos modificar el valor de una variable realizando cierta operación con él, en la mayoría de los lenguajes debemos recurrir a asignar a dicha variable el resultado de una expresión en la que interviene la propia variable. Por ejemplo si queremos sumar 4 al valor que tenía X debemos poner ‘let X=X+4′, esa expresión es matemáticamente un absurdo, pero en lenguaje informático quiere decir, ‘asigna a X el valor resultante de sumar 4 a su antiguo valor’. En bash podemos hacerlo así, pero además existe una forma abreviada, que os sonará a aquellos que habéis programado en C, o en php: X+=4. El operador += es un operador de asignación igual que el = y por tanto tiene que ir a continuación de una variable, y se usa para sumar a dicha variable el operando que viene a continuación del operador, dejando el resultado en la misma variable, digamos que es como ‘sumar in situ’.

$ X=3
$ let X+=3
$ echo $X
6

Con el resto de operaciones aritméticas tenemos operadores de asignación compuesta similares:

• Var+=Expr Sumar in situ
• Var-=Expr Restar in situ
• Var*=Expr Multiplicar in situ
• Var/=Expr Dividir in situ
• Var%=Expr Resto de división in situ

Preincremento, predecremento, postincremento y postdecremento

Para sumar una unidad a una variable (X=X+1) podemos usar el operador ++. Poner X++ o ++X es aproximadamente lo mismo que poner X+=1 y es más corto. La diferencia es que X++ ó ++X puede funcionar además como operando. X++ devuelve el valor de X antes de ser incrementada y ++X devuelve el valor después de ser incrementado. Veamos ejemplos:

$ let A=5 A++
$ echo $A
6
$ let X=A++
$ echo $X $A
6 7
$ let X=++A
$ echo $X $A
8 8

A estos operadores se les suele llamar postincremento (Var++) y preincremento (++Var), y para no ser menos también existen el postdecremento (Var–) y el predecremento (–Var) que son lo mismito pero restan 1 en vez de sumarlo, simple ¿no?.

Comparaciones

Aunque no suele usarse mucho let, además de para asignar valores a variables también se puede usar para hacer comparaciones, que devuelven cierto o falso. Tal que así:


$let "4>5" ; echo "Resultado=$? (0=Cierto, 1=Falso)"


Las operaciones de comparación admitidas son:

• == Igual
• != Distinto
• > Mayor que
• < Menor que
• >= Mayor o igual que
• <= Menor o igual que

Con ya esto podemos construir expresiones condicionales. Aunque más adelante veremos como evaluar expresiones condicionales de otra forma que se usa bastante más que let.


read -p "Cuantos años tienes:" edad; let "edad>=18" && echo "Que bien, ya puedes votar";\
let "edad<30" && echo "Eres un chaval"


Fijaros que siempre que haya un símbolo de > o < hay que escaparlo, o mejor todavía entrecomillar la expresión para que bash no interprete el símbolo como una redirección.

Varias comparaciones pueden asociarse mediante los operadores lógicos:

• && And
• || Or
• ! Not

Lógica booleana y operaciones de bits

Y además de las comparaciones y las operaciones aritméticas let permite hacer una serie de operaciones booleanas. Hay que tener en cuenta que al fin y al cabo todos los números para el ordenador son binarios, y estas operaciones funcionan a nivel de bits. No quiero profundizar en aritmética booleana, pero si quiero citar las operaciones posibles:

• & And a nivel de bits (Producto booleano)
• | Or a nivel de bits (Suma booleana)
• ^ Or exclusivo a nivel de bits
• ~ Negación a nivel de bits
• >> Desplazamiento de bits a la izquierda
• << Desplazamiento de bits a la derecha

Otra forma de escribir let

Encerrar una expresión entre doble paréntesis es exactamente lo mismo que usar el comando let con la ventaja de que el doble paréntesis ya actúa como delimitador de la expresión y no es necesario el escapado o entrecomillado que casi siempre necesitaremos con let. Veámos como sería con el ejemplo anterior:


read -p "Cuantos años tienes:" edad; ((edad>=18)) && echo "Que bien, ya puedes votar";\
((edad<30)) && echo "Eres un chaval"


Sustitución aritmética

En una orden aparece una expresión aritmética encerrada en doble paréntesis la precedemos de un signo de $ se evaluará la expresión y se sustituirá toda ella por su resultado previamente a la ejecución de la orden, de manera similar a como se sustituyen las variables por su valor.

$ echo $((3 + 2))
5


Variables enteras

Básicamente bash permite almacenar números en variables, si una variable contiene un número puede tratarse como tal, y hacer operaciones con el. Si se intenta hacer una operación aritmética en la que intervenga como operador una variable que no contenga un número entero válido se considerará que contiene un cero. Se pueden declarar las variables como enteras pero no es obligatorio hacerlo. Al declarar una variable como entera solo podrá contener números, el intento de asignarle cualquier cosa que no sea un número entero asignará el valor cero, pero no dará error.
$ VAR1=hola
$ declare -i VAR2
$ VAR2=hola
$ echo $VAR1 $VAR2
hola 0

]]> http://redy.fotolibre.net/2008/03/26/curso-de-bash-para-fotografos-linuxeros-10-aritmetica-sencilla/feed/ 0 http://redy.fotolibre.net/2008/03/25/las-medulas-una-vez-mas/ http://redy.fotolibre.net/2008/03/25/las-medulas-una-vez-mas/#comments Tue, 25 Mar 2008 20:56:22 +0000 Redy http://redy.fotolibre.net/fotolibre/las-medulas-una-vez-mas/ Después de visitar As Ermidas, teníamos intención de subir a Manzaneda, pero en vista de que no había ni pizca de nieve, preferimos cambiar de ruta y nos acercamos hasta las Médulas. Desde 'O barco' fuimos por la OU-536 en lugar de por la N-120 la carretera es bastante más retorcida, pero el paisaje es Seguir leyendo «Las Médulas (Una vez más)»
]]>


Después de visitar As Ermidas, teníamos intención de subir a Manzaneda, pero en vista de que no había ni pizca de nieve, preferimos cambiar de ruta y nos acercamos hasta las Médulas. Desde 'O barco' fuimos por la OU-536 en lugar de por la N-120 la carretera es bastante más retorcida, pero el paisaje es mucho más bonito (Pero el que conduzca que no se despiste mucho contemplándolo ¡Eh!).

Del pintoresco paisaje de Las Médulas, que decir que no se haya dicho ya, solo pongo las fotos.























]]> http://redy.fotolibre.net/2008/03/25/las-medulas-una-vez-mas/feed/ 0 http://redy.fotolibre.net/2008/03/25/as-ermidas-un-pueblecito-orensano/ http://redy.fotolibre.net/2008/03/25/as-ermidas-un-pueblecito-orensano/#comments Tue, 25 Mar 2008 20:53:23 +0000 Redy http://redy.fotolibre.net/fotolibre/as-ermidas-un-pueblecito-orensano/ Aprovechando el puente, este viernes santo me acerqué hasta un pueblo de Ourense, de rancia tradición religiosa. En este escondido y casi abandonado pueblecito está el Santuario de 'Nosa Señora das Ermidas', monumento de interés cultural. El pueblo está en la zona de Trives, cerca de Manzaneda, concretamente en el municipio de 'O Bolo'. A Seguir leyendo «As Ermidas: un pueblecito Orensano»
]]>


Aprovechando el puente, este viernes santo me acerqué hasta un pueblo de Ourense, de rancia tradición religiosa. En este escondido y casi abandonado pueblecito está el Santuario de 'Nosa Señora das Ermidas', monumento de interés cultural. El pueblo está en la zona de Trives, cerca de Manzaneda, concretamente en el municipio de 'O Bolo'.

A parte del tema religioso que convoca a mucha gente en las procesiones que celebran en semana santa, merece la pena acercarse a contemplar el paisaje, desde los miradores que lo rodean: 'A cruz de Santa Cruz', 'Outar de Pregos'  y a recorrer las empinadas cuestas del pueblo (haciendo o no el viacrucis, al gusto de cada cual).

Un par de panorámicas del valle:


Entre las escalonadas viñas y olivares que bordean el valle podemos ver el pueblo en la ladera y abajo de todo casi junto al río el Santuario.


Otra panorámica desde lo alto del pueblo.




Llegamos al pueblo y empezamos a bajar hacia el santuario.





El Santuario es una construcción barroca del siglo XVIII que como dije fue declarado Bien de Interés Cultural en la categoría de Monumentos.













El interior del santuario:





Una escena del Viacrucis que hay en pequeñas capillitas a lo largo del pueblo:



La procesión:





]]> http://redy.fotolibre.net/2008/03/25/as-ermidas-un-pueblecito-orensano/feed/ 0 http://redy.fotolibre.net/2008/02/25/aceite-de-galicia/ http://redy.fotolibre.net/2008/02/25/aceite-de-galicia/#comments Mon, 25 Feb 2008 18:34:06 +0000 Redy http://redy.fotolibre.net/fotolibre/aceite-de-galicia/ Muy poca gente conoce que hay una pequeña zona en Galicia en la que se sigue cultivando y elaborando aceite de forma totalmente tradicional y artesana. En mi pueblo natal (Vilaster) la almazara (bueno allí prefieren llamarle 'o muiño': el molino), está en ruinas, pero en un pueblo muy cercano (Bendilló) todavía se conserva en Seguir leyendo «Aceite de Galicia»
]]>


Muy poca gente conoce que hay una pequeña zona en Galicia en la que se sigue cultivando y elaborando aceite de forma totalmente tradicional y artesana.

En mi pueblo natal (Vilaster) la almazara (bueno allí prefieren llamarle 'o muiño': el molino), está en ruinas, pero en un pueblo muy cercano (Bendilló) todavía se conserva en muy buen estado, y desde un tiempo a esta parte celebran una feria del aceite y de productos artesanales, todos los años.

Cualquiera diría que esta foto tiene más de medio siglo, y es del fin de semana pasado:



En estos pueblos casi abandonados todavía queda gente que se dedica a la cría de ganado de forma tradicional.

Mario, por ejemplo cría bueyes, parece algo absurdo hoy que estos animales han sido sustituidos por maquinaria en las labores del campo. Pero en Euskadi se siguen celebrando 'Tiradas de bueyes', Mario ha vendido varias parejas de sus mejores ejemplares para ese deporte.





Por supuesto me dejaron posar frente a los bichos…



No hice fotos de la Almazara, porque con tanta gente como había resultaba imposible sacar algo decente. Pero otro día que no haya feria tendré que volver para sacar fotos del interior, y que veáis como se hace el aceite gallego.







Nota 05/03/2008: La Voz de Galicia publicó la semana pasada un artículo sobre los bueyes de Mario

]]> http://redy.fotolibre.net/2008/02/25/aceite-de-galicia/feed/ 0 http://redy.fotolibre.net/2008/01/08/curso-de-bash-para-fotografos-linuxeros-9-la-fontaneria/ http://redy.fotolibre.net/2008/01/08/curso-de-bash-para-fotografos-linuxeros-9-la-fontaneria/#comments Tue, 08 Jan 2008 12:56:52 +0000 Redy http://redy.fotolibre.net/fotolibre/curso-de-bash-para-fotografos-linuxeros-9-la-fontaneria/ Concepto de entradas y salidas Titulo el artículo ‘La fontanería’, porque vamos a hablar de streams (esta palabra en inglés significa arroyo, o corriente de agua), pero en informática es un flujo de datos, y de eso vamos a hablar de como fluyen los datos entrando y saliendo de los programas y de como podemos Seguir leyendo «Curso de bash para fotógrafos linuxeros. (9) La Fontanería»
]]>



Concepto de entradas y salidas

Titulo el artículo ‘La fontanería’, porque vamos a hablar de streams (esta palabra en inglés significa arroyo, o corriente de agua), pero en informática es un flujo de datos, y de eso vamos a hablar de como fluyen los datos entrando y saliendo de los programas y de como podemos canalizarlos.

Esto no es algo propio de la shell bash, es algo inherente a Linux, y a cualquier Unix en general, no se puede entender un sistema operativo tipo Unix sin entender una de sus principales características, el ‘stream‘. Un stream es un canal de entrada-salida de datos. Cada proceso en Linux para comunicarse con el exterior dispone al menos de tres streams, llamados stdin (entrada estándar), stdout (salida estándar) y stderr (salida de errores), veámoslo con más detalle.

Todo proceso se comunica con el exterior en dos posibles direcciones: puede leer datos y escribir datos, y dispone como mínimo de un canal (stream) por el que puede leer datos y dos por los que puede escribir. Al canal por el que lee se le llama ‘la entrada estándar (stdin)’. Normalmente ese canal está conectado a la consola de modo que lee lo que tecleamos. Los canales por los que escribe duelen ser dos, de modo que si necesita dar una información estándar suele escribirla por el canal que denominamos ‘la salida estándar (stdout)’, si lo que tiene es que dar información de un error lo hará por ‘la salida de error (stderr)’. Habitualmente tanto la salida estándar como la salida de error están conectadas a la consola, por lo que en principio veremos ambas por pantalla sin distinguir una de la otra. Lo bueno de todo esto es que tanto los streams de entrada como los de salida los podemos ‘enchufar’ a dónde queramos. Si enchufamos un stream de salida a un fichero no veremos la salida por pantalla sino que quedará grabada en ese fichero, y si conectamos un fichero a un stream de entrada cuando el programa espere que le tecleemos algo, en lugar de leer de teclado leerá de ese fichero. Muy útil para automatizar tareas que esperan que le tecleemos algo.

Para que veáis que existen dos salidas vamos a probar lo siguiente aunque no lo entendáis de momento.

$ cd ~/ejercicios_curso_bash
$ ls fichero_que_no_existe
ls: fichero_que_no_existe: No existe el fichero o el directorio

Ahora creamos un fichero y hacemos lo mismo.

$ touch fichero_que_existe
$ ls fichero_que_existe
fichero_que_existe

Aparentemente en ambos casos el programa ls nos da la información de error o la que le pedimos por la pantalla, pero en realidad lo hace por dos caminos distintos: si le decimos que redirija su salida estándar hacia ninguna parte (o sea hacia /dev/null), en el primer caso seguimos obteniendo el mensaje en pantalla pero en el segundo caso no vemos nada.

$ ls fichero_que_no_existe >/dev/null
ls: fichero_que_no_existe: No existe el fichero o el directorio
$ ls fichero_que_existe >/dev/null

Y si lo que redirigimos es la salida de error hacia ninguna parte ocurrirá al revés:

$ ls fichero_que_no_existe 2>/dev/null

$ ls fichero_que_existe 2>/dev/null
fichero_que_existe

El comando ls, aunque dispone de ella, normalmente no hace uso de la entrada estándar, nos da la información necesaria por la salida que corresponda, pero no espera recibir ninguna información del exterior. Veamos otro caso que sí espera información de la entrada estándar.

$ rm -i fichero_que_existe
 rm: ¿borrar `fichero_que_existe'? (s/n)

Vamos a contestarle que no, no queremos borrarlo de momento, cuando tecleamos la n y damos intro, lo que hacemos es poner esos datos en la entrada estándar del programa, ya que la entrada estándar está conectada a la consola. Ricemos un poco el rizo: primero escribiremos una ‘y’ y una ‘n’ en sendos ficheros, y luego usaremos la orden rm conectando la entrada estándar a esos ficheros en vez de a la consola:

$ echo y >contesta_que_si
$ echo n >contesta_que_no
$ rm -iv fichero_que_existe <contesta_que_no  rm: ¿borrar `fichero_que_existe'? (s/n)

Vemos que rm pregunta, pero no espera a que le contestemos, ha leído la ‘n’ del fichero, y no ha borrado nada, en cambio si tecleamos

$ rm -iv fichero_que_existe <contesta_que_si rm: ¿borrar `fichero_que_existe'? (s/n)
borrando fichero_que_existe

El fichero se borra como cabía esperar.

Hasta aquí lo único que me interesa que te haya quedado claro es que todo programa tiene por defecto una entrada de la que puede leer datos y dos salidas en las que puede escribir, y que esas entradas y salidas que normalmente están conectadas a la consola se pueden redirigir.

Esto es lo interesante, todos los streams pueden conectarse a archivos, a dispositivos, o unos con otros.

Redirigiendo las salidas.

Para redirigir la salida estándar a otro fichero o dispositivo usaremos un signo de mayor (que opcionalmente puede estar precedido del número 1, el 1 indica la salida estándar y el 2 la salida de error, si no se pone ningún número se entiende que nos estamos refiriendo a la salida estándar). Si redirigimos la salida hacia un fichero existente lo sobreescribiremos con la nueva información borrándose su contenido anterior. Si no queremos que se sobrescriba, si no que se añada al final usaremos dos signos de mayor en vez de uno, por ejemplo.

$ echo Esto se va a sobreescribir >fichero_de_prueba
$ echo esto es una prueba 1>fichero_de_prueba
$ echo a la que le añadimos una línea >>fichero_de_prueba
$ echo y luego otra >>fichero_de_prueba
$ cat fichero_de_prueba
esto es una prueba
a la que le añadimos una línea
y luego otra

Para redirigir la salida de error es más o menos lo mismo, solo que en vez de poner el 1 (o no poner nada) pondremos un 2

$ ls fichero_que_no_existe 2>fichero_de_prueba
$ ls fichero_que_tampoco_existe 2>>fichero_de_prueba
$ cat fichero_de_prueba
ls: fichero_que_no_existe: No existe el fichero o el directorio
ls: fichero_que_tampoco_existe: No existe el fichero o el directorio

Si queremos redirigir ambas salidas hacia ficheros distintos podemos hacerlo, por ejemplo:

$ ls contesta_q* fichero_no_existe 1>fichero_de_prueba 2>fichero_de_error
$ cat fichero_de_prueba
contesta_que_no
contesta_que_si
$ cat fichero_de_error
ls: fichero_no_existe: No existe el fichero o el directorio

Incluso podemos redirigir ambas hacia el mismo fichero, para hacer esto podemos poner

$ ls contesta_q* fichero_no_existe 1>fichero_de_prueba 2>fichero_de_prueba 

O podemos usar esta forma simplificada que significa ‘redirige la salida estándar hacia un fichero, y la salida de error al mismo sitio que la estándar’.

$ ls contesta_q* fichero_no_existe 1>fichero_de_prueba 2>&1

Observa que el orden de las redirecciones es significativo. Por ejemplo, la orden

$ ls > fichero_de_prueba 2>&1

dirige ambas, la salida estándar y la de errores, al fichero_de_prueba, mientras que la orden

$ ls 2>&1 > fichero_de_prueba

dirige solamente la salida estándar al fichero_de_prueba, porque la salida de errores estándar se ha duplicado como salida estándar antes de que ésta se redirigiera al fichero.

Para los que somos vagos escribiendo decir que hay una forma más breve de poner ‘comando >fichero 2>&1′ que es ‘comando &>fichero’

Aunque no suele hacerse, quizá porque no queda muy claro; hay que decir que los signos de redirección pueden ponerse antes o después del comando, como se quiera. Así que es lo mismo poner…

$ >fichero_de_prueba echo hola

que…

$ echo hola >fichero de prueba

Redirigiendo la entrada:

Ya hemos visto algún ejemplo, contestando que si o que no al rm, para redirigir la entrada, y hacer que el programa lea los datos que espera desde un fichero u otro dispositivo usaremos el signo de menor, hay que asegurarse de que de donde leemos hay suficientes datos, por ejemplo si hacemos

$ rm -iv fichero_de* <contesta_que_si
rm: ¿borrar `fichero_de_error'? (s/n)
borrando fichero_de_error
rm: ¿borrar `fichero_de_prueba'? (s/n)

Se borra el primer fichero, pero no el segundo, porque en el fichero contesta_que_si solo hay una ‘y’

Muy usado en scripts es la redirección que los anglosajones llaman here-document y que no sé como traducir, algo así como redirigir de aqui mismo. Para ver un ejemplo, ¿conoceis el comando mail? Además de ser usado para leer el correo si tecleas ‘mail usuario’ o ‘mail usuario@host.dom’ permite mandar correo a otros usuarios de nuestra máquina o a cualquier cuenta de correo del mundo si tenemos bien configurado el MTA. Lo normal es que pongamos mail y el usuario al que queremos enviar el mensaje y luego comenzamos a teclear, primero el asunto y a continuación el texto. Pulsamos Control-D cuando acabamos.


mail usuario@gmail.com
subjet: Hola. Me acabo de comprar una cámara nueva
Me he comprado la nueva Olimpius 3-E y no sabes que pedazo
de fotos hace. Es una pasada de cámara.
Estoy como un niño con zapatos nuevos.

<aquí pulso Control-D>

Si quisieramos automatizar el envío de mensajes podríamos grabar el subject y el texto en un fichero y luego ejecutar:

mail usuario@gmail.com <fichero-mensaje

Pero en un script seguramente queda mejor así:

#! /bin/bash
#
# Ejemplo de redirección here-document
#
mail $1 < <FIN_DE_MENSAJE && echo "Mensaje navideño enviado correctamete a $1"
Felices fiestas
Os deseo una Feliz Navidad
Y un próspero año nuevo
FIN_DE_MENSAJE
# Ahora podríamos seguir poniendo comandos de bash si fuera necesario.
# La redirección terminó en la línea que contiene la palabra FIN_DE_MENSAJE

Estamos usando la redirección here-document fijaros que en lugar de un único signo < ponemos dos consecutivos y sin espacios en medio y a continuación una palabra (Que no esté en el texto que queremos redirigir). Todo el texto que aparezca en las siguientes líneas, hasta encontrar una línea que contenga únicamente la palabra en cuestión, se pondrá en la entrada estándar del comando, tal como si lo hubiésemos redirigido de un fichero. Si queremos ponerlo más bonito podemos indentar el texto usando tabuladores al principio de la línea (nunca espacios) y en lugar de poner

comando <<PALABRA

ponemos la palabra precedida de un signo menos, así

comando <<-PALABRA

eso hará que todos los tabuladores al principio de línea se quiten mientras se van inyectando las líneas en la entrada estándar del proceso.

Otra forma parecida de redirección de entrada es usar tres signos de menor <<< seguidos de una palabra, en ese caso la palabra se expande primero aplicando las reglas de expansión de bash y su resultado se inyecta en la entrada. Con esto podríamos por ejemplo almacenar un texto en una variable y usarlo para inyectar ese texto en la entrada estándar de un proceso.

Tuberías, o como encadenar la salida del uno con la entrada del otro.

Hemos visto como redirigir las entradas y las salidas a ficheros, pero es
más interesante ejecutar varios comandos en tubería, de forma que la salida
de uno se use como entrada del otro. Por ejemplo, el comando yes envía a su
salida sucesivas letras 'y' sin parar. Si hacemos

$ yes | rm -iv fichero_de_* contesta_que_*

Estaremos redirigiendo la salida estándar del comando yes a la entrada estándar del comando rm, con lo cual cada vez que rm pregunte si estás seguro de que quieres borrar el fichero, tendrá una 'y' en su entrada estandar.

Ahora usaremos algunos comandos nuevos, pero no los voy a explicar a fondo. Ya los veremos con más detalle a medida que vaya avanzando el curso. Del comando ps ya hablamos cuando explicabamos la gstión de procesos, y el comando grep busca y presenta las líneas que contengan una palabra o expresión (o que no la contengan si usamos la opción -v).

Supongamos que queremos buscar todos los procesos del usuario 'nobody' en la lista de procesos, podríamos redirigir la salida de 'ps axu' hacia un fichero y luego buscar con grep en ese fichero la palabra 'nobody', pero es mucho más sencillo hacer

$ ps axu | grep nobody
nobody 30631 SW Nov03 0:00 [httpd]
nobody 30632 SW Nov03 0:00 [httpd]
nobody 30633 SW Nov03 0:00 [httpd]
nobody 30634 SW Nov03 0:00 [httpd]
redy 15299 S 18:40 0:00 grep nobody

Uyyyy! casi, el último no me interesaba sacarlo, ya que en realidad no es de nobody, aunque aparece dicha palabra, no importa, me viene al pelo para que veáis que todavía puedo seguir encadenado salidas con entradas:

$ ps axu | grep nobody | grep -v "grep nobody"
nobody 30631 SW Nov03 0:00 [httpd]
nobody 30632 SW Nov03 0:00 [httpd]
nobody 30633 SW Nov03 0:00 [httpd]
nobody 30634 SW Nov03 0:00 [httpd]

Así ya está mejor....

El signo '|' (tubería) lo que hace es encadenar varios procesos que se ejecutan simultaneamente, de manera parecida a como lo hacíamos con el signo '&' pero además la salida estándar del primero se conecta a la entrada estándar del segundo, digamos que el segundo comando actúa como un filtro de la salida del primero.

El primer comando de una secuencia de ellos unidos por tuberías se ejecuta en la shell actual, pero los subsiguientes se ejecutan en subshells distintas cada una hija de la anterior.

Algunos comandos que suelen actuar como filtros

Hemos visto como redirigir las entradas y salidas encaminando el flujo de información de ficheros a procesos, de procesos a ficheros, y entre procesos tal como se nos antoje. Ahora es el momento de estudiar algunos comandos que por su peculiar modo de comportarse son especialmente útiles usados de este modo, canalizan los streams, haciendo alguna operación con la información, por ello se dice que actúan a modo de filtros. Hay que decir que no tienen ninguna característica especial, en cuanto al modo de programarlos, quiero decir que no son distintos a otros comandos, cualquier comando interno o cualquier programa puede funcionar como filtro, solo tiene que hacer algo con la información que recibe por la entrada estándar, y enviar el resultado a una de sus salidas, normalmente la salida estándar.

Un filtro que ya vimos es 'grep', grep coge líneas de la entrada
estándar, o de uno o varios ficheros, y muestra en la salida estándar
solamente aquellas líneas que contienen una determinada expresión. Pruébalo,
pon

$ grep hola

Ahora teclea frases y verás como las que contengan la cadena 'hola' las repite. Cuando te canses pulsa <ctl>D para indicarle que has terminado, es el carácter que representa el final de fichero, o del flujo de información. Es muy útil para buscar lo que nos interesa en un fichero o en un programa que muestra mucha información.

Por ejemplo si usas 'ls --help' se te muestran muchísimas opciones, pero nos interesa conocer solo las que guardan relación con la ordenación, podemos hacer:

$ ls --help | grep ordena
-c ordena por la fecha de modificación (ctime);
-f no ordena, utiliza -aU, no utiliza -lst
-r, --reverse invierte el orden, en su caso
-S ordena los ficheros por tamaño
-t ordena por la fecha de modificación
-u ordena por la fecha de último acceso (atime)
-U no ordena; muestra las entradas en el orden
-v ordena por versión
-X ordena alfabéticamente por la extensión de

y así solo veremos las líneas que contienen 'ordena'. Otros dos filtros útiles son more y less. More muestra la información que cabe en pantalla y hace una pausa hasta que pulsamos espacio, luego continúa, pruébalo. Less hace lo mismo pero nos permite avanzar o retroceder con las flechas (pulsa q para salir). Pruébalos:

$ ls --help |more
$ ls --help |less

ls lista los archivos pero no nos dice cuantos hay. No hay problema hay un filtro que cuenta las líneas, es wc, en realidad cuenta líneas, palabras y caracteres, pero lo único que nos interesa en este caso es contar líneas, ya que se muestra un fichero en cada línea.

$ ls |wc -l

Otro comando interesante es nl que numera las líneas que recibe por la entrada estándar, prueba

$ ls |nl

Los comandos tail y head, muestran sólo las últimas o las primeras líneas de un archivo o de la entrada estándar si no se especifica el número de líneas muestran 10, pero pueden especificarse con la opción -n. Prueba por ejemplo:

$ ls --help |nl -ba |head -n 6
$ ls --help |nl -ba |tail -n 12

No os explico todas las opciones de estos comandos, porque eso ya no es parte de bash, además el curso se alargaría demasiado. Hay un proverbio que dice aquello de que si te doy un pez comerás hoy, y si te enseño a pescar comerás muchos días. Pues te voy a enseñar a pescar, es decir a usar el comando man, si necesitas saber más sobre cualquier comando como por ejemplo sobre el wc usa

$ man wc

También puedes ver una breve ayuda de de la mayoría de los comandos comando usándolo con el argumento --help, por ejemplo

$ wc --help


]]> http://redy.fotolibre.net/2008/01/08/curso-de-bash-para-fotografos-linuxeros-9-la-fontaneria/feed/ 0 http://redy.fotolibre.net/2007/11/23/curso-de-bash-para-fotografos-linuxeros-8-gestion-de-multiples-procesos/ http://redy.fotolibre.net/2007/11/23/curso-de-bash-para-fotografos-linuxeros-8-gestion-de-multiples-procesos/#comments Fri, 23 Nov 2007 13:34:19 +0000 Redy http://redy.fotolibre.net/como/curso-de-bash-para-fotografos-linuxeros-8-gestion-de-multiples-procesos/ La gestión de procesos Procesos en segundo plano y en primer plano Cuando os hablé de comandos internos y externos, no sé si recordaréis que introduje el concepto de programa y proceso. Un programa existe sin necesidad de que esté ejecutándose, cuando se ejecuta un programa se inicia un proceso que termina cuando el programa Seguir leyendo «Curso de bash para fotógrafos linuxeros. (8) Gestión de múltiples procesos»
]]>



La gestión de procesos

Procesos en segundo plano y en primer plano

Cuando os hablé de comandos internos y externos, no sé si recordaréis que introduje el concepto de programa y proceso. Un programa existe sin necesidad de que esté ejecutándose, cuando se ejecuta un programa se inicia un proceso que termina cuando el programa finaliza. Un mismo programa puede estar ejecutándose en varios procesos distintos de forma simultánea. Hasta ahora todas las ordenes que escribíamos aunque fuesen compuestas, ejecutan los programas o los comandos de forma secuencial, es decir no comenzamos otro hasta que finaliza el primero. Esto es así incluso aunque los metamos de una sola vez en una orden compuesta con cualquiera de los separadores vistos hasta ahora. Los procesos en los que se ejecuta cada comando no son pues simultáneos.


Un separador que nos permite ejecutar varios comandos de forma simultánea es el ‘&’ (un solo ampersand, y no dos). Por ejemplo si ponemos:
$ du /bin & ps u & echo esto es una prueba
Se ejecutarán los tres comandos simultáneamente, y obtendremos su salida no necesariamente en el mismo orden que los hemos tecleado. Lo más probable es que el comando echo termine primero, luego termine el ps y finalmente el du, pero eso dependerá mucho de cada máquina. El segundo proceso se lanza inmediatamente después de lanzar el primero pero sin esperar a que finalice, y el tercero se lanza inmediatamente después del segundo, sin esperar la finalización de ninguno de los anteriores, y cuando el tercer proceso ha finalizado (no tienen porque haberlo hecho los anteriores) se devuelve el control al bash que nos presenta el prompt. Así que probablemente si lanzas esa orden, el prompt te quede arriba, justo después de que echo haya escrito ‘esto es una prueba’, y a continuación ps y du lanzan su salida.

Si hubiésemos finalizado la orden con un ‘&amp:’ tendríamos el prompt incluso antes de que la última orden finalizase. Esto puede ser útil cuando queremos ejecutar un comando que tarda mucho y mientras termina queremos seguir trabajando. Por ejemplo si queremos obtener 4000 cifras decimales del número pi podemos usar la calculadora ‘bc’ para hacerlo, tal que así:
bc -l -q < <<"scale=4000; 4*a(1)"
El comando es bc, los parámetros -l y -q son para que use la librería matemática, en la que tiene las funciones trigonométricas que necesitamos y la q es para que no muestre nada más que el resultado. Lo que queremos calcular se lo introducimos, como si lo hubiésemos tecleado, mediante la expresión <<<”scale=4000; 4*a(1)”. Fijamos la precisión (scale) a 4000 cifras decimales y calculamos el producto de 4 por el arcotangente de 1 (Pi/4=Arcotangente(1)).
Pero esto puede tardar en calcularse varios segundos o varios minutos (depende de la potencia de cálculo de tu ordenador), así que lo más practico es terminar la orden con un & y seguir trabajando hasta que termine ¿no?

bc -l -q < <<"scale=4000; 4*a(1)" &

A los procesos que se lanzan y se dejan trabajando, sin esperar a que terminen se les denomina procesos en segundo plano. Un proceso puede estar detenido, ejecutándose en segundo plano o ejecutándose en primer plano (en primer plano solo puede haber un proceso, detenidos o en segundo plano todos los que quieras. Bueno, todos no, el administrador puede, mejor dicho: debe, establecer cuotas para que el usuario no pueda abrir todos los procesos que quiera).

Supongamos que tecleamos la orden anterior, la que calculaba PI y la hemos lanzado en primer plano, (sin ponerle el & al final). Mientras se está ejecutando nos damos cuenta de que teníamos algo más importante que hacer y no podemos esperar a que la orden finalice. Siempre podemos pulsar <control>Z, con lo que la orden que está en primer plano se detiene, y la shell nos devuelve el prompt para que podamos hacer eso que tanta prisa nos corría. La orden no ha finalizado, está parada. Si ejecutamos el comando jobs nos muestra todos los procesos que nuestra shell tiene abiertos y su estado, que en este caso es ‘stopped’ es decir parado.
$ jobs
[1]- Stopped bc -l -q < <<"scale=4000; 4*a(1)" &

Cuando queramos podemos hacer que continúe, y podemos hacerlo continuar de dos formas, en primer plano o en segundo plano, el comando para pasar un proceso al primer plano es fg (de foreground=primer plano) y el comando para reanudar en segundo plano es bg (de backgrund=al fondo). A esos comandos normalmente hay que especificarle el número de proceso (ese numerito que sale entre corchetes cuando pedimos un listado de los procesos con el comando jobs) precedido de un signo ‘%’ que indica proceso, tal que así:

$ bg %1
$ fg %1

Otra cosa que podemos hacer con un proceso es matarlo, con lo cual deja de ocupar recursos y finaliza, y ya no se puede ‘resucitar’. Para matar un proceso se usa el comando kill, al que también se le pasa como argumento el número de proceso precedido del símbolo ‘%’.

$ kill %1

El comando kill en realidad lo que hace es mandar una señal al proceso. La señal por defecto es la de terminación ‘SIGTERM’, pero pueden enviarse otras, como por ejemplo ‘SIGKILL’ que es mucho más dura. SIGTERM normalmente se usa para finalizar el proceso de forma razonable, por ejemplo si hay datos sin guardar se guardarían antes de finalizar le proceso, pero con SIGKILL no, se mata el proceso inmeditamante sin guardar nada. Para ver la lista de posibles señales usa el comando ‘kill -l’ o consulta ‘man 7 signal’ (no pongas man signal sin más porque en ese caso te llevará a la sintáxis de la función del lenguaje C que maneja las señales). Entendido el asunto de las señales veamos como podemos parar o reanudar un proceso que se encuentra en segundo plano. El kill de bash es bastante flexible y permite poner la señal mediante un nombre o por su número precedida de ‘-s ‘ o simplemente de un signo menos para diferenciarla del número de proceso’. Incluso si usamos nombres podemos omitir el prefijo (SIG) por el que empiezan todos los nombres de señal. Así que cualquiera de estas formas es equivalente, yo que soy muy vago me quedo con una de las dos últimas, preferiblemente la última, porque me resulta más sencillo recordar los nombres que los números.
$ kill -s SIGSTOP %1
$ kill -SIGSTOP %1
$ kill -s 19 %1
$ kill -19 %1
$ kill -STOP %1


Evidentemente podemos reanudar un proceso parado con cualquiera de estas formas:

$ kill -s SIGCONT %1
$ kill -SIGCONT %1
$ kill -s 18 %1
$ kill -18 %1
$ kill -CONT %1


Procesos y Trabajos

Como sabemos, Linux es Multiusuario y Multitarea. Hasta ahora hemos visto como en una shell se pueden ejecutar varios procesos simultáneamente, y la orden jobs, nos muestra todos los procesos abiertos desde nuestra shell, numerados. Hay que saber que, al mismo tiempo, seguro que hay muchos más procesos corriendo en Linux, que no fueron iniciados por nosotros desde nuestra shell, pueden ser procesos que el sistema arranca automáticamente o procesos que arrancan otros usuarios desde otras consolas, cada proceso tiene un número único a nivel del sistema llamado PID (Proccess IDent = Identificador de proceso), no hay que confundir este número con el número de ‘job’ que la shell le da a nuestros procesos. Cuando lanzamos un proceso en segundo plano o detenemos un proceso, la shell nos indica dos números, el primero entre corchetes ‘[]‘ es el numero de proceso para la shell y el segundo es el número de proceso en el sistema, el PID. Para no liarnos con los dos números, de aquí en adelante, al número de proceso que asigna la shell le llamaremos ‘trabajo’, reservando la palabra ‘proceso’ para referirnos a la numeración que asigna el sistema.

bc -l -q < <<"scale=4000; 4*a(1)" &
[1] 28777

Aquí podemos ver que nuestro cálculo de PI es el trabajo 1 y el proceso 28777 (en mi caso, vosotros evidentemente obtendréis números distintos). Otros usuarios pueden tener también su trabajo 1, pero el proceso 28777 es único en el sistema, ningún otro proceso puede tener el mismo número. Si consultamos con el comando jobs solo se muestra el número de trabajo.

$ jobs
[1]+ Running bc -l -q < <<"scale=4000; 4*a(1)" &

El comando ps nos muestra los procesos del sistema. Si no le decimos otra cosa nos mostrará los que son de nuestro usuario y nuestra terminal.

$ ps
PID TTY TIME CMD
19399 pts/2 00:00:00 bash
28777 pts/2 00:00:01 bc
28796 pts/2 00:00:00 ps

El comando kill puede usarse con el número de trabajo o con el número de proceso indistintamente, en mi caso concreto las dos órdenes siguientes serían equivalentes.

$ kill %1
$ kill 28777

No sé si os habéis fijado que al lado de los números de trabajo, a veces aparece un signo ‘+’ o un signo ‘-’. Estos signos tienen su significado.
Introduzcamos por ejemplo las siguientes ordenes que calculan el número PI, el número e, y el logaritmo natural de 2, todos ellos con 4000 cifras significativas para que se tomen algo de tiempo, (si tu máquina es muy rápida puedes calcular más cifras).

$ bc -l -q < <<"scale=4000; 4*a(1)" &
[1] 28987
$ bc -l -q < <<"scale=4000; e(1)" &
[2] 28989
$ bc -l -q < <<"scale=4000; l(2)" &
[3] 29026
$ jobs
[1] Running bc -l -q < <<"scale=4000; 4*a(1)" &
[2]- Running bc -l -q < <<"scale=4000; e(1)" &
[3]+ Running bc -l -q < <<"scale=4000; l(2)" &
El trabajo actual (el último que se ha iniciado) se marca con un signo ‘+’, el anterior con un signo ‘-’. El resto de los trabajos no tienen denominación especial. Decíamos que con las ordenes kill, fg y bg siempre había que especificar el número de trabajo (%1, %2, %3…) al trabajo actual nos podemos referir con el identificador especial ‘%%’ o con ‘%+’ y al trabajo anterior con ‘%-’. Así que en nuestro caso concreto las siguientes ordenes son equivalentes.
$ kill %3
$ kill %%
$ kill %+
Y estas también:
$ kill %2
$ kill %-
Kill se puede usar para matar trabajos o procesos, así que siempre hay que poner los números de trabajo con % y los números de proceso sin él. En cambio fg y bg, solo se pueden usar con números de trabajos, así que si omitimos el signo de %, funcionan igual. Es lo mismo poner ‘fg %1′ que ‘fg 1′, o ‘bg %1′ que ‘bg 1′. Pero no es lo mismo ‘kill %1′ que ‘kill 1′ ¡eh!.

En fg y en bg si no se pone número de proceso se entiende que nos referimos al proceso actual, estas tres órdenes son equivalentes:

$ bg %+
$ bg %%
$ bg

Y Para rematar, el comando fg se puede omitir siempre que el número de trabajo lo pongamos precedido de %, así que si (como yo) eres vago escribiendo puedes poner solamente ‘%2′ cuando quieras poner ‘fg %2′.

nice y renice

Aunque no es algo específico de bash, en linux, al ser un sistema multitarea existen utilidades para administrar la prioridad de cada proceso. Habrá procesos que consumen muchos recursos y otros menos. Uno de los recursos más preciados es uso de la cpu. Todos los procesos se están ejecutando al mismo tiempo en una misma cpu (bueno ahora con procesadores de doble y cuádruple nucleo, pueden repartirse en varias), en realidad lo que hace la cpu es repartir su tiempo en pequeños intervalos dedicando unos ciclos de reloj a cada proceso. Hay procesos que la mayoría del tiempo no están haciendo nada, porque deben esperar por un dato del usuario, o de un dispositivo más lento. Esos procesos consumen poca cpu, en cambio otros que hacen cálculos intensivos, consumen más tiempo. El sistema operativo usa un planificador que asigna unas prioridades a cada proceso, y lo hace de forma dinámica, variando esta prioridad para cada proceso según los recursos que va utilizando, de acuerdo a unas reglas que intentan mantener la máxima disponibilidad de recursos. Los procesos con mayor prioridad dispondrán de más tiempo de cpu. Además de esto el usuario puede asignar un nivel de prioridad (NICE) a cada proceso cuando lo lanza. Disponemos de 40 niveles NICE desde -20 (prioridad más alta) hasta 19 (prioridad más baja) lo normal es que los procesos se arranquen con nivel 0. Pero si arrancamos un proceso con un nivel distinto sus hijos heredaran este nivel. El root puede asignar valores negativos a los procesos que arranca, pero los usuarios solo positivos, quiere esto decir que como usuarios solo podemos arrancar un proceso con menos prioridad de la habitual. En cualquier caso es útil: imagínate que queremos lanzar un programa de esos que consumen bastante cpu, pero no tenemos prisa porque acabe y queremos que el sistema no se ralentice mucho porque queremos seguir haciendo otras cosas. Podemos lanzar el proceso en segundo plano pero con una prioridad menor (un valor mayor de NICE) a la normal. Para hacer esto usaremeos el comando nice:
nice -n 19 bc -l -q < <<"scale=6000; 4*a(1)" &

(El comando anterior arrancará la calculadora bc en segundo plano para calcular las primeras 6000 cifras decimales del número PI), pero lo hará con una prioridad muy pequeña.

Podemos ver que procesos consumen más recursos con el comando top, que nos sacará ordenados de mayor a menor los comandos que más uso de cpu consumen. También muestra otra información general, como la cantidad de usuarios que están en el sistema, el número total de procesos y de estos cuantos están activos, cuantos durmiendo, cuantos detenidos y cuantos zombies; la memoria total, la usada y la libre, etc…

El listado que nos mostrará contendrá el número de PID, el usuario que lo está ejecutando, la prioridad del proceso (PRI), el valor nice (NI), el tamaño del proceso (SIZE), el tamaño total del proceso junto con los datos que maneja (RSS), el tamaño usado por el proceso en la memoria (SHARE), el estado del proceso(STAT), el tamaño de las librerías del proceso (LIB), el porcentaje de CPU ( %CPU) y de memoria (%MEM) así como también el tiempo de ejecución (TIME) y el nombre del proceso (COMMAND).

Para salir de top pulsaremos la tecla ‘q’

Si queremos mostrar solo los procesos que más consumen de un determinado usuario podemos pulsar la ‘u’ y se nos pedirá el nombre del usuario (dejarlo en blanco para mostrar todos).

Desde top también podemos interactuar (si tenemos permiso para ello) matando un proceso o modificando su prioridad (nice). Usaremos la tecla ‘k’ para matar un proceso y la ‘r’ para cambiarle la prioridad.

Ya vimos como lanzar un proceso con menos prioridad con nice, pero ¿que ocurre si ya hemos lanzado un proceso y decidimos luego cambiarle la prioridad?

Podemos usar el comando renice seguido de un valor de nice y del numero de proceso. Pero hay que tener en cuenta que un usuario jamás puede aumentar la prioridad de un proceso (dar valores más bajos de nice), solo disminuirla, y que no puede modificar la prioridad a procesos que no sean suyos. Sólo el root puede aumentar o disminuir la prioridad según quiera.

Parámetros y variables relativas a procesos

Hay ciertos parámetros y variables interesantes que podemos consultar que nos dán información sobre los procesos:

$$ Es el numero de PID del bash que estamos ejecutando.

Esta variable puede sernos muy útil en scripts, por ejemplo para crear ficheros temporales únicos, ya que no puede haber dos procesos con el mismo pid.

$! Es el número de PID de la órden más reciente ejecutada en segundo plano.

Nos permitirá conocer fácilmente el numero de pid de un proceso en background, por si hay que matarlo o mandarle alguna señal.

$SHLVL Cada vez que arranquemos una subshell este número se incrementa en 1. Hay que tener en cuenta que siempre que invocamos a un script se ejecuta una subshell.

$PPID El proceso padre del nuestro.

wait

Este comando en principio no hace nada más que esperar a que un determinado ejecutado en segundo plano termine. Si ponemos un número de proceso (PID) o un identificador de trabajo (prefijado con % igual que ya vimos antes) se esperará por ese proceso. Si no ponemos nada wait espera a que terminen todos los proceso hijos que haya en segundo plano. Esto es útil en scrips si lanzamos ciertos procesos en segundo plano, pero es necesario que alguno termine antes de acometer la siguiente tarea.

]]> http://redy.fotolibre.net/2007/11/23/curso-de-bash-para-fotografos-linuxeros-8-gestion-de-multiples-procesos/feed/ 0 http://redy.fotolibre.net/2007/10/30/curso-de-bash-para-fotografos-linuxeros-7-comandos-internos-y-externos-ordenes-compuestas/ http://redy.fotolibre.net/2007/10/30/curso-de-bash-para-fotografos-linuxeros-7-comandos-internos-y-externos-ordenes-compuestas/#comments Tue, 30 Oct 2007 22:14:39 +0000 Redy http://redy.fotolibre.net/como/curso-de-bash-para-fotografos-linuxeros-7-comandos-internos-y-externos-ordenes-compuestas/ Comandos internos y externos Hay una serie de comandos que la propia shell ejecuta sin ninguna ayuda, a esos comandos les llamaremos comandos internos. A modo meramente informativo puedo poner una relación de los comandos internos de bash: ., :, [, alias, bg, bind, break, builtin, caller, cd, command, compgen, complete, continue, declare, dirs, disown, Seguir leyendo «Curso de bash para fotógrafos linuxeros. (7) Comandos internos y externos. Órdenes compuestas.»
]]>


Comandos internos y externos

Hay una serie de comandos que la propia shell ejecuta sin ninguna ayuda, a esos comandos les llamaremos comandos internos.
A modo meramente informativo puedo poner una relación de los comandos internos de bash: ., :, [, alias, bg, bind, break, builtin, caller, cd, command, compgen, complete, continue, declare, dirs, disown, echo, enable, eval, exec, exit, export, false, fc, fg, getopts, hash, help, history, jobs, kill, let, local, logout, popd, printf, pushd, pwd, read, readonly, return, set, shift, shopt, source, suspend, test, times, trap, true, type, typeset, ulimit, umask, unalias, unset, wait

Cualquier otro comando que no se encuentre entre estos, bash no sabe ejecutarlo, y entenderá que es un programa externo, así que lo buscará en una serie de directorios que se la han configurado.

Por ejemplo si tecleamos:

$ ls

El bash ejecutará un programa que está en el directorio /bin/ y se lama ls.

Hay que decir también que existen ciertas redundancias, bash maneja internamente ciertos comandos que también son ejecutables externos, otras shells quizá no los manejen internamente, por eso son necesarios como ejecutables externos. Por ejemplo el comando 'pwd' nos informa de en que directorio nos encontramos, y es un comando interno de bash, pero también es un programa externo que está en /bin/. En casos así siempre se ejecuta primero el interno.

$ pwd
/home/redy

Si existe esta coincidencia, pero por la razón que sea necesitamos ejecutar el comando externo y no el interno debemos hacerlo indicando su path completo:

$ /bin/pwd

Aparentemente el resultado es el mismo, pero se ejecutó un programa externo en vez del comando interno. Prueba

$ /bin/pwd --help
Modo de empleo: /bin/pwd [OPCIÓN]
 
Muestra el nombre de fichero completo del directorio de trabajo actual.
   –help muestra esta ayuda y finaliza
   –version informa de la versión y finaliza
NOTE: your shell may have its own version of pwd, which usually supersedes
the version described here. Please refer to your shell’s documentation
for details about the options it supports.

Otra forma de evitar los comandos internos es usando el comando enable que permite activar o desactivar el manejo interno del comando que queramos. Si tecleamos por ejemplo

$ enable -n pwd

A partir de ese momento y hasta que salgamos de la shell o lo volvamos a activar pwd nunca será tratado como comando interno, se ejecutará en su lugar el programa externo. Para volver a activarlo como comando interno deberás ejecutar

$ enable pwd

Para ver todos los comandos que se manejan internamente, puedes usar 'enable' sin parámetros o 'enable -p'. Y para ver los que están desactivados puedes usar 'enable -n'. Por último 'enable -a' te los muestra todos mezclados.

$ enable
$ enable -p
$ enable -n
$ enable -a


Una orden muy útil para ver como tratará bash un comando es 'type'. Type nos informa de si un comando es manejado internamente o externamente.
$ type man
man is /usr/bin/man
$ type -t man
file
$ type pwd
pwd is a shell builtin
$ type -t pwd
builtin
$ enable -n pwd
$ type pwd
pwd is /bin/pwd
$ type -t pwd
file

Todo comando que el bash no sepa manejar internamente, lo busca en los directorios dónde residen los programas. Busca un programa con el mismo nombre que el comando que tecleamos, puede ser una utilidad del sistema operativo, o un programa de usuario, no hay diferencia, si lo encuentra lo ejecuta, y si no nos avisa del error diciendo 'command not found.'.
Existe una variable que tiene un significado especial, su nombre es PATH, y contiene la lista de directorios separados por ':' en los que la shell busca los programas.

Cuando hablamos de 'comando' sin más, sin definir si es externo o interno, nos referimos tanto a los comandos que el propio bash interpreta, como a los programas que tenemos instalados en nuestro sistema operativo.

Concepto de programa y proceso

Quizá este sea el momento de definir lo que es un programa. Un programa es un archivo o un conjunto de archivos que contienen instrucciones y datos, el ordenador de alguna forma puede ejecutar las instrucciones de ese programa. Por ejemplo ls es un programa, contenido en un archivo, que está en el directorio /bin/ y que realiza una tarea que es la de mostrar el contenido de un directorio.

Fundamentalmente hay dos tipos de programas: unos está escritos en código binario, en lenguaje, que el propio procesador puede entender. No es que se escriban así, generalmente se escriben en un lenguaje de programación de alto nivel, más inteligible por seres humanos y un programa (compilador) los traduce al lenguaje binario del procesador. En cambio hay otro tipo de programas que están escritos en un lenguaje que el procesador no entiende directamente, generalmente son archivos de texto que tendrán que ser interpretados por otro programa binario que los va traduciendo línea a línea y los va ejecutando. Tal es el caso de los scripts que escribimos en las anteriores entregas, son archivos de texto que el programa binario /bin/bash, tiene que interpretar. Pues bien en nuestro sitema habrá de los dos tipos. Por ejemplo en el mío:
$ file /bin/ls
/bin/ls: ELF 64-bit LSB executable, AMD x86-64, version 1 (SYSV), for GNU/Linux 2.6.9, dynamically linked (uses shared libs), for GNU/Linux 2.6.9, stripped
$ file /bin/egrep
/bin/egrep: Bourne shell script text executable
$ file /usr/bin/partmon
/usr/bin/partmon: perl script text executable
$ file /usr/bin/helpviewer
/usr/bin/helpviewer: a python script text executable
$ file /usr/bin/spamassassin
/usr/bin/spamassassin: awk script text

Ya veis que hay tanto programas binarios, como scripts en formato texto tanto de bash como de otros intérpretes como pueden ser el perl o el python, el awk..

En un entorno multitarea y multiusuario como Linux hay que distinguir programa y proceso. Se denomina proceso a un programa que se encuentra en ejecución. La multitarea permite que un mismo programa sea ejecutado simultáneamente varias veces, ya sea porque varios usuarios lo han lanzado, o porque un único usuario lo ha lanzado varias veces. Esto es: un mismo programa puede generar varios procesos. En linux cada proceso tiene un número de identificador (PID). Un proceso (proceso padre) puede desencadenar otros (procesos hijos), y un proceso no puede finalizar mientras haya procesos hijos que no hayan terminado. En linux un único proceso llamado init, que siempre tiene el PID 1, es el padre (bueno mejor dicho el ancestro) de todos los demás procesos. Para ver los procesos en ejecución se utiliza el comando ps, pero no adelantemos acontecimientos porque dedicaremos un capítulo a la gestión de procesos.

Lo que si quiero reseñar es que cada proceso tiene un área de memoria, a la que llamamos entorno del proceso dónde se guardan sus parámetros y variables. Cada proceso tiene su entorno y el hecho de modificar un parámetro o variable en un proceso no afectará para nada a los parámetros de otro proceso, aunque se llamen igual. Cuando un proceso finaliza su entorno desaparece con él. Ahora bien cuando se crea un proceso hijo se copia parte del entorno del padre, ese entorno que se hereda es una copia y como dije antes se destruye al acabar el proceso hijo, sin afectar para nada al entorno del padre, ni a otros entornos de otros procesos. Si hablamos de variables; podemos decidir que variables serán copiadas en los procesos hijos y cuales no marcándolas como exportables. El comando para hacer esto es export y su sintáxis es más o menos:
'export VAR1[=valor1] ... [VAR_N=[valor_n]]'.
Si se usa export con una lista de una o más variables estas se marca para ser exportadas a los procesos hijos. Se puede asignar un valor a la variable al mismo tiempo.

$ A=5
$ B=6
$ export B # Los procesos hijos tendrán una variable B que copiará su valor del proceso padre
$ bash # Abrimos un proceso bash hijo
$ echo $A # A no tiene valor en el proceso hijo
$ echo $B # Pero B si, ha copiado el valor del padre en el entorno del hijo
$ B=7 # Modificamos B en el hijo
$ echo $B # Vemos que se ha modificado
$ exit # Finalizamos el proceso hijo
$ echo $A # Las variables del proceso padre siguen conservando sus valores
$ echo $B # Incluso la B que había sido modificada en el hijo, pero claro, era una copia.

Si queremos desmarcar una variable que ha sido previamente marcada como exportable usaremos 'export -n variable', esto hará que no se copie a los procesos hijos que se puedan desencadenar desde ese momento. Y si queremos obtener una lista de todas las variables, que se copiarán al entorno de los procesos hijos cuando estos se inicien usaremos el comando export sin ningún argumento o con el argumento -p

$ export -p

Los comandos internos se ejecutan normalmente en el mismo proceso en el que estamos, pero para ejecutar comandos externos bash genera un proceso hijo en el que se ejecuta el comando. Es importante reseñar esto ya que si el comando necesita acceder al valor de una variable es necesario que ésta esté en el entorno del comando (proceso hijo). Por ejemplo si trabajamos con varios displays (varios monitores, o varias consolas gráficas virtuales, y queremos ajustar la gamma de uno de ellos podemos usar el comando xgamma que por defecto ajustará el display indicado en la variable $DISPLAY


$ export -n DISPLAY # por si acaso
$ DISPLAY=:1
$ xgamma 1.2


No funcionará como queremos porque al ejecutarse xgamma en un proceso hijo, en su entorno la variable DISPLAY no está definida. Tendríamos que hacer:


$ DISPLAY=:1
$ export DISPLAY
$ xgamma 1.2

Así cuando se genera el proceso hijo, la variable DISPLAY, marcada para exportación se copiará con el valor que tenga del entorno del proceso padre all entorno del proceso hijo. En lugar de dos órdenes también se puede usar una sola, que es más cómodo, para exportar y asignar valor:

$ export DISPLAY=:1
$ xgamma 1.2

O simplemente usar la forma de asignar variables en la misma línea del comando que ya hemos visto:

$ DISPLAY=:1 xgamma 1.2

Decíamos en el capítulo anterior que esta es una asignación temporal del valor de la variable; en realidad lo que hacemos con ese comando es asignar valor a una variable en el entorno del proceso hijo que vamos a iniciar para ejecutar el comando xgamma.

Cuando una variable está marcada para exportación y se copia a un proceso hijo conserva todos sus atributos, marca de esportación incluída, así que si no hacemos algo que lo evite también se copiará a los proceso hijos del hijo y así sucesivamente.

Hay ciertas variables que se definen en los ficheros de configuración del bash, y que normalmente tienen el atributo de exportables. Un ejemplo es PATH que mencionábamos antes que es uasad por la shel para saber dónde buscar programas ejecutables, es decir comandos externos.


Órdenes compuestas

Hablábamos ya en la entrega 1 de las órdenes simples, y decíamos: "Si comparamos el lenguaje bash con el castellano, podríamos decir que cada orden es como un frase. Cada orden consta de varios elementos (palabras) y tiene significado propio, puede ser interpretada y ejecutado por la shell. Como en nuestro idioma, toda frase debe tener normalmente un verbo, en bash los verbos son los comandos, que generalmente van al principio de la orden. [...] Hay ordenes que no tienen más que el comando, y hay otras que llevan argumentos adicionales. [...] Cuando estudiábamos lengua en el cole, había oraciones simples y compuestas. Las simples tenían un solo verbo y las compuestas, se formaban combinando dos o más oraciones simples, y normalmente tenían más de un verbo. Además había varios tipos de oraciones compuestas, coordinadas, subordinadas... En el lenguaje de bash pasa lo mismo, hay órdenes simples con un solo comando, y hay órdenes compuestas que llevan varios comandos. En el castellano para unir varias frases simples en una farse compuesta se usan la conjunciones, en bash se usan también unos signos que denominaremos separadores.

El caso más simple de ordenes compuestas consiste en juntar varias ordenes simples, para que se ejecuten una tras otra separándolas por un punto y coma ';' tal que así

$ echo "Este es el listado del directorio"; ls; echo "Buenos días"

Hay otras formas de formar órdenes compuestas, que iremos viendo poco a poco, pero antes tengo que explicar algunos conceptos:

Ejecución de programas, código de terminación

Siempre que se ejecuta un comando, ya sea este interno o externo, al finalizar el proceso obtenemos un código de terminación, que es un número de 0 a 65535. Normalmente, y salvo que el programador haya decidido otra cosa, se sigue el convenio de que si el programa finalizó sin ningún error se obtiene un código 0 y si hubo algún problema un código distinto de 0.

Podemos consultar el código de terminación del último comando ejecutado viendo el valor del parámetro $? por ejemplo con el comando echo, tal que así:
$ echo $?

Prueba a hacer un ls de un fichero existente y de otro que no existe y verás como el código de terminación cambia:

$ cd ~/ejercicios_curso_bash
$ touch fichero_que_existe
$ ls fichero_que_existe
$ echo $?
0
$ ls fichero_que_no_existe
$ echo $?
1

Ordenes compuestas condicionadas

Una vez entendido esto volvemos a las órdenes compuestas. Más arriba veíamos como en una sola orden podíamos agrupar varias ordenes simples usando el separador ';'. Hay dos separadores que hacen lo mismo pero la segunda (y sucesivas ordenes si las hubiese), se ejecutará o no en función del código de terminación de la orden anterior.

Para ejecutar una orden si el código de terminación de la anterior fue 0 usaremos el separador '&&' dos signos de andpersand consecutivos de la siguiente forma.


$ ls fichero_que_existe && echo "El fichero existe"
fichero_que_existe
El fichero existe
$ ls fichero_que_no_existe && echo "Esto no se imprimirá"
ls: fichero_que_no_existe: No existe el fichero o el directorio

Para ejecutar una orden si el código de terminación de la anterior fue distinto de 0, usaremos el separador '||' dos barras verticales consecutivas tal que así:


$ ls fichero_que_existe || echo "Esto no se imprime"
fichero_que_existe
$ ls fichero_que_no_existe || echo "El comando ls terminó con error $?"
ls: fichero_que_no_existe: No existe el fichero o el directorio
El comando ls terminó con error 1

Los ejemplos vistos unen dos ordenes simples en una compuesta, pero podemos concatenar más de dos combinando los separadores como nos interese.

$ ls fichero_que_existe && ls fichero_que_no_existe || echo "hola"
fichero_que_existe
ls: fichero_que_no_existe: No existe el fichero o el directorio
hola
 
$ ls fichero_que_existe && echo "CT: $?"; echo "El fichero existe"
fichero_que_existe
CT: 0
El fichero existe

Como pueden combinarse muchas oŕdenes simples usando varios separadores hay que establecer unas prioridades para le evaluación de estos, es como en matemáticas que la multiplicación tiene prioridad sobre la suma y la resta por ejemplo, y por tanto si ponemos 3 + 2 * 5, se entiende que primero se multiplica el dos por el cinco y a continuación se suma a tres el resultado de ese producto. Aquí es igual, los separadores anteriores se ejecutan en un orden de prioridad: primero se ejecuta '&&' y '||' que tienen la misma prioridad, y se ejecutarán por órden de izquierda a derecha. Y luego está ';'. En caso de duda podemos hacer agrupaciones con llaves o con paréntesis.

Agrupación con llaves: Toda lista de ordenes que agrupemos entre llaves funcionará, en cuanto a prioridad se refiere como si fuese una sola orden simple. Hay que dejar espacios siempre entre las llaves y las ordenes (para que la shell no las confunda con una expansión de llaves) , y la lista tiene que acabar en un ';' antes de cerrar la última llave. Por ejemplo:

$ ls fichero_que_no_existe && { echo hola ; ls pepe || echo adios ; }
Dada la prioridad de cada separador, si no pusiesemos ninguna llave llave sería como ejecutar:
${ ls fichero_que_no_existe && echo hola ; } ; { ls pepe || echo adios ; }

Los comandos entre llaves se agrupan y se ejecutan como procesos de la shell actual y el código de terminación obtenido como resultado de la evaluación de las llaves es el del último comando ejecutado dentro de las llave.

Agrupación con paréntesis: funciona de manera similar. Como el paréntesis no puede confundirse con una expansíon como era el caso de las llaves, no es necesario respetar los espacios. La agrupación con paréntesis no se ejecuta en la misma shell sino que se abre en un proceso hijo otra subshell y se ejecuta dentro de esta, por lo que si las órdenes modifican el entorno en la subshell, el entorno de la shell original permanece invariable al finalizar. No hace falta acabar en ';' antes de cerrar el último paréntesis.

Las llaves se ejecutan en la misma shell con la siguiente orden compuesta podéis ver que entre nuestra lista de procesos, solo hay un bash.

$ { echo Comandos entre llaves ; ps f; }
Comandos entre llaves
PID TTY STAT TIME COMMAND
14911 pts/2 S 0:00 bash
15358 pts/2 R 0:00 ps f

Sin embargo en una orden entre paréntesis se abre otro proceso con otro bash en el que se ejecutan las órdenes.
$ (echo Comandos entre paréntesis ; ps f)
Comandos entre paréntesis
PID TTY STAT TIME COMMAND
14911 pts/2 S 0:00 bash
17637 pts/2 S 0:00 bash
17638 pts/2 R 0:00 \_ ps f

$ A=5; { A=6; echo 'Dentro $A vale' $A; } ; echo 'Fuera $A vale' $A
Dentro $A vale 6
Fuera $A vale 6
$ A=5; (A=6; echo 'Dentro $A vale' $A ) ; echo 'Fuera $A vale' $A
Dentro $A vale 6
Fuera $A vale 5

Algo de lógica

Para los que sepan programar en C u otro lenguaje similar habrán visto en los separadores "||" y "&&" una relación con los operadores de C de igual grafía que representan a los operadores lógicos and y a or respectivamente.

Que no se asuste nadie. No hace falta saber C, para entender lo que voy a intentar explicar. Eso sí, si no se presta atención puede ser algo lioso de entender, así que espero muchas dudas y consultas de este capítulo, porque ya sabéis que el que no pregunta nada, o lo sabe todo, o no sabe nada.

Decíamos que si todo iba sin errores el estado de terminación era 0 y si había error era algo distinto a 0. Podemos asumir que cero es 'Éxito' y no cero es 'Fallo'. Para abstraernos a algo más booleano (de Boole, el padre de la lógica), podemos entender que 'Éxito' es como un resultado 'Cierto' y 'Fallo' es como un resultado 'Falso', o sea que cero es Cierto, y no cero es Falso. (A veces cuesta pensar en lógica negativa, ya que estamos acostumbrados a que el cero sea falso, pero en bash el cero es cierto).

En lógica de Boole tenemos dos operadores muy usados.

A veces a estos dos operadores se les llama suma lógica (O) y producto lógico (Y) pero yo creo que se entiende más con la nomenclatura de las conjunciones Y y O

El operador Y (and en inglés) que dadas dos proposiciones nos devuelve 'Cierto' si ambas son Ciertas y 'Falso' Si alguna de ellas es falsa.

(Yo soy usuario de Fotolibre) Y (Me gusta Windows)

Es falso porque una de las dos proposiciones es falsa pero...

(Yo soy usuario de Fotolibre) Y (Sé algo de bash)

Es cierto porque ambas son ciertas.

El otro operador lógico es O (or en inglés) que nos da como resultado Cierto si alguna de las proposiciones es cierta, y falso solo si ambas son falsas.

(Yo soy usuario de Fotolibre) O (Me gusta Windows)

Es cierto porque al menos una de las dos es cierta, pero...

(Me gusta Windows) O (Odio Linux)

Es falso porque ambas son falsas.

En realidad el separador && es un operador lógico Y. Entonces ¿Porque sólo se ejecuta la segunda sentencia si la primera devuelve un error 0?

Tal como decíamos antes 0='Éxito'='Cierto'. Aplicando un principio de comodidad, si la primera orden nos da cierto, tenemos que evaluar si se cumple la segunda para saber si se ambas son ciertas. Pero si la primera no es cierta ya no necesitamos seguir evaluando, ya sabemos que al menos una no es cierta, para que vamos a ejecutar la otra.

La tabla de esta operación lógica sería:

   En lógica:                               En bash:
   -----------------------------            ----------
   Cierto Y Cierto     = Cierto             0 && 0 = 0
   Cierto Y Falso      = Falso              0 && 1 = 1
   Falso  Y lo_que_sea = Falso              1 && X = 1

De forma análoga el separador '||' es un operador lógico O. Así que si la primera orden nos da un resultado de 0, es decir cierto, no se ejecuta la segunda, porque ya sabemos que al menos una de las dos es cierta. Por el contrario si el resultado de la primera es no cero, o sea falso, debemos seguir ejecutando porque, para saber si alguna es cierta, debemos saber el resultado de la segunda. La tabla de la operación lógica O sería:

   En lógica:                               En bash:
   -----------------------------            ----------
   Cierto O lo_que_sea = Cierto             0 || X = 0
   Falso  O Cierto     = Cierto             0 || 1 = 0
   Falso  O Falso      = Falso              1 || 1 = 1

El resultado de la evaluación Y es 0 (Cierto) si ambas ordenes devuelven 0. En realidad se devuelve el resultado de la última orden ejecutada, si la primera es 'no 0' (Falso) se devuelve este valor, ya que la siguiente no se ejecuta. Y si la primera es 0 y la segunda no, se devuelve el valor de terminación de la segunda. Así que efectivamente funciona como una operación lógica Y.

En una evaluación O también se devuelve siempre el código de terminación de la última orden ejecutada, deducirá el lector fácilmente que también funciona como una operación lógica O.

Si te has liado con lo último, no te preocupes, recuerda lo dicho en el apartado anterior:

&& (and ó Y) ejecuta una orden si la anterior devolvió 0 (no error)
|| (or ó O) ejecuta una orden si la anterior no devolvió 0 (error)

Como regla nemotécnica para recordar que cual es Y y cual es O solo tenéis que recordar que el & en los nombres de sociedades significa Y, como en 'Manolo Fdez. & Hijos'. Y para entender el funcionamiento puedes remplazar el && (Y) por un 'Y (si ha funcionado)' o el || (O) por un 'O (si no)' por ejemplo:

$ ls fichero_que_existe && echo "El fichero existe"

Lo leeríamos como '(ls fichero_que_existe) y si ha funcionado (echo "El fichero existe")' y

$ ls fichero_que_no_existe || echo "El fichero no existe"

Lo leeríamos como '(ls fichero_que_no_existe) o si no (echo "El fichero no existe)"

Me interesaría bastante recibir opiniones sobre este capítulo, porque pienso que es especialmente lioso ¿o no?

]]> http://redy.fotolibre.net/2007/10/30/curso-de-bash-para-fotografos-linuxeros-7-comandos-internos-y-externos-ordenes-compuestas/feed/ 0 http://redy.fotolibre.net/2007/10/26/curso-de-bash-para-fotografos-linuxeros-6-variables-y-parametros/ http://redy.fotolibre.net/2007/10/26/curso-de-bash-para-fotografos-linuxeros-6-variables-y-parametros/#comments Fri, 26 Oct 2007 07:13:00 +0000 Redy http://redy.fotolibre.net/fotolibre/curso-de-bash-para-fotografos-linuxeros-6-variables-y-parametros/ Introducción a las variables y parámetros Cualquiera que conozca cualquier lenguaje de programación tendrá ya claro el concepto de variable, pero para los que no sabéis programar es conveniente hacer una pequeña introducción. Todo el mundo sabe usar una calculadora. Todas las calculadoras tienen una o varias teclas de ‘memoria’, usando esas teclas podemos almacenar Seguir leyendo «Curso de bash para fotógrafos linuxeros. (6) Variables y parámetros»
]]>



Introducción a las variables y parámetros

Cualquiera que conozca cualquier lenguaje de programación tendrá ya claro el concepto de variable, pero para los que no sabéis programar es conveniente hacer una pequeña introducción.

Todo el mundo sabe usar una calculadora. Todas las calculadoras tienen una o varias teclas de ‘memoria’, usando esas teclas podemos almacenar un valor con el que estamos trabajando, para poder recuperarlo después, también podemos hacer operaciones con ese valor, como sumarle o restarle cosas. Una variable, en programación, es muy similar a ese concepto, es un almacén donde guardo un dato, que puedo recuperar cuando lo necesito. Puedo modificar o borrar el dato cuando quiera, es por eso que a esa ‘memoria’ se da el nombre de variable. A diferencia de las calculadoras que normalmente solo tienen una ‘memoria’ con las variables tenemos cuantas necesitemos, es decir podemos almacenar no solo un valor sino muchos, cada uno en un espacio distinto. Para distinguir cada uno de estos espacios de almacenamiento es necesario darle un nombre a cada uno, los nombres los elige el usuario a su libre albedrío, pero siguiendo ciertas reglas.

A diferencia de nuestro ejemplo de la calculadora, que sólo trabaja con números, los ordenadores pueden procesar muchos tipos de datos, números, palabras, textos… las variables pueden almacenar cualquier tipo de datos.

En algunos lenguajes es necesario distinguir de que tipo es el dato que guardamos en una variable, en bash no, la misma variable puede contener en un momento dado un número y en otro un texto.

En realidad las variables son un caso concreto de un concepto más amplio que es el de parámetro. Un parámetro es cualquier entidad capaz de almacenar un valor susceptible de cambiar. Las variables son en realidad parámetros que nosotros podemos crear, destruir o modificar su valor a voluntad. Pero hay otros parámetros a los que no podemos asignar valores pero si consultarlos. Por ejemplo el código de error del último comando ejecutado no puede ser asignado ni modificado por nosotros sin embargo es un valor que puede consultarse.

Llamamos asignar un valor a una variable al hecho de almacenar un valor en el espacio designado por el nombre de ésta, cada variable solo puede contener un valor al mismo tiempo, y si asignamos un nuevo valor a una variable cualquier valor que tuviese previamente se destruye.

Variables, asignación y utilización

A una variable se le puede asignar un valor en bash mediante la orden:

$ NOMBRE=valor

Esta es una de las órdenes cuya primera palabra no es un comando, tal como estábamos acostumbrados a ver, la primera palabra es el nombre de una variable, luego lleva un signo igual y luego un valor, no se ponen espacios ni antes ni despues del signo igual. El nombre puede ser cualquier serie de caracteres alfabéticos (A-Z, a-z), numéricos (0-9) o el caracter de guión bajo ‘_’, pero el primer caracter no puede ser un número, lo siguiente son asignaciones válidas:

$ A=5
$ Mi_Nombre=Redy
$ JC45="Esto es un valor"
$ _T_65=Hola

Estas no valen:

$ 5jK=67 #(El nombre de la variable no puede empezar por un número)
$ A-47=Hola #(El nombre de la variable no puede tener signos, solo letras números y '_')
$ A = 7 #(No se pueden dejar espacios entre la variable y el '=' ni entre el '=' y el valor)
$ NombreCompleto=Redy Rodriguez #(Si el valor lleva espacios hay que usar comillas o escape)

Las letras mayusculas y minusculas en los nombres de variables son diferenciadoras, no es lo mismo A=7 que a=7, son dos variables distintas.

Otra cosa… podemos definir varias variables en la misma orden:

$ A=5 B=6 C=hola

Para obtener el valor de un parámetro, o de un variable, el bash utiliza un mecanismo de expansión, que funciona de manera similar a las expansiones vistas hasta ahora. Cuando bash encuentra en una palabra el signo ‘$’ todo lo que va a continuación se considera el nombre de un parámetro, y todos los caracteres desde el ‘$’ hasta el final de la palabra son sustituidos por el valor contenido en el parámetro (o variable) con dicho nombre.

$ A=Curso
$ B="Redy Rodríguez"
$ echo este $A lo escribe $B
este Curso lo escribe Redy Rodríguez
$ C=mente
$ echo este $A normal$C lo escribe $B
este Curso normalmente lo escribe Redy Rodríguez

Como ves el $ no tiene porque aparecer siempre al principio de la palabra, en este caso no hay ningun problema porque está al final de la palabra. Pero cuando queremos hacer una expansión de variable en medio de una palabra surge un problema: no sabemos donde acaba el nombre de la variable. Por ejemplo, esto no funcionaría como esperamos.

$ A=Normal
$ echo $Amente $B escribe este curso
Redy Rodríguez escribe este curso

Como después de $A no acaba la palabra, bash se cree que el nombre de la variable es ‘Amente’ y como esa variable no tiene ningún valor se sustituye toda la palabra por una cadena vacía. Para evitar este problema podemos recurrir a encerrar el nombre de la variable entre llaves. $A y ${A} significan exactamente lo mismo y se expanden igual pero con la segunda forma las llaves delimitan el nombre y así podemos ponerla en medio de otra palabra:

$ echo ${A}mente $B escribe este curso
Normalmente Redy Rodríguez escribe este curso

La sustitución de parámetros funcionará incluso dentro de expresiones encerradas entre comillas dobles, pero no entre comillas simples. Veamos ejemplos:

$ Nombre=Redy Apellido=Rodriguez
$ echo "Me llamo $Nombre $Apellido"
Me llamo Redy Rodriguez
$ echo 'Si pongo $Nombre $Apellido obtengo:' "$Nombre $Apellido"
Si pongo $Nombre $Apellido obtengo: Redy Rodriguez
$ Directorio=/home/
$ ls $Directorio

Aunque todo lo que hay dentro de las comillas es una sola palabra, ya ves que no es imprescindible usar las llaves cuando el nombre de la variable va seguido de un blanco o de otro signo que no pueda formar parte del nombre. Las llaves solo son imprescindibles cuando no se pueda interpretar dónde acaba el nombre de la variable, pero ante la duda, si las pones no pasa nada, solo el trabajo de teclear dos caracteres de mas.

La expansión de parámetros tendrá efecto en cualquier parte de una orden, incluso en el comando (esto puede sorprender a quienes conocéis otros lenguajes de programación), o en la propia asignación a la derecha del igual:

$ Comando="ls -l"
$ $Comando

$ Comando=ls
$ Argumento=-l
$ $Comando $Argumento

$ MeLlamo="$Nombre $Apellido"
$ Echo Me llamo $MeLLamo
Me llamo Redy Rodriguez

No obstante no se podrá usar a la izquierda del igual en una asignación. Lo siguiente no le asignará un valor a la variable A5 y dará error:

$ NombredeVariable=A5
$ $NombredeVariable='Valor de la variable'

La asignación de variables se puede hacer en la misma orden en la que se ejecuta un comando: de esta forma:


$ DISPLAY=:0 xgamma 1,2


Pero en ese caso la variable tiene un carácter temporal, y solo tendrá ese valor durante la ejecución de ese comando, volviendo a tomar al finalizar al valor antiguo. Intentaré demostrar esto:


$ A=0 B=3
$ A=1 B=5 eval 'echo $A $B'
1 5
$ echo $A $B
0 3


¿Porque uso eval ‘echo $A $B’ en lugar de un simple echo $A $B? Muy sencillo: Analicemos como funciona bash. Primero divide la línea en palabras y hace las expansiones, y luego ejecuta el comando. Si pusiera:


$ A=1 B=5 echo $A $B


Lo primero que se haría sería sustituir $A y $B por sus valores que inicialmente eran 0 y 3. Luego ejecutaría el comando, que consiste por una parte en asignar a la variable A y B unos nuevos valores y a continuación ejecutar el comando echo con dos parámetros que previamente se habían expandido a 0 y a 3. No era eso lo que queríamos ¿verdad?. Al encerrar entre comillas simples $A y $B no se expanden en un principio, pero cuando se ejecuta el comando eval si. (El comando eval lee la cadena que le pasamos como argumento y se la pasa al bash para que la ejecute como si se la hubiésemos tecleado.) ¿Se ha entendido esto? Hay que tener muy claro como funciona bash si no queremos tener extrañas sorpresas que parecen ir contra la lógica.

Dialogando con los scripts: El comando read

Un comando muy interesante y que funciona con variables es read. Este comando permite leer lo que tecleamos y lo almacena en una o varias variables. Veamos como funciona en un script:

#! /bin/bash
#
# Este script ilustra el uso del comando read
#
echo -n "¿Como te llamas? "
read NOMBRE
echo "Hola $NOMBRE; encantado de conocerte."

Lo guardamos como saluda2 en nuestra carpeta ~/bin y le damos permiso de ejecución.

$ saluda2
¿como te llamas? Redy
Hola Redy; encantado de conocerte.
El parámetro -n de echo sirve para que no salte a la línea siguiente tras escribir lo que le decimos. El read lee lo que le tecleamos hasta que pulsamos <enter> y lo almacena en la variable NOMBRE. Podríamos haber puesto el equivalente a estas dos líneas en una sola usando el argumento -p en el read. La palabra que sige a -p se mostrará en pantalla antes de leer del teclado. Modifiquemos nuestro script:

#! /bin/bash
#
# Este script ilustra el uso del comando read
#
read -p "¿Como te llamas? " NOMBRE
echo "Hola $NOMBRE; encantado de conocerte."

A veces nos interesa que read lea varios valores. Si después del read no ponemos ningun nombre de variable todo lo que tecleamos hasta pulsar <enter> se almacenará en la variable $REPLY. Si ponemos una sola variable se almacenará en esa variable, pero si ponemos varias irá tomando las palabras que le tecleemos (en el sentido que bash entiende las palabras) y almacenará la primera palabra en la primera variable, la segunda en la segunda variable, y así hasta la última. Si tecleamos más palabras que variables, la última variable contendrá todas las palabras que queden hasta el <enter> Y si tecleamos menos palabras que variables las últimas variables quedarán vacías.

#! /bin/bash
#
# Este script ilustra el uso del comando read
#
read -p "¿Cual es su nombre y apellido? " NOMBRE APELLIDO
echo "Encantado de conocerle sr. $APELLIDO."
echo "D. $NOMBRE, se nota que es usted una persona distinguida."

También podemos especificarle al read un tiempo máximo de espera. Si el usuario no le teclea nada después de ese tiempo finaliza (con error). Esto de los errores lo veremos más adelante. Para especificarle el tiempo pondremos -t y un valor en segundos como argumentos. (el || exit del final es para que no continúe en caso de error, ya lo veremos más adelante también).

#! /bin/bash
#
# Este script ilustra el uso del comando read
#
read -t 20 -p "¿Cual es su nombre y apellido? " NOMBRE APELLIDO || exit
echo "Encantado de conocerle sr. $APELLIDO."
echo "D. $NOMBRE, se nota que es usted una persona distinguida."

Ahora el script hace lo mismo, salvo que tiene ‘menos paciencia’, si tardas más de 20 segundos en contestar a su pregunta se cansa y termina.

Parámetros posicionales:

Otra manera de pasarle información a nuestros scripts es usando argumentos. Hasta ahora solo ejecutábamos el script sin más pero, a los scripts, al igual que al resto de programas se le puede pasar argumentos. Supongamos que hacemos un script para rescalar una imagen a un tamaño de 1000 pixels en su lado más largo, y además si no estaba ya en jpg, convertirlo con unos valores de compresión adecuados para que no pese mucho ni pierda mucha calidad. Vamos, lo ideal para subirlo a nuestra galería de fotolibre, por ejemplo. Todo eso lo haremos con imagemagick. Yo obtengo muy buenos resultados para hacer esto, con bastante buena calidad y no demasiado peso del archivo con el comando:

$ convert -filter Lanczos -resize 1000x1000 -sharpen 1x0.75 -blur 1x0.5 -quality 85 -strip -sampling-factor 2x2 -compress JPEG IMAGEN-ORIGINAL IMAGEN_RESCALADA.jpg

Suelen salir, dependiendo de la foto ficheros de no más de 200K en los que no se nota la pérdida de enfoque que produce el rescalado y creo que normalmente no genera artefactos. Si alguien tiene un sistema con el que se consigan mejores resultados que lo diga. Claro que el comando es un poco largo para recordarlo de memoria y para escribirlo entero cada vez que queremos redimensionar una foto ¿no? Así que ¿que os parece si hacemos un script que le llamemos ‘pasubir’ por ejemplo y que haga todo esto por nosotros con la imagen que le digamos?
Como cada vez vamos a hacer el proceso con una imagen distinta habrá que encontrar una manera de decirle al script la imagen que queremos tratar. Pues para eso están los argumentos. Si ejecutamos

$ pasubir imagen.tif

Estamos pasando un argumento al script. Podemos pasar varios. Luego en el script estos argumentos podemos leerlos consultando lo que llamamos parámetros posicionales. $1 será el primer argumento que hemos pasado, $2 el segundo $3 el tercero y así hasta $9. Si queremos ir más allá del 9 hay que poner ${10}, ${11} etc… En nuestro caso concreto con el 1 nos apañamos.

#! /bin/bash
#
# Este script convierte una imágen (si no lo está ya) a jpg y 
# la rescala a un máximo de 1000 pixels por su lado más largo. 
# la imágen de destino se llamará igual que la original pero añadiendo 
# al nombre el sufijo '_escalado.jpg'
# 
convert -filter Lanczos -resize 1000x1000 -sharpen 1x0.75 \
             -blur 1x0.5 -quality 85 -strip -sampling-factor 2x2 \
             -compress JPEG $1 $1_escalado.jpg

Ya expliqué lo de escapar los retornos de cario ¿no?. Si, lo dije en la entrega 3. Para los despistados lo repito: “Si pones un escape justo antes de dar al intro, anulas el efecto del intro, y se continúa introduciendo el comando en la siguiente línea, pero al final se tratará como si fuese una sola línea, esto puede ser útil para teclear líneas largas.” Para bash no es ningún problema que las líneas sean largas, pero cuando editamos un script las líneas largas se hacen incómodas de leer, así que porque no partirlas en varias, poniendo un caracter de escape ‘\’ justo al final de la línea. Mucho cuidad de no dejar espacios después del ‘\’ porque si lo hacemos escapamos el espacio y no el intro ¡eh!

Hala como ejercicio propongo mejorar el script para que no solo rescale al tamaño de 1000 pixels sino que seamos nosotros quienes le digamos el tamaño que queremos. ¿que os parece?

]]> http://redy.fotolibre.net/2007/10/26/curso-de-bash-para-fotografos-linuxeros-6-variables-y-parametros/feed/ 0 http://redy.fotolibre.net/2007/10/22/curso-de-bash-para-fotografos-linuxeros-5-hola-mundo/ http://redy.fotolibre.net/2007/10/22/curso-de-bash-para-fotografos-linuxeros-5-hola-mundo/#comments Mon, 22 Oct 2007 12:53:38 +0000 Redy http://redy.fotolibre.net/como/curso-de-bash-para-fotografos-linuxeros-5-hola-mundo/ Me estuve planteando que para hacer más ameno el curso deberíamos empezar ya a hacer scripts. (Ya sé que la palabra script no existe en castellano pero decir guiones o cualquiera de sus sinónimos no me parece adecuado, así que, y con la venia, seguiré diciendo script aun consciente de que no es correcto). Primero Seguir leyendo «Curso de bash para fotógrafos linuxeros. (5) Hola mundo»
]]>


Me estuve planteando que para hacer más ameno el curso deberíamos empezar ya a hacer scripts. (Ya sé que la palabra script no existe en castellano pero decir guiones o cualquiera de sus sinónimos no me parece adecuado, así que, y con la venia, seguiré diciendo script aun consciente de que no es correcto).
Primero pensé que como había que trabajar con los permisos de ejecución se hacía imprescindible explicar antes lo de los permisos en linux, y de hecho escribí un artículo sobre los permisos pero al terminar lo vi tan ‘infumable’ que no me atrevo a publicarlo. Ahora he retomado el asunto de explicar los scripts, y cuando haya que hablar de permisos daré unas breves nociones pero sin meterme a fondo. Quizá más adelante volvamos sobre el tema, para ver el tema de los permisos a fondo, pero de momento no lo considero imprescindible.

Hola mundo

Para los que nunca habéis hecho un curso de programación, decir que eso de ‘Hola Mundo’ es el primer ejemplo de programa que se suele poner para aprender a programa en cualquier lenguaje. Un programa tan simple que lo único que hace es imprimir una frase en la pantalla, la frase más manida es por supuesto ‘Hello World’ o su traducción ‘Hola Mundo’.

En bash no es necesario hacer un programa para sacar una frase por pantalla, si con un simple comandito de una línea ya está.

$ echo "Hola Mundo"
Hola Mundo


Pero claro con eso no aprenderíamos lo que es un script. Un script de bash no es más que una secuencia de comandos contenidos en un fichero de texto, cada uno en una línea, que la shell interpreta y ejecuta uno tras otro (salvo que haya instrucciones que indiquen una secuencia distinta claro).

Nuestro primer script solo tendrá una linea. Todavía tenemos la carpeta ‘ejercicios_curso_bash’ que creamos en el capítulo anterior, vamos a utilizarala, primero nos situamos y borramos todos los archivos que hay en ella. Asegurate con el comando ‘pwd’ de cual es tu directorio de trabajo antes de hacer el ‘rm -f *’. Esa órden borra todos los ficheros de la carpeta de trabajo, y no quiero sorpresas.
$ cd ~/ejercicios_curso_bash
$ pwd
/home/redy/ejercicios_curso_bash
$ rm -f *
Abre tu editor de textos favorito, crea un fichero nuevo con el siguiente texto:

echo "Hola Mundo"

Guardalo en la susodicha carpeta con el nombre ‘saluda’

En lo sucesivo todos los scripts que ponga irán en recuadros como el de arriba. El texto aparecerá en colorines, al estilo de como aparece en muchos editores que resaltan la sintaxis del lenguage. Que sepas que cuando veas un recuadro así, son las líneas que debes teclear (bueno también ‘se vale’ copiar y pegar venga…) en tu editor de textos, para que queden grabadas en el script (no te preocupes si los colores son distintos o si en tu editor no sale el texto coloreado, eso depende del editor.)

Ahora vamos a decirle a bash que ejecute ese script:

$ bash saluda
Hola Mundo

Si tu script saludo no dice ‘Hola Mundo’ tenemos un problema. ¿Has escrito exactamente lo que yo decía? ¿Lo has guradado con el nombre ‘saluda’ en la carpeta ‘~/ejercicios_curso_bash’? ¿Era esa carpeta tu directorio de trabajo cuando le mandaste ejecutarlo?.

Comentarios

Un comentario en un programa es un texto que no forma parte de las instrucciones, no será interpretado por el ordenador a la hora de ejecutar o de compilar el programa, simplemente se pone para que cuando un programador lea el programa, le sirva de aclaración de algun aspecto o detalle importante.
Dicen los grandes programadores que el buen código no los necesita, que si un programa está bien escrito se entiende tan bien que cualquier comentario sobra. Y ahora me viene a la mente una frase de Martin Fowler, un experto en desarrollo y metodología del software, que dice que: “Any fool can write code that a computer can understand. Good programmers write code that humans can understand” (Cualquier necio puede escribir código que un ordenador puede entender. Los buenos programadores escriben código que los seres humanos podemos entender). Como ni yo, ni posiblemente tu tampoco , somos de esa pequeña minoría que se pueden llamar buenos programadores, será mejor que pongamos en nuestro código algún comentario y quizá así nos sea más fácil entender luego el espagueti que hemos liado (Bueno vale, el hola mundo se entiende bien sin comentarios, pero tiempo al tiempo… Mejor irnos acostumbrando a ponerlos.).
En bash los comentarios se ponen mediante el signo ‘#’. Cuando bash encuentre en un comando una palabra que comience por el signo ‘#’ ignorará todo lo que haya desde ese signo hasta el final del comando (final de línea).

$ echo Hola Mundo # Esta órden saludara a todo el mundo
Hola Mundo

Aunque lo más usual es que en un script el # se ponga al principio de la línea y entonces toda la línea es un comentario, ya ves que no tiene porque ser así, y que justo a continuación de un comando y en la misma línea podemos poner un # para clarificar algo. Evidentemente el # no tendrá efecto entre comillas, ni en medio de una palabra:

$ echo "Hola Mundo # Esto también sale"
Hola Mundo # Esto también sale
$ echo Hola Mundo Es#to también sale
echo Hola Mundo Es#to también sale
Ahora que ya sabemos comentar vamos a poner bonito nuestro script: ábrelo con tu editor favorito y modifícalo para que quede tal que así:

# saluda versión 1.0
#        Programa para aprender como confeccionar un primer script en bash
#        Autor: _pon tu nombre aquí_
#        Se permite la reproducción bajo los términos de la licencia GPL y patatín patatán
#
echo "Hola Mundo" 
# Fin del programa

Guárdalo, y tendrás una nueva versión del script que hace exactamente lo mismo pero queda como más ‘pofesional‘ ¿no?
$ bash saluda
Hola Mundo

Hacer que sea un programa ejecutable

Si ahora miramos, con el comando file, qué es nuestro script ‘saluda’, veremos que el sistema lo reconoce como un simple archivo de texto ASCII.

$ file saluda
saluda: Non-ISO extended-ASCII text

Solo nosotros sabemos que es un script de bash. Y por tanto la única manera de ejecutarlo es diciéndole al bash que lo abra como un script, tal como hicimos arriba.
Vamos a mejorar un poco todo esto: podemos convertir nuestro script en un programa más del sistema que el kernel sepa ejecutar, y así solo tendremos que invocarlo por su nombre como un comando más. Para hacer esto solo es necesario un par de retoques:
En la primera línea del programa, añadiremos un comentario especial que comienza siempre por ‘#!’ y un espacio en blanco, luego ponemos el nombre de ruta del intérprete que va a ejecutar ese script, en nuestro caso ‘/bin/bash’.
Cuando al kernel le ordenamos ejecutar un fichero de texto cuya primera línea está formada siguiendo esa regla, en realidad ejecutará el intérprete pasándole como argumento el nombre del script (exactamente igual que hacíamos nosotros con el comando ‘bash saluda’). En este caso, como el script se llama ‘saluda’ y la primera línea es ‘#! /bin/bash’, ejecutará lo equivalente a teclear ‘/bin/bash saluda’. Editemos pues nuestro script para añadirle esa línea:

#! /bin/bash
# saluda versión 1.0
#        Programa para aprender como confeccionar un primer script en bash
#        Autor: _pon tu nombre aquí_
#        Se permite la reproducción bajo los términos de la licencia GPL y patatín patatán
#
echo "Hola Mundo" 
# Fin del programa

Ahora ya es un script de bash para el sistema:

$ file saluda
saluda: Bourne-Again shell script text executable

Solo falta otro detalle hay que darle permiso de ejecución. El sistema de permisos en Linux se basa en un esquema de usuarios/grupos que lo convierte en la base principal de la seguridad en Linux, a estos usuarios y grupos se les asignan distintos derechos sobre los archivos y directorios. Cada archivo pertenece a un usuario y a un grupo. Un archivo puede tener permiso de lectura, de escritura y de ejecución, si no tiene el permiso de lectura no podremos leerlo, si no tiene el de escritura no podremos modificarlo y si no tiene el de ejecución no podrá ser ejecutado, que es lo que nos interesa. Veamos como funciona, si haces:
$ ls -l
Te saldrá algo como esto:
-rw-r--r-- 1 redy redy 264 oct 22 10:07 saluda
El tercer y cuarto campos (con los valores ‘redy’ y ‘redy’ en mi caso) son el usuario propietario del fichero y el grupo al que pertenece el fichero. Un fichero pertenece normalmente al usuario que lo crea y al grupo de ese usuario. Solo el root puede cambiar el propietario de un fichero. Pero el propietario puede cambiarle los permisos. Las letras y guiones que aparecen en el primer campo son los permisos. Bueno, la primera letra es el tipo de elemento dentro del sistema de archivos, una ‘d’ indicará que es un directorio y un ‘-’ que es un fichero (hay otras como ‘b’, o ‘c’ para dispositivos, ‘l’ para enlaces simbólicos…). Los 9 caracteres a continuación y en grupos de tres en tres son los permisos; por este orden: permisos para el propietario, permisos para el grupo y permisos para el resto. Cada grupo de permisos indica lo que puede hacer el individuo en cuestión con ese fichero. Y las tres letras que pueden aparecer en cada grupo de permisos por este órden son r (Read: lectura), w (Write: escritura) y x (eXecute: ejecución). Si aparece la letra es que el permiso está concedido y si aparece un ‘-’ en su lugar es que no. ¿Vaya lío? Veámoslo en el ejemplo de arriba: Tenemos -rw-r–r– si quitamos el primer ‘-’ que indica que es un fichero y lo dividimos de tres en tres nos queda rw- r– r– lo cual indicará que los permisos para el usuario redy (que es el propietario del fichero) son rw- (lectura y escritura). Los permisos para cualquier otro usuario que pertenezca al grupo redy serían los tres siguientes r– (lectura). Y para el resto de usuarios del sistema también serían r– (lectura). Es decir que a pesar de que es reconocido por el sistema como un script de bash ejecutable, nadie puede ejecutar el fichero porque nadie tiene permiso para ello. Para modificar los permisos se usa el comando chmod. Normalmente a chmod se le pasan dos argumentos el primero indica los permisos que queremos modificar, y el segundo el nombre del fichero. Para indicar los permisos que queremos modificar pondremos el signo ‘+’ para darlo o ‘-’ para quitarlo seguido de la letra del permiso (‘r’, ‘w’, o ‘x’). Opcionalmente podremos poner antes del signo las letras ‘u’ (usuario), ‘g’ (grupo) u ‘o’ (otros) para indicar a quien queremos conceder o denegar ese permiso, si no ponemos esa letra o ponemos la ‘a’ (de all) se asignará o quitará el permiso para todos.
Entonces, para darle permiso de ejecución a nuestro fichero, tenemos que hacer:

$ chmod +x saluda
ls -l
-rwxr-xr-x 1 redy redy 264 oct 22 10:07 saluda


Ahora que tiene permiso de ejecución y en su primera línea se le indica al kernel como debe manejarlo, ya es un programa, y para ejecutarlo solo hace falta escribir como un comando su nombre de ruta

$ ~/ejercicios_curso_bash/saluda
Hola Mundo

Como ~/ejercicios_curso_bash es nuestro directorio de trabajo, y si volvemos a lo explicado hace un par de entregas eso puede representarse con una ruta relativa con un simple punto (‘..’ era el directorio padre y ‘.’ el propio directorio, ¿recuerdas?), podemos teclear simplemente:

$ ./saluda
Hola Mundo

Y ya para darle el último toque. Hay una serie de directorios dónde suelen ponerse los programas. Al sistema se le indica dónde debe buscar los programas en caso de que nosotros no indiquemos la ruta completa, mediante una variable (pronto veremos esto de las variables, paciencia). Solo comentar que si pones el comando:
$ echo $PATH
/usr/local/bin:/bin:/usr/bin:/usr/X11R6/bin:/usr/games:/home/redy/bin

Obtendrás la lista (separados por ‘:’) de todos los directorios dónde se buscan programas para ejecutarlos. Si ponemos nuestro programa en uno de esos directorios ya no será necesario especificar su nombre de ruta completo para ejecutarlo, sólo el nombre, como si fuera uno de tantos programas o utilidades de nuestro sistema. Claro que en esa lista no tendremos permiso de escritutra en la mayoría de los directorios… Veamos (No intentes entender el siguiente comando de momento, que sepas simplemente que nos sirve para ver en que directorios de los dichos podemos escribir):
$ ls -ld $(echo $PATH |tr ":" " ")
drwxr-xr-x 2 root root 4096 nov 20 2006 /bin/
drwxr-xr-x 2 redy redy 4096 oct 18 08:17 /home/redy/bin/
drwxr-xr-x 3 root root 61440 sep 21 13:53 /usr/bin/
drwxr-xr-x 2 root root 4096 abr 25 12:48 /usr/games/
drwxr-xr-x 2 root root 4096 sep 13 08:19 /usr/local/bin/
drwxr-xr-x 3 root root 4096 sep 27 07:54 /usr/X11R6/bin/


En la lista de los que a mi me salen, resulta que todos pertenecen al root y solo tienen permiso de escritura para el propietario, excepto el /home/redy/bin que pertenece a redy y también tiene permiso de escritura solo para el propietario. Vaya ese soy yo, luego ahí puedo escribir, lo cual, dicho de un directorio significa que puedo meter cosas dentro de él. Apuesto a que tu tienes uno igual pero, obviamente, sustituyendo ‘redy’ por tu nombre de usuario. Puedes trasladar el script ‘saluda’ a ese directorio con el comando mv.

$ mv saluda /home/redy/bin
$ saluda
Hola Mundo

¡Funciona!
Recuerda que si quieres editarlo de nuevo, ahora ya no está en ~/ejercicios_curso_bash sino en ~/bin

]]> http://redy.fotolibre.net/2007/10/22/curso-de-bash-para-fotografos-linuxeros-5-hola-mundo/feed/ 0 http://redy.fotolibre.net/2007/10/02/curso-de-bash-para-fotografos-linuxeros-4-las-llaves-y-los-comodines/ http://redy.fotolibre.net/2007/10/02/curso-de-bash-para-fotografos-linuxeros-4-las-llaves-y-los-comodines/#comments Tue, 02 Oct 2007 10:04:55 +0000 Redy http://redy.fotolibre.net/como/curso-de-bash-para-fotografos-linuxeros-4-las-llaves-y-los-comodines/ La expansión de llaves Lo primero que hace bash al analizar una orden es separarla en palabras, luego comprueba si alguna de las palabras debe ser expandida. Hay ciertas expresiones que son expandidas cuando bash las analiza para producir un resultado distinto a lo que hemos escrito. Lo primero que analiza bash es si alguna Seguir leyendo «Curso de bash para fotógrafos linuxeros. (4) Las llaves y los comodines»
]]>



La expansión de llaves

Lo primero que hace bash al analizar una orden es separarla en palabras, luego comprueba si alguna de las palabras debe ser expandida. Hay ciertas expresiones que son expandidas cuando bash las analiza para producir un resultado distinto a lo que hemos escrito. Lo primero que analiza bash es si alguna palabra contiene expresiones entre llaves ‘{}’. Te gustará este tipo de expansión porque sirve para escribir menos. Básicamente la expansión de llaves convierte una palabra en tantas como expresiones pongamos entre las llaves separadas por comas.


echo {1,2,3,4,5,6}
1 2 3 4 5 6


Visto así no parece muy práctico ¿no? bueno déjame continuar… Antes y después de las llaves puedes poner un prefijo y/o un sufijo, pero siempre formando una única palabra, en ese caso se combinará prefijo y sufijo, con cada uno de los elementos.

echo cant{o,as,a,amos,áis,an}
canto cantas canta cantamos cantáis cantan
echo {lenta,rápida,inmediata}mente
lentamente rápidamente inmediatamente
echo co{mun,tidiana}mente
comunmente cotidianamente


Cuando tengas soltura en bash, te verás escribiendo cosas como: ‘convert fichero.{jpg,png}’ en lugar de ‘convert fichero.jpg fichero.png’

Algunos elementos de la expansión pueden estar vacíos:

echo esta{,ba,tatica}
esta estaba estatatica


Si en una palabra aparecen varias llaves se expanden sucesivamente. Por ejemplo echo prueba{1,2}{a,b} primero se expandiría la primera llave quedando dos palabras 'prueba1{a,b} prueba2{a,b}' Como cada una de las palabras generadas sigue teniendo una llave se volverían a expandir, dándo como resultado cuatro palabras: 'prueba1a prueba1b prueba2a y prueba2b'

También se pueden anidar unas llaves dentro de otras:

$ echo hola{1{a,b,c},2,3{d,e}}
hola1a hola1b hola1c hola2 hola3d hola3e


A partir de la versión 3 de bash (La que tendréis la mayoría), también se pueden poner intervalos numéricos en la expansión de llaves. {3..9} es equivalente a {3,4,5,6,7,8,9}. {0..999} generará mil palabras 0 1 2 … 998 999. En cambio si queremos generar 000 001 002 … 998 999 tendremos que poner {0..9}{0..9}{0..9}

La expansión solo funciona a nivel de palabras. Y nunca dentro de comillas (ni simples ni dobles). Si queremos incluir espacios en la expansión hay que evitar que dividan la palabra con el caracter de escape o con comillas pero sin que estas afecten a las llaves.

$ echo hola {Juan,Carlos,Jose Manuel}
hola {Juan,Carlos,Jose Manuel}
$ echo "hola {Juan,Carlos,Jose Manuel}"
hola {Juan,Carlos,Jose Manuel}
$ echo hola {Juan,Carlos,"Jose Manuel"}
hola Juan Carlos Jose Manuel
$ echo hola\ {Juan,Carlos,Jose\ Manuel}
hola Juan hola Carlos hola Jose Manuel
$ echo "hola "{Juan,Carlos,"Jose Manuel"}
hola Juan hola Carlos hola Jose Manuel


En el primer caso no se expande nada porque la llave de abrir y la de cerrar están en palabras distintas. En el segundo caso están en la misma palabra pero tampoco se expande porque dentro de unas comillas nunca se raliza la expansión de llaves. En el tercer caso se hace la expansión pero solo de las llaves ya que hay un espacio que separa la palabra ‘hola’.
En los dos últimos utilizamos el escape y las comillas para hacer la expansión correctamente.

La expansión de nombres de ruta. Patrones, comodines…

Después de la expansión de llaves y siempre antes de ejecutar una orden el bash comprueba si alguna palabra contiene algún carácter de estos: ‘*’, ‘?’ y ‘[' y si es así la considera como un patrón. Un patrón es una palabra que se expande a todos los nombres de ruta que concuerden con él antes de ejecutar la orden. A los caracteres que tienen un significado especial dentro de un patrón les llamamos caracteres comodín

Al igual que pasaba con la expansión de llaves, dentro de un par de comillas, ya sean simples o dobles jamás se hace esta sustitución, así que si queremos usar alguno los caracteres comodín literalmente, sin que se produzca la expansión podemos bien encerrarlo entre comillas o bien usar el caracter de escape.

Cuando una palabra contiene un comodín bash busca en nuestro sistema de ficheros todos los nombres de ruta que concuerdan con esa palabra patrón. Si encuentra concordancias la palabra es sustituida por todos los nombres que concuerden. Esto quiere decir que una palabra puede convertirse en varias antes de ejecutar la orden. Si ningún nombre concuerda se deja la palabra tal cual estaba y el caracter o caracteres comodín pasan a considerarse caracteres completamente normales.

Pero te estarás preguntando ¿que es eso de concordar? ¿Como funcionan exactamente los comodines?. El caracter '?' en un patrón significa cualquier caracter. Así que si ponemos en una órden la palabra '/usr/bin/?c', por ejemplo, se buscarían todos los nombres de ruta que comiencen con '/usr/bin/' luego tengan un caracter cualquiera y finalmente una 'c', que seguramente habrá varios, y se sustituirá la palabra que contenía el comodín por todos los nombres de ruta que se han encontrado. Personalmente me sale:


echo /usr/bin/?c
/usr/bin/bc /usr/bin/cc /usr/bin/dc /usr/bin/gc /usr/bin/mc /usr/bin/nc /usr/bin/wc


Se puede usar varias veces un comodín (o varios) en la misma palabra, por ejemplo:


echo /usr/bin/?a?
/usr/bin/cal /usr/bin/dat /usr/bin/fax /usr/bin/mag /usr/bin/man /usr/bin/pan /usr/bin/rar /usr/bin/raw /usr/bin/tac


Evidentemente en tu ordenador puedes obtener resultados distintos, porque no todos tendréis una instalación exactamente igual que la mía.

El comodín '*' en un patrón significa ninguno, o más caracteres cualquiera. Es decir concordará con cualquier secuencia de caracteres de cualquier longitud, incluso con ningún caracter. Ejemplos:

$ echo /usr/bin/col*
/usr/bin/col /usr/bin/colcrt /usr/bin/colormap /usr/bin/colrm /usr/bin/column
$ ls *.jpg
$ du -c f-*.jpg


Los que estáis familiarizados con el interprete de comandos de MS/DOS o Windows, debeis tener mucho ojo con la expansión de nombres, porque puede resultar muy parecido a como el DOS trata sus patrones (formados por los caracteres llamados comodines * y ?), pero es sustancialmente distinto, para comparar os pondré un ejemplo, si en MS/DOS o Windows ponemos en la línea de comando:

EDIT *.TXT


El command.com (o el cmd.exe) no hace nada, simplemente llama al programa edit y le pasa como argumento '*.TXT' es EDIT quien tras analizar el argumento entiende que es un patrón que puede designar múltiples ficheros y lo expande. Hay comandos que nunca expanden los nombres de fichero y otros que sí...

En bash, (y en las shells de UNIX en general), es la shell la que hace la expansión, y si escribo por ejemplo:

$ gimp *.jpg


La shell encuentra el *, sabe que designa un patrón y busca todos los ficheros que concuerden con ese patrón, supongamos que hay tres y que son: foto1.jpg, foto2.jpg y foto3.jpg. La orden se convierte, pues, antes de ser ejecutada en:

$ gimp foto1.jpg foto2.jpg foto3.jpg

Y el gimp recibirá tres argumentos y no uno como el EDIT en el ejemplo anterior. Esto que parece trivial hay que tenerlo muy claro, y suele desembocar (entre otros) en un error que muchos novatos en Linux que veníamos de DOS habremos cometido alguna vez, el error de usar el cp o el mv sin destino. Como anécdota voy a explicarlo ya que además de servirnos para ilustrar como funciona la expansión de nombres, te puede evitar algún disgusto:

Para los que hicimos nuestros 'pinitos' en DOS antes de pasarnos a Linux, conocemos perfectamente como funcionan los comandos COPY y MOVE del DOS. Copy (en DOS) copia uno o varios ficheros a un destino. Necesita normalmente dos parámetros, origen y destino, el origen puede ser un directorio, un fichero o un patrón que concuerde con varios ficheros. El destino puede ser otro fichero, o un directorio; pero puede omitirse. Si se omite se tomará como destino el directorio actual.

Supongamos que estamos en MS/DOS (o Windows) y el directorio actual es '\Mis Documentos' en la unidad C y en la unidad A tenemos varios fotos (.jpg) que queremos copiar a nuestro directorio actual, es suficiente con que tecleemos:
Copy a:\*.jpg

Veamos el mismo caso en Linux y concretamente con bash:

El comando para copiar es cp, cp siempre espera al menos dos argumentos: un origen y un destino. Si recibe más de dos argumentos, entiende que todos son orígenes excepto el último que es el destino, si hay más de un fichero origen, el destino debe ser un directorio. El comando cp no entiende de comodines ni de patrones es la shell quien tiene que darle todo expandido.

Ignorantes de estas premisas y acostumbrados a MS/DOS, si en Linux queremos hacer lo mismo del ejemplo anterior, es decir, nos encontramos en nuestro directorio home y queremos copiar a él todos los ficheros .jpg que hay en un diskette, es necesario poner origen y destino. Por desgracia, creyendo que bash es como el command.com, traducimos el comando copy a:\*.jpg
por lo que nos parece lo más equivalente que es:

$ cp /mnt/floppy/*.jpg

¿Que puede ocurrir? Si tenemos la suerte de que en el disquete hay más de dos ficheros .jpg, el bash expande los nombres de fichero en orden como:
$ cp /mnt/floppy/foto1.jpg /mnt/floppy/foto2.jpg /mnt/floppy/foto3.jpg

El comando cp (al menos en las versiones modernas del cp que suele venir con Linux) ve que hay más de dos parámetros, y como el último no es un directorio, nos da un error diciendo que no se puede copiar varios ficheros sobre uno solo, y que el destino tiene que ser un directorio. (En otros UNIX o en versiones muy antiguas de cp, puede que ni siquiera nos de el error y copie los dos primeros ficheros sobre el último).

Pero si tenemos la desgracia de que el disquete solo tiene dos ficheros .jpg (fatal coincidencia), el comando cp después de que bash expanda los nombres de fichero recibirá dos parámetros como si hubiésemos tecelado:
$ cp /mnt/floppy/foto1.jpg /mnt/floppy/foto2.jpg

Y como eso es perfectamente válido copia la foto1 sobre la foto2, machacando el contenido de la segunda. Así que mucho ojo, que esto no es MS/DOS. El directorio de trabajo actual se designa (tal como vimos cuando hablábamos de los nombres de ruta) por un punto, así que lo que debieramos haber hecho es:

$ cp /mnt/floppy/*.jpg .

Así nos evitaríamos algún que otro disgusto. Otra diferencia sustancial es que por para DOS/Windows el patrón '*.*' designaba a todos los ficheros del directorio de trabajo. En bash '*.*' solamente designa a aquellos fichero que contienen un punto en su nombre para designar a todos debemos emplear simplemente '*'

Hay otro comodín que no tiene equivalente en DOS que es una serie de caracteres entre corchetes '[...]‘ (paréntesis cuadrados), y que concuerda con uno cualquiera de dichos caracteres, por ejemplo [afj]* concordará con cualquier fichero que comience por las letras a, f ó j. En vez de los caracteres uno a uno también se puede especificar un rango indicando el carácter inicial y el final separados por un guión como [a-z] o [0-9] que concordarán con cualquier letra minúscula o cualquier número respectivamente. Si queremos que el propio guión ‘-’ sea uno de los caracteres de la serie debemos ponerlo al principio o al final, ya que si va entre dos caracteres delimitará un rango. Si queremos que el propio ‘]’ que se usa para marcar el final del conjunto forme parte de la expresión hay que ponerlo al principio de todo.

Ejemplos de patrones con este comodin:

• [a-fA-F]* cualquier fichero que comience por una letra desde la a hasta la F bien sea en mayúsculas o minúsculas.
• *[0-9]* cualquier fichero que contenga un número.
• *[0-9].txt cualquier fichero cuyo nombre termine en un número seguido de un punto y las letras ‘txt’
• ??[1-9][0-9]* Cualquier fichero que comience por dos caracteres cualesquiera, seguidos de dos números (y que el primero no sea un cero), y cualquier serie de caracteres después.
• *[0-36-9]* Cualquier fichero que tenga un número del 0 al 3 o del 6 al 9 en su nombre.
• *.[jJ][pP][gG] Cualquier fichero que termine en .jpg ya sea en mayúsculas, minúsculas o cualquier combinación de mayúsculas y/o minúsculas.

Si el rango, o la serie de caracteres empieza por ^ o por ! se entenderá que es cualquier
caracter fuera de ese rango o serie: Si queremos poner cualquiera de esos dos caracteres en una serie, los pondremos en una posición que no sea la primera

• [^0-9]* Cualquier fichero excepto los que empiezan por un número.
• [^a-zA-Z]* Cualquier fichero que no comience por una letra.

Hay que hacer notar que cuando empleamos rangos, se tiene en cuenta la ordenación alfabética de nuestra configuración regional. Esto es realmente importante porque en casi todos los lenguajes la ordenación alfabética no tiene en cuenta mayúsculas y minúsculas. Quiere esto decir que si ponemos, [a-z] por ejemplo y dependiendo de la configuración regional que tengamos puede coincidir con las mayúsculas y las minúsculas, o incluír la ‘ñ’ o las vocales acentuadas. Ya que en la configuración regional van alfabéticamente en ese rango. Para que la comparación de rangos sea estricta, y no tenga en cuenta la ordenación regional sino el órden de caracteres del código ASCCI se debe establecer la variable de entorno LC_COLLATE=C. Como las variables, el entorno y esas zarandajas las veremos más adelante, sólo os indico como hacerlo, no os preocupéis si no lo entendéis de momento. Para consultar de acuerdo a que reglas se está ordenando, pondremos poner:

$ echo $LC_COLLATE
es_ES


En mi caso me indica que estoy usando el método de ordenación alfabética de es_ES que es español de España. Podría ser es_AR si estás en argentina, o es_MX para Mexico, o en_US para English – USA, o fr_FR para Francia o fr_BE para francés de Bélgica, fr_CA para francés de Candá, o en_CA para ingles de Canadá. Nuestros idiomas autonómicos se codifican normalmente como ‘gl’ para gallego ‘ca’ para catalan o ‘eu’ para euskera, sin variantes de país aunque es posible que en alguna distribución aparezcan como gl_ES, ca_ES, o eu_ES, lo cual no me parece muy correcto. Estos son unos códigos definidos por el estándar POSIX, que dice que: ‘Los códigos de idioma y país se deben definir juntos. El idioma sigue la norma ISO 639-1. Los códigos de países están definidos en la norma ISO 3166‘. El código de lenguaje ‘C’ así sin más indica que se seguirá el orden numérico del código ASCII (Bueno en realidad del código de caracteres que estemos usando, normalmente en una distribución linux moderna será el UTF-8). Para cambiar el código de lenguaje utilizado para la ordenación se usará el siguiente comando, poniendo después del igual el código que nos interese que se utilice para las reglas de ordenación. Este cambio tendrá efecto durante toda esa sesión de bash, o hasta que lo cambiemos de nuevo:

$ export LC_COLLATE=C


Vamos a experimentar un poco todo esto. Primero crearemos un directorio para hacer pruebas, luego lo poblaremos con unos cuantos ficheros (vacíos, que para el caso es lo mismo), y sobre ellos usaremos distintos patrones para que entiendas como funciona el asunto.


$ cd ~
$ mkdir ejercicios_curso_bash
$ cd ejercicios_curso_bash
$ touch fichero{1,8,9,0,_,a,c,C,F,Ñ,ñ}.txt
$ touch {123,345,685}{b,j,A,BcD,JJ}.{dat,dit,zip,jpg,Jpg,JPEG}
$ touch {A,B,C,a,b,f,á,é,í,ñ,Ñ}{ABC,abc,def}
$ touch {A,á,Z,z,Ñ.Ñ}' '{ABC,abc,def}
 
$ echo 1???.dat
123A.dat 123b.dat 123j.dat
$ echo 1*.dat
123A.dat 123BcD.dat 123b.dat 123j.dat 123JJ.dat
$ echo 1*.d?t
123A.dat 123A.dit 123BcD.dat 123BcD.dit 123b.dat 123b.dit 123j.dat 123j.dit 123JJ.dat 123JJ.dit
$ echo 1*
123A.dat 123A.dit 123A.JPEG 123A.jpg 123A.Jpg 123A.zip 123BcD.dat 123BcD.dit 123BcD.JPEG 123BcD.jpg 123BcD.Jpg 123BcD.zip 123b.dat 123b.dit 123b.JPEG 123b.jpg 123b.Jpg 123b.zip 123j.dat 123j.dit 123JJ.dat 123JJ.dit 123JJ.JPEG 123JJ.jpg 123J
J.Jpg 123j.JPEG 123j.jpg 123j.Jpg 123JJ.zip 123j.zip
$ echo f*
fabc fABC fdef fichero0.txt fichero1.txt fichero8.txt fichero9.txt ficheroa.txt ficheroc.txt ficheroC.txt ficheroF.txt fichero±.txt ficheroÐ.txt fichero_.txt
$ echo f*.*
fichero0.txt fichero1.txt fichero8.txt fichero9.txt ficheroa.txt ficheroc.txt ficheroC.txt ficheroF.txt fichero±.txt ficheroÐ.txt fichero_.txt
$ echo *.jpg
123A.jpg 123BcD.jpg 123b.jpg 123JJ.jpg 123j.jpg 345A.jpg 345BcD.jpg 345b.jpg 345JJ.jpg 345j.jpg 685A.jpg 685BcD.jpg 685b.jpg 685JJ.jpg 685j.jpg
$ echo 3*.[jJ]pg
345A.jpg 345A.Jpg 345BcD.jpg 345BcD.Jpg 345b.jpg 345b.Jpg 345JJ.jpg 345JJ.Jpg 345j.jpg 345j.Jpg
$ echo 3*.[jJ][pP]*[gG]
345A.JPEG 345A.jpg 345A.Jpg 345BcD.JPEG 345BcD.jpg 345BcD.Jpg 345b.JPEG 345b.jpg 345b.Jpg 345JJ.JPEG 345JJ.jpg 345JJ.Jpg 345j.JPEG 345j.jpg 345j.Jpg
$ export LC_COLLATE=C
$ echo fichero[a-z].txt
ficheroa.txt ficheroc.txt
$ echo fichero[A-Z].txt
ficheroC.txt ficheroF.txt
$ export LC_COLLATE=es_ES
$ echo fichero[a-z].txt
ficheroa.txt ficheroc.txt ficheroC.txt ficheroF.txt ficheroñ.txt ficheroÑ.txt
$ echo fichero[a-f].txt
ficheroa.txt ficheroc.txt ficheroC.txt
$ echo fichero[A-Z].txt
ficheroc.txt ficheroC.txt ficheroF.txt ficheroñ.txt ficheroÑ.txt

Con el método de ordenación, establecido como ‘C’ en el rango [a-z] sólo coincidirán las letras minúsculas del código ascii (descartando eñes, vocales acentuadas, etc), en cambio con el método de ordenación es_ES, parece que obtendremos coincidencias en todas las letras mayúsculas y minúsculas del alfabeto español. Si ponemos el rango en mayúsculas [A-Z] con el LC_COLLATE=C coincidirá con todas las letras mayúsculas del código ASCII, como era de esperar. En cambio con es_ES no tamos que no sale la ‘a’ minúscula. Esto tiene una sencilla explicación: Como hay que darle un órden a todos los caracteres, se decidió que primero irían las letras minúsculas, luego las mayusculas, luego (en el caso de las vocales) las acentuadas, primero en minúscula y luego en mayúscula, Más o menos así: aAábBcC…nNñÑ…uUúü…zZ Visto así está claro que en el rango [a-z] nos dejamos fuera la ‘Z’ mayúscula y en el rango A-Z nos dejamos fuera la ‘a’ minúscula. O en el rango [a-f], como podemos apreciar en el ejemplo, la ‘F’ mayúscula queda fuera. Parece algo trivial pero hay que tenerlo en cuenta si no queremos sorpresas trabajando con rangos

Además de listas de caracteres y rangos, bash reconoce los siguientes nombres especiales de clase, que irán siempre entre otros corchetes (además de los corchetes de rango) y símbolos de dos puntos.

• [:alpha:] Coincide con cualquier letra.
• [:digit:] Coincide con cualquier dígito numérico decimal.
• [:xdigit:] Coincide con cualquier digito hexadecimal, es decir los numeros 0-9 y las letras A-F que pueden ser mayúsculas o minúsculas.
• [:alnum:] Coincide con cualquier letra o número decimal.
• [:punct:] Cualquier signo de puntuación.
• [:lower:] Cualquier letra minúscula.
• [:upper:] Cualquier letra mayúscula.
• [:ascii:] Cualquier caracter del conjunto ascii de 7 Bits.
• [:blank:] Cualquier caracter de espaciado, es decir los espacios y los tabuladores.
• [:cntrl:] Cualquier caracter de control.
• [:print:] Cualquier caracter imprimible incluyendo los espacios.
• [:graph:] Cualquier caracter imprimible sin incluir los espacios.

Como los rangos, estas clases dependen del LC_COLLATE que tengamos seleccionado. Por ejemplo con es_ES, la letra Ñ o las vocales acentuadas o la u con diéresis pertenecerán a la clase :alpha:, en cambio con fr_FR la Ñ no estará en la clase :alpha: pero si estará la C con cedilla ‘Ç’ o las vocales con acento grave o circunflejo.

Por ejemplo:


$ echo fichero[[:digit:]aC]*


Mostrará todos los ficheros que comiencen con la palabra fichero, y contengan bien un
número o las letras ‘a’ minúscula o ‘C’ mayúscula a continuación.

$ ls -1 *[[:blank:]]*


Mostrará todos los ficheros o directorios que tengan algun espacio en su nombre. Este lo pongo con el comando ls -1 para que salga cada uno en una línea porque si los pongo con un simple echo saldrían todos segudos y no se distinguiría cuales son los espacios dentro del nombre de los que separan unos nombres de otros.

Patrones extendidos

Además de los patrones normales existen los denominados patrones extendidos, pero normalmente no funcionarán porque suelen estar desactivados por defecto en bash. Los comodines normales, que acabamos de ver en detalle, aunque potentes, se quedaban algo escasos para algunas cosas, así que en la versión 2 de bash se implementó esta nueva expansión de nombres de ficheros. Pero para mantener compatibilidad hacia atrás, esta expansión solo funciona si se activa previamente, de no hacerlo así los nuevos caracteres podrían hacer que un script que funcionaba correctamente en bash 1.x tuviese un extraño comportamiento en el bash 2.x. Aclarado esto, para que funcionen los patrones extendidos de expansión de nombres de ficheros hay que activarlos previamente (en cada sesión) con la orden:

$ shopt -s extglob

Después de esa orden:

• ?(patrón) concordará con una o ninguna ocurrencia del patrón dado. Por ejemplo texto?([0-9]).txt concordará con texto.txt, texto1.txt, texto3.txt, pero no con texto12.txt
• *(patrón) concordará con ninguna o más ocurrencias del patrón dado. Por ejemplo texto*([0-9]).txt concordará con texto.txt, texto1.txt, texto3.txt, texto12.txt y texto12345.txt pero no con texto1a.txt
• +(patrón) concordará con una o más ocurrencias del patrón dado. Por ejemplo texto+([0-9]).txt concuerda con texto1.txt, texto3.txt, texto12.txt y texto12345.txt pero no con texto.txt
• @(patrón) concuerda solo con una ocurrencia del patrón. Por ejemplo texto@([0-9]).txt concuerda con texto1.txt, pero no con texto12.txt ni con texto.txt
• !(patrón) Concuerda con cualquier cosa que no concuerde con el patrón. Por ejemplo texto!([0-9]).txt concordará con textoa.txt, textob.txt, texto19.txt o texto.txt, pero no con texto4.txt

En la evaluación de patrones extendidos, entre los paréntesis podemos poner un patrón simple o una lista de ellos separados por el caracter ‘|’, en caso de poner una lista coincidirá con cualquier cosa que coincida con cualquiera de los patrones de la lista.

Para volver a desactivar los patrones extendidos hay que usar

$ shopt -u extglob

¿Serías capaz de escribir un patrón que concordase con todos los ficheros que comenzaran con ‘img-’ seguidos de una serie de números, y después de un punto las extensiones jpg o jpeg teniendo en cuenta que tanto el img inicial como la extensión al final pueden aparecer en minúsculas, mayúsculas o cualquier combinación de mayúsculas y/o minúsculas? Puedes usar patrones extendidos.

]]> http://redy.fotolibre.net/2007/10/02/curso-de-bash-para-fotografos-linuxeros-4-las-llaves-y-los-comodines/feed/ 0 http://redy.fotolibre.net/2007/09/26/curso-de-bash-para-fotografos-linuxeros-3-usando-las-comillas/ http://redy.fotolibre.net/2007/09/26/curso-de-bash-para-fotografos-linuxeros-3-usando-las-comillas/#comments Wed, 26 Sep 2007 15:28:28 +0000 Redy http://redy.fotolibre.net/como/curso-de-bash-para-fotografos-linuxeros-3-usando-las-comillas/ Uso de comillas y otros caracteres especiales Decíamos hace unos días que el bash era un ‘interprete de comandos’, cuya misión es analizar lo que le tecleamos e interpretarlo para ordenarle al sistema operativo lo que debe hacer. Para interpretarlo las órdenes lo primero que hace es dividirlas en palabras. Cuando bash encuentra un espacio Seguir leyendo «Curso de bash para fotógrafos linuxeros. (3) Usando las comillas»
]]>



Uso de comillas y otros caracteres especiales

Decíamos hace unos días que el bash era un ‘interprete de comandos’, cuya misión es analizar lo que le tecleamos e interpretarlo para ordenarle al sistema operativo lo que debe hacer. Para interpretarlo las órdenes lo primero que hace es dividirlas en palabras. Cuando bash encuentra un espacio en blanco lo entiende como un separador de palabras. Veremos más adelante que el espacio no es el único separador y que además puede cambiarse el caracter que actúa como separador, pero por ahora nos quedaremos con que el espacio separa palabras y que da lo mismo que pongamos uno o varios.

A veces es necesario que los espacios no actúen como separadores. Supongamos que estuvimos retocando una foto con el gimp y la hemos guardado con el nombre ‘Foto de mi amigo juan.jpg’, el propio nombre del fichero contiene espacios. Ahora queremos ver cuanto ocupa ese fichero en el disco, porque el servidor al que vamos a enviarla no admite ficheros de más de 600Kb. Podríamos usar la orden ‘du’ (disk usage) seguida del nombre del fichero, pero si escribimos:

$ du Foto de mi amigo juan.odt

El bash encuentra los espacios y los entiende como separadores, divide la línea en 6 palabras y toma la primera como un comando y las otras cinco como los argumentos que debe pasarle a ese comando. Evidentemente el comando ‘du’, que espera recibir como argumentos nombres de fichero o de directorio, nos dirá que no encuentra el fichero ‘Foto’, ni el fichero ‘de’, ni tampoco ‘mi’, ni ‘amigo’, ni por supuesto ‘juan.odt’.

En este caso concreto una solución es entrecomillar el nombre del fichero.

$ du 'Carta para mi amigo juan.odt'

Todo lo que bash encuentre entre dos comillas simples lo considerará como una sola palabra. El conflicto podría venir si el nombre fichero fuese “Don’t Cry For Me Argentina by Synead o’Connor.mp3″, y me explico: al interpretar el comando:

$ du 'Don't Cry For Me Argentina by Synead o'Connor.mp3'

Bash empareja primero las comillas simples: La primera se empareja con la que hay entre la D y la t de Don’t, y la que hay en o’Connor se empareja con la última, y por la mitad nos quedan un montón de espacios sin entrecomillar que delimitan las palabras Cry, For, Me…

En casos así podemos usar las comillas dobles. Entre comillas dobles los espacios y otros separadores, y las comillas simples pierden su significado como delimitadores. Y entre comillas simples los espacios, las comillas dobles y todos los caracteres especiales también pierden todo su significado. Más adelante veremos que en realidad las comillas simples son ‘más duras’; ya que hay ciertos caracteres especiales que pierden su significado dentro de ellas pero no dentro de las dobles, pero eso sería anticipar acontecimientos. Por ahora solo quiero que quede claro que ambas nos sirven para lo mismo, para agrupar en un solo argumento palabras que de otro modo estarían separadas. Así que creo que todo funcionará como queremos si escribimos:

$ du "Don't Cry For Me Argentina by Synead o'Connor.mp3"

Otro caso en el que las comillas nos resultarían muy útiles podría ser este:

$ echo Hola        Pepe
Hola Pepe

El comando ‘echo’ escribe en pantalla todos los argumentos que se le pasan, es como un loro que repite lo que le dices (o mejor como el eco). En este caso recibe dos argumentos, y los muestra uno a continuación
del otro. Sin embargo:

$ echo "Hola        Pepe"
Hola        Pepe
$ echo 'Hola        Pepe'
Hola        Pepe

En estos dos casos hay un único argumento, que contiene varios espacios en blanco, y se muestra tal cual.

Ya que las comillas más exteriores siempre que sean de otro tipo anulan el efecto de las interiores, los ejemplos siguientes son todos formas válidas de representar palabras que contienen en si mismas los caracteres de comillas simples o dobles:

$ echo "Este curso se titula 'Curso de bash para fotógrafos linuxeros'"
$ echo 'Este curso se titula "Curso de bash para fotógrafos linuxeros"'
$ echo "Ese programa es de Mc'Affe"
$ echo 'Ponlo entre comillas (")'

Pero no podemos meter una comilla doble entre comillas dobles o una simple entre simples, así sin más, porque se entendería que ha finalizado el bloque entrecomillado. Si fuese necesario poner comillas dobles dentro de un bloque encerrado entre comillas dobles podríamos recurrir al carácter de escape. El carácter de escape es el ‘\’ (no confundir con la tecla escape ¡eh!) y cuando lo ponemos hace que el carácter que va inmediatamente a continuación, si tenía un significado especial, lo pierda y sea tratado como un carácter normal perteneciente a la palabra en la que está contenido.


$ echo o\'Donell
$ echo "Estás leyendo el \"Curso de bash para fotógrafos linuxeros\""


Pero, ojo, dentro de comillas simples el propio caracter de escape pierde su significado y se comporta como un caracter normal, por lo tanto no tiene efecto. Mejor dicho: Entre comillas simples todo lo que pongamos se toma como un caracter normal, nada tiene significado especial. Ni siquiera se puede evitar que otra comilla simple sirva de cierre poniéndole un escape antes. Entre comillas dobles el escape (\) tiene significado especial sólo si va seguido de uno de estos dos símbolos: la propia comilla doble o del propio escape. (Bueno, también del dólar “$” o de la comilla invertida “`”, pero de esos hablaremos a su debido tiempo)

$ echo 'El caracter de escape es \'
El caracter de escape es \

Prueba estos comandos…


$ echo 'Entre comillas simples nada se interpreta "\"'
$ echo "Entre comillas dobles el escape \" \ \' \\ se interpreta a veces \c"
$ echo "Escape \, Comilla doble \", comilla simple '"
$ echo "Escape escapado para que no anule la última comilla \\"
$ echo 'Dentro de comillas simples el escape \\ nunca funciona \'
$ echo Fuera de comillas \c \" \' \ \\ el escape siempre se interpreta.
$ echo "Entre comillas dobles \c \" \' \ \\ sólo si va antes de \" \` \$ ó el propio \\."


No podemos poner

$ echo 'Ese programa es de Mc\'Affe'

porque la comilla de después del escape no perdería su significado, y sería interpretada como el final de la expresión entrecomillada.

El escape lo puedes usar incluso con los espacios u otros separadores, si pones un escape antes de un espacio, éste no funcionará como separador.


$ ls /mnt/windows/Mis\ Documentos


Si pones un escape justo antes de dar al intro, anulas el efecto del intro, y se continúa introduciendo el comando en la siguiente línea, pero al final se tratará como si fuese una sola línea, esto puede ser útil para teclear líneas largas.

$ echo esto \\
  es una \\
  sola línea
esto es una sola línea

Si ponemos un escape antes de un carácter que no tenía ningún significado especial no pasa nada, simplemente se ignora el carácter de escape.

$ echo \Hola
Hola


Si queremos que el propio caracter de escape pierda su significado y sea tratado como un caracter literal, podemos encerrarlo entre comillas simples, como ya vimos, o también lo podemos escapar

$ echo "En DOS los directorios se separan con esta barra \\"
En DOS los directorios se separan con esta barra \


Hasta ahora hemos usado las comillas para encerrar palabras completas, pero no tiene porque ser así, podemos ponerlas solo para encerrar una parte de la palabra, y mientras no haya un separador (espacio) fuera de ellas todo seguirá siendo la misma palabra. Me explico: En estas dos expresiones solo entrecomillamos los espacios, y como las comillas está pegada al resto de la palabra, todo sigue siendo una sola palabra.


$ echo Hola"        "Pepe
Hola        Pepe
$ echo Hola'        'Pepe
Hola        Pepe

Podemos combinar todo esto como queramos. La siguiente orden sólo tiene un argumento, ¿sabrías explicar porqué?:

$ du Don"'"t\ Cry" "For' 'Me' Argentina by Synead 'o\'Connor.mp3


]]> http://redy.fotolibre.net/2007/09/26/curso-de-bash-para-fotografos-linuxeros-3-usando-las-comillas/feed/ 0 http://redy.fotolibre.net/2007/09/19/curso-de-bash-para-fotografos-linuxeros-2-empezamos-a-meternos-en-harina/ http://redy.fotolibre.net/2007/09/19/curso-de-bash-para-fotografos-linuxeros-2-empezamos-a-meternos-en-harina/#comments Wed, 19 Sep 2007 17:46:12 +0000 Redy http://redy.fotolibre.net/fotolibre/curso-de-bash-para-fotografos-linuxeros-2-empezamos-a-meternos-en-harina/ Algunos conceptos importantes sobre directorios y ficheros en Linux. Aunque no sean cosas específicas de bash, ni de la shell, y como el curso es para principiantes se hace imprescindible ir comentando ciertos aspectos del sistema operativo, así como los comandos y utilidades más usuales, y que todo usuario que maneje la shell debe conocer. Seguir leyendo «Curso de bash para fotógrafos linuxeros. (2) Empezamos a meternos en harina»
]]>



Algunos conceptos importantes sobre directorios y ficheros en Linux.

Aunque no sean cosas específicas de bash, ni de la shell, y como el curso es para principiantes se hace imprescindible ir comentando ciertos aspectos del sistema operativo, así como los comandos y utilidades más usuales, y que todo usuario que maneje la shell debe conocer. Porque ambas cosas van ligadas, shell y sistema operativo. Como estamos empezando el curso empiezo por lo más básico, así que a los que ya tengáis bastante soltura con el sistema, puede que estos conceptos ya os suenen algo, o mucho, o que incluso los tengáis dominadísimos, pero bueno, yo creo que un repasito nunca viene mal.

Bajo la mayoría de sistemas operativos (incluyendo por supuesto a linux), existe el concepto de fichero. Un fichero es simplemente un conjunto de información con un nombre. Cualquier documento que guardamos dándole un nombre es un fichero. La foto que le hice el otro día a mi sobrino y que le he llamado ‘Damián.jpg’ es un fichero. El curriculum que escribí para ver si me admitían en la empresa Benito y compañía, y al que llamé ‘Curriculum para Benito Y Cia.odt’ también. El vídeo ese que edité de la cámara de video y que grabé como ‘Cumpleaños de Ada.mpg’ también es un fichero.

Para mayor comodidad los ficheros se organizan en directorios. Un directorio no es más que una colección de ficheros. Puede entenderse (y de hecho así se simboliza en la mayoría de entornos gráficos) como una ”carpeta” que puede contener muchos ficheros diferentes. Los directorios también tienen nombres, con los que se les identifica. Además, los directorios se mantienen en una estructura de tipo árbol; es decir, los directorios pueden contener otros directorios.

Por tanto decimos que un fichero tendrá siempre un nombre y estará contenido en un directorio. Y puede haber otro fichero distinto que tenga el mismo nombre en otro directorio, pero nunca en el mismo.

Podemos referirnos a un fichero o a un directorio por su ‘nombre de ruta’, esto es un nombre que nos indica cual es el nombre del elemento (fichero o directorio), y que esté precedido por el nombre de ruta del directorio que lo contiene, para separar los nombres de los distintos elementos que componen un nombre de ruta se utiliza un caracter separador. Como seguramente ya sabrás, los nombres de ruta en Linux, utilizan el caracter ‘/’ como separador, igual que en las URL de internet, en lugar del ‘\’ que usa Windows o DOS. El nombre de ruta de un elemento (ya sea de un fichero o de un directorio) lo identifica de manera unívoca entre todos los demás elementos del sistema informático. No puede haber dos elementos con el mismo nombre de ruta.

Para verlo como un ejemplo la foto de mi sobrino, a la que llamé ‘Damián.jpg’ la había guardado en un directorio que se llamaba fotos, y que estaba dentro de mi directorio personal que se llama redy, que a su vez está en el directorio donde el sistema guarda normalmente los directorios personales de todos los usuarios, y que se llama home. Por lo tanto el nombre de ruta de la foto será ‘/home/redy/fotos/Damián.jpg’

Es importante decir que a diferencia de otros sistemas operativos en Linux los nombres de fichero y de directorio (como casi todo) son, como dirían los anglosajones ‘case sensitive‘, es decir que no es lo mismo /usr que /Usr que /USR, así que mucho ojo a como escribimos.

También hay que decir que en muchos sistemas operativos existe un concepto que son las unidades, cada disco, o partición de un disco, cada medio de almacenamiento (diskette, cd, dvd, pendrive, tarjeta de memoria sólida… ) tiene un nombre de unidad y dentro de esa unidad hay un árbol de ficheros y directorios. En linux y la mayoría de los unix ese concepto no existe, todos los árboles de todas las unidades están formando ramas de un único arbol cuyo comienzo está en lo que llamamos directorio raíz, que no tiene nombre y tiene como nombre de ruta un único caracter ‘/’ sin nada más.

En cualquier sesión de la shell existe un concepto que es el directorio de trabajo. Podemos consultar y cambiar el directorio de trabajo a nuestro antojo, si mencionamos el nombre de un fichero sin especificar su nombre de ruta se entiende que nos referimos al fichero de ese nombre que se encuentra en el directorio de trabajo.

Para consultar cual es el directorio de trabajo usaremos el comando pwd (print working directory)
$ pwd
/home/redy

Para cambiarlo podemos usar el comando cd (change directory) seguido del nombre de ruta del directorio al que queremos cambiar. Nuestro directorio de trabajo por defecto al iniciar una sesión de shell será nuestro directorio personal generalmente ‘/home/nombre_de_usuario’. Como ese es un nombre de ruta muy usado tiene una abreviatura. Es lo mismo escribir la olilla ‘~’ que poner la ruta de nuestro directorio personal. (La olilla ‘~’ en teclado español en la mayoría de los Linux se obtiene pulsando <Alt-Gr> y la tecla de abrir admiración ‘¡’, o también <Alt-Gr>Ñ ). Así que en mi caso será lo mismo escribir ‘cd /home/redy’ que escribir ‘cd ~’. Y concretamente en el comando cd hay todavía una forma más sencilla de ir a nuestro directorio personal que es escribir el comando cd sin ningun argumento.

cd /etc
pwd
/etc
cd
pwd
/home/redy

Claro que si queremos hacer algo temporalmente en otro directorio para luego volver al que estábamos, igual nos es más útil usar pushd y popd. El comando pushd hace lo mismo que cd pero ‘recuerda’ dónde estaba antes de cambiarse, de tal manera que luego solo tenemos que hacer un popd para volver al directorio de dónde partimos. pushd siempre requiere un argumento, el nombre del directorio al que queremos cambiar, popd no requiere argumentos, regresará siempre al directorio donde estábamos antes del último pushd que ejecutamos. Se pueden anidar todos los pushd que se quieran. Se puede consultar la lista dónde pushd va guardando los directorios con el comando dirs. Se trata de una lista de las que los informáticos conocemos como ‘pila’ o ‘lista LiFo’ (Last in First out: El último en entrar será el primero en salir). Estas listas se comportan como si fuese apilando cosas, de ahí el nombre de ‘pila’. Imagina una pila de platos: a medida que vas poniendo platos la pila va creciendo, y cuando quieres coger un plato coges el de arriba de todo que fue el último que pusiste. Pues esta lista es igual, los elementos se añaden por el principio de la lista de tal manera que cada vez que haces un pushd el directorio de trabajo antiguo se añade al principio de la lista y los demás elementos que ya tenía quedan a continuación. Cuando se hace un popd se quita el primer elemento de la lista (que en realidad es el último que se ha metido) y se restablece el directorio de trabajo a donde indica ese elemento.

$ pwd
/home/redy
$ pusd /usr/bin
$ pwd
/usr/bin
$ pushd /usr/share
$ pwd
/usr/share
$ dirs
/usr/share /usr/bin ~
$ popd
$ pwd
/usr/bin
$ popd
$ pwd
/home/redy


Nombres de ruta absolutos y relativos al directorio de trabajo

En linux (y UNIX) si un nombre de ruta comienza con la barra ‘/’, se entiende que nos referimos al elemento (ya sea un fichero o un directorio) que designa dicho nombre de ruta de forma absoluta; es decir es el camino entero a seguir desde el directorio raíz. Por el contrario, si no empieza con ‘/’ se entiende que lo hacemos de forma relativa al directorio de trabajo, en el que nos encontramos. Así ‘/usr/bin’ denomina siempre al directorio bin que hay dentro del directorio usr que a su vez cuelga del directorio raíz. Mientras que ‘bin’ puede designar al directorio /usr/bin si n nuestro directorio de trabajo es /usr o a /usr/local/bin si el directorio de trabajo fuese /usr/local. Si hablamos de ficheros es exactamente lo mismo, se puede uno referir a un fichero dando su nombre de ruta de forma absoluta o relativa al directorio de trabajo. Así fichero.txt se entiende que está en el directorio de trabajo, mientras que /tmp/fichero.txt designa siempre al fichero.txt que se encuentra en el directorio /tmp

existen dos nombres de elemento un poco especiales: el elemento ‘..’ se utiliza para
referirnos al directorio padre, y ‘.’ para referirnos al directorio actual.
Así si por ejemplo te encuentras en el directorio /home/redy ‘..’ será el
directorio /home y ‘.’ será el mismo directorio ‘/home/redy’. Si usamos estos elementos en nombres de rutas podemos recorrer hacia arriba nuestro arbol a nuestro antojo. Por ejemplo estando en el mismo /home/redy el nombre relativo ../ada/fotos será /home/ada/fotos. O suponiendo que nuestro directorio de trabajo en un momento dado es /usr/share/icons/hicolor
../../../bin será /usr/bin. No es práctico pero algo como fotos/../fotos/./../fotos/. es un nombre de ruta válido que recorre hacia arriba y hacia abajo nuestro árbol para dejarnos en el mismo sitio dónde estábamos.

Directorios usuales en linux:

• / Es el directorio raíz, todo cuelga de él.
• /bin En este y otros directorios llamados bin es donde normalmente se encuentran los programas ejecutables.
• /sbin En este y otros directorios llamados sbin es donde normalmente se encuentran las utilidades para administrar el sistema.
• /dev En este directorio se encuentran unos ficheros especiales que sirven para comunicarse con los diversos dispositivos de hardware que puede haber en nuestro PC.
• /etc Aquí es donde se guardan los ficheros de configuración globales.
• /home Es donde residen los directorios personales de cada usuario.
• /lib Se guardan aquí las bibliotecas de enlazado dinámico, que contienen funciones y rutinas comunes y reutilizables, y que son usadas por muchos programas.
• /mnt Es donde se suelen montar los diversos dispositivos de almacenamiento, como diskettes o CDROMS, u otros discos duros etc… en algunas distribuciones los dispositivos removibles se montan en /media en lugar de en /mnt
• /opt En algunas distribuciones aquí se instalan componentes opcionales.
• /tmp para guardar los archivos temporales.
• /usr Contiene más o menos los mismos directorios que el raiz, hay un bin, un sbin, un lib etc… los ficheros que no son imprescindibles en el arranque están aquí, mientras que los imprescindibles cuelgan del raíz. Esto es así porque el sistema puede estar en una unidad de red, pero tiene que tener en un disco local al menos lo mínimo para arrancar, acceder a la red y montar el resto del sistema en /usr.
• /var Aquí se almacenan varios ficheros, como las colas de impresión y de correo, los ficheros de log, etc…
• /usr/local Reproduce de nuevo la estructura del raíz y de /usr, y al igual que estos también suele contener un bin, un lib, un etc… en /usr/local van normalmente los ficheros que compilamos a partir del código fuente en nuestra máquina, para distinguirlos de los que se instalan con la distribución, que ya vienen compilados.

Esto es un somero resumen, para informacón mas detallada podéis consultar: Estructura del Sistema de Archivos de Linux

Como obtener ayuda uno mismo

Como vamos a empezar a ver algunos comandos útiles, y yo no puedo explicar a fondo todas y cada una de sus opciones, y como sé que sois curiosos os voy a explicar como obtener mucho más información de lo que yo os voy contando en este curso.

–help

Generalmente cada comando tiene su ayuda y su pagina de manual. La mayoría de los comandos admiten el argumento –help que muestra una breve ayuda con la sintáxis de uso. Veamoslo por ejemplo con el comando chsh que usábamos en el capítulo pasado:

$ chsh --help
Uso: chsh [ -s shell ] [ --list-shells ] [ --help ] [ --version ]
[ nombredeusuario ]


Cuando nos ponen la sintaxis de un comando, se indican en paréntesis cuadrados los argumentos opcionales. En este caso todos los argumentos son opcionales quiere esto decir que podemos poner el comando chsh sin ningún argumento. Veamos otro ejemplo, el comando top no lo conocemos, se usa para ver quien consume más recursos del sistema, lo veremos más adelante pero vamos a pedirle ayuda a ver que nos dice:
$ top --help
       top: procps version 3.2.5
 usage: top -hv | -bcisS -d delay -n iterations [-u user | -U user] -p pid [,pid ...]


Aquí ya vemos cosas nuevas, veis que hay una barra vertical ‘|’ entre varias opciones. Las opciones ‘h’ y ‘v’ son de ‘help y de version’ el resto de opciones afectan a su conportamiento si le pedimos ayuda o queremos saber la versión, no queremos que se ejecute luego no procede ponerle las otras opciones. La barra vertical indica justo eso que o ponemos lo uno o lo otro, pero no ambas cosas. Dentro del paréntesis cuadrado volvemos a encontrarla [-u user | -U user] indicando que podemos usar o bine la -u minúscula o la -U mayúscula seguida siempre de un nombre de usuario pero no ambas. Al final en la opción ‘-p pid [,pid ...]‘ (pid se refiere a proccess id, identificador de proceso), nos indica que después de una p hay que poner al menos un pid y opcionalmente una lista de ellos separados por comas.

Otras veces la ayuda es tan extensa que no cabe en pantalla, prueba por ejemplo

$ ls --help

Si te ocurre esto en una terminal de texto (recuerda <Control><Alt><F1-6>) puedes usar la tecla de mayúsculas combinada con las de retroceder y avanzar página para moverte hacia atrás y hacia adelante. En una terminal gráfica generalmente también funcionan esas teclas, pero además suele tener una barra de desplazamiento para hacerlo a golpe de ratón. Otra opción cuando sabemos de antemano que no va acaber es añadir al final del comando un |more

ls --help |more

Esto hace (ya veremos gracias a que mecanismo a su debido tiempo) que la salida salga paginada. Cada página pone al final el prompt ‘–Más–’ y hace una pausa. Si pulsamos la tecla de espacio avanzamos a la siguiente página, con intro avanzamos línea a línea, y si ya hemos encontrado lo que buscábamos y no queremos seguir leyendo hasta la última página pulsamos la ‘q’ de (quit). El único inconveniente de esto es que |more siempre pagina hacia adelante no podemos ir hacia atrás. Por eso inventaron otro filtro mucho más práctico que es |less, que funciona de manera parecida a |more pero con muchísimas más posibilidades básicamente podemos usar las flechas arriba y abajo o las teclas de inicio fin avance y retroceso de página e igualmente usaremos la ‘q’ para salir.

man

El comando man invoca al manual. Si ponemos man –help nos dirá que, entre otras muchas opciones que no voy a explicar, hay un parámetro obligatorio que es el nombre de un comando. Así que podemos poner cosas como:


man ls
man chsh
man man


Como los manuales de los comandos suelen ser largos siempre se paginan (sin necesidad de ponerlo en el comando) con |more o con |less, dependiendo de la configuración de tu sistema. Lo digo por si no encuentras como salir del manual, tienes que usar la ‘q’ (de quit), recuerdas…

¿Porque con algunos comandos no funciona ni man ni –help?

Bueno es complejo responder a esa pregunta. No todos los programadores le ponen un parámetro –help a sus programas. No todos adjuntan una página de manual junto con su programa. Por otra parte hay comandos que son internos del propio bash (como veremos más adelante), en este último caso la página man nos redirigirá a un breve resumen de los comandos internos de bash, y la forma correcta de obtener más ayuda es usando el comando ‘help’. Por ejemplo.

$ help pushd


Hay que hacer notar el hecho de que no todas las páginas man o las ayudas están traducidas, así que a veces obtendrás la ayuda en inglés, se están traduciendo cada vez más cosas, pero es un largo camino por recorrer.

Comandos básicos para trabajar con directorios y ficheros

• mkdir nombre_de_directorio Crea un nuevo directorio.
• rmdir nombre_de_directorio Borra un directorio, (debe estar vacío).
• cd nombre_de_ruta_de_directorio Nos lleva al directorio que digamos, haciendo que sea el directorio de trabajo, si no especificas un nombre te lleva tu directorio personal.
• pushd y popd Cambian el directorio de trabajo recordando en cual estábamos antes y regresan al directorio anterior respectivamente.
• pwd Nos dice cual es nuestro directorio de trabajo.
• ls nombre_de_ruta Muestra el contenido del directorio, si no indicamos ningún nombre muestra el contenido del directorio de trabajo, con un nombre de fichero nos sirve para saber si el fichero existe o no.
• tree [-d] nombre_de_ruta_de_directorio Muestra el contenido del directorio y de los directorios hijos en forma de árbol, si no indicamos ningún nombre muestra el contenido del directorio de trabajo, con el parámetro -d sólo muestra los directorios, sin el muestra directorios y ficheros. (Tree no está instalado por defecto en todas las distribuciones)
• touch nombre_de_fichero Si el fichero no existe lo crea vacío, si existe simplemente le cambia la fecha de modificación por la del momento en que hacemos el touch, pero sin modificar ninguno de sus datos.
• cp fichero1 fichero2 Copia el fichero uno al fichero2 si fichero2 no existe lo crea, si ya existía machaca todo su contenido.
• cp fichero1 fichero2 (etc..) directorio Copia todos los ficheros que le digamos al directorio especificado.
• mv Funciona exactamente igual que cp, solo que mueve los ficheros en vez de copiarlos, (es decir el fichero original se borra), sirve también para renombrar.
• rm fichero [fichero2 ...] Borra el o los fichero especificado.
• cat fichero [fichero2 ...] Muestra el contenido del o los fichero.
• more fichero Nos permite ver el contenido de un fichero largo que no cabe en pantalla e ir pasando página a página.
• less fichero Nos permite ver el contenido de un fichero, y desplazarnos por él arriba y abajo.
• file fichero Examina el fichero para identificar cual es su contenido, nos dice si es una imágen, un vídeo, un archivo de texto, etc…
• locate fichero_o_directorio Busca un directorio o un fichero en el disco.
• du Obtiene información sobre lo que ocupa un fichero o directorio en el disco.
• df Obtiene información sobre el espacio que nos queda libre en nuestro(s) disco(s).
• basename Dado un nombre de ruta de fichero quita toda la parte del directorio dejándo solamente el nombre del fichero.
• dirname Dado un nombre de ruta de un directorio quita el nombre del fichero dejándo solamente la ruta del directorio.

Editar ficheros de texto

Muchas veces, y por muy diversas razones tendremos la necesidad de editar ficheros de texto. En este curso pronto empezaremos a crear nuestros propios scripts que no son más que archivos de texto, y necesitaremos editarlos. En linux existen multitud de editores de texto tanto gráficos como de consola, y no voy a ser yo quien os diga cual debéis utilizar, el que prefiera uno gráfico tiene gedit en Gnome, kate en Kde, mousepad en xfce. Cualquier escritorio de linux cuenta entre sus utilidades con un editor de textos.

El que quiera un editor gráfico específicamente pensado para programadores tiene el scite, NEdit… La ventaja de estos es que reconocen la sintáxis de diversos lenguajes de programación y resaltan en colores los distintos elementos para que nos sea más sencillo programar, formatean el texto para que sea más sencillo identificar el principio y el final de ciertos bloques de código, o incluso permiten plegar y desplegar bloques (scite), todo ello hace que sean más cómodos para la tarea de editar scripts y programas.

Siendo como soy un amigo de la consola, lo que yo os aconsejaría sería un editor de texto que funcione en la propia consola, sin necesidad de entorno gráfico. Y no voy a entrar en una discusión sobre vi contra emacs, porque aunque los conozco no utilizo habitualmente ninguno de los dos. Yo personalmente uso joe, nano puede ser una buena opción, ne está muy bien y es sencillo de utilizar. Otro editor sencillo de usar es el mcedit, que viene con el midnight commander.

wpe (y xwpe) es un editor de texto que se acerca bastante a los editores gráficos de hecho son dos programas uno para consola de texto y otro para entorno GUI ambos prácticamente con el mismo aspecto, inicialmente estaba pensado para C pero se pueden descargar extensiones con la sintáxis de otros lenguajes (bash inclído).

Vistas las opciones (y no sólo las que yo te he contado), elige el que quieras, lo importante es que estés cómodo con él, y que sepas manejar las funciones básicas abrir un fichero guardarlo, buscar texto, cortar, pegar…

]]> http://redy.fotolibre.net/2007/09/19/curso-de-bash-para-fotografos-linuxeros-2-empezamos-a-meternos-en-harina/feed/ 0 http://redy.fotolibre.net/2007/09/18/lago-de-sanabria-zamora/ http://redy.fotolibre.net/2007/09/18/lago-de-sanabria-zamora/#comments Tue, 18 Sep 2007 14:53:52 +0000 Redy http://redy.fotolibre.net/fotolibre/lago-de-sanabria-zamora/ Un bonito parque natural, dónde se pueden pasar unos días de Relax, pena que ya se acaban las vacaciones. El Lago de Sanabria ofrece un precioso paisaje, tanto para admirarlo como para disfrutar de sus limpias aguas… El lago Visto desde el 'Mirador de la Fuente de Los Ojos', por encima del pueblo de San Seguir leyendo «Lago de Sanabria (Zamora)»
]]>


Un bonito parque natural, dónde se pueden pasar unos días de Relax, pena que ya se acaban las vacaciones.

El Lago de Sanabria ofrece un precioso paisaje, tanto para admirarlo como para disfrutar de sus limpias aguas…


El lago Visto desde el 'Mirador de la Fuente de Los Ojos', por encima del pueblo de San Martín de Castañeda




Una panorámica desde una de las playas. (La pano no está hecha con el hugin. No llevé mi cámara y las fotos están hechas con la Kodad C875, que tiene una función para hacer panorámicas, las une ella misma y la verdad es que no quedan mal… Pena que solo una tres como máximo)


El agua estaba de vicio, limpita y llena de peces, truchas creo, que nadaban sin miedo entre la gente.

Otro lago más pequeño de este parque natural, al que hay que acercarse es la Laguna de los Peces:



Esta vez la luz, las nubes y la hora eran más adecuadas que las anteriores panorámicas que hice. La cámara no era la buena, pero como ya han dicho por aquí, 'La cámara no lo es todo' ¿no?

]]> http://redy.fotolibre.net/2007/09/18/lago-de-sanabria-zamora/feed/ 0 http://redy.fotolibre.net/2007/09/16/curso-de-bash-para-fotografos-linuxeros-1-toma-de-contacto/ http://redy.fotolibre.net/2007/09/16/curso-de-bash-para-fotografos-linuxeros-1-toma-de-contacto/#comments Sun, 16 Sep 2007 09:13:51 +0000 Redy http://redy.fotolibre.net/fotolibre/curso-de-bash-para-fotografos-linuxeros-1-toma-de-contacto/ Otras shells ¿Puedo elegir que shell uso? Volvemos a remontarnos a la historia de UNIX (prometo que una vez pasada la introducción, no volveré a hacerlo), hablábamos en la entrega anterior del curso de que los primeros Unix de Bell y de AT&T incluían la shell sh de Bourne. Luego la historia de UNIX se Seguir leyendo «Curso de bash para fotógrafos linuxeros. (1) Toma de contacto»
]]>



Otras shells ¿Puedo elegir que shell uso?

Volvemos a remontarnos a la historia de UNIX (prometo que una vez pasada la introducción, no volveré a hacerlo), hablábamos en la entrega anterior del curso de que los primeros Unix de Bell y de AT&T incluían la shell sh de Bourne. Luego la historia de UNIX se bifurca desde el momento que las universidades solicitan utilizarlo y Bell les distribuye de forma abierta el código fuente. En Berkeley, comienza a gestarse BSD, BSD no usa la shell de Bourne, sino una cuyo lenguaje recuerda más a la sintaxis del lenguaje C llamada C-shell o csh. A David Korn de AT&T le gusta la sintaxis de c-shell y la mejora creando la Korn-shell o ksh. Simultáneamente la Free Software Foundation busca una shell para su sistema operativo GNU y tomando ideas de la shell de Bourne y de la Korn Shell crean Bash, ¡vaya! esta ya nos suena…

Paul Falstad por su parte cogiendo ideas de bash y de ksh crea otra shell llamada zsh. Hoy en día hay muchas shells donde elegir, sh, csh, tcsh, ksh, zsh… cada una tiene sus peculiaridades y sus ventajas, y en este curso nos centraremos en bash por ser la más usada en Linux, pero creo que era necesario citar las demás.

Un usuario de Linux normalmente puede elegir que shell utiliza, aunque como digo, por defecto suele tener la shell bash. Para cambiar de shell usaremos el comando chsh (change shell). Como sabes Linux (y Unix) es multiusuario. Cuando entramos en un UNIX o en un Linux lo normal es que el sistema nos pida un nombre de usuario y una clave, es lo que conocemos como login, el programa login comprueba que el usuario existe, y comprueba si la clave es correcta. Si lo es, mira en el fichero de configuración de usuario cual es la shell que el usuario tiene asignada, y la ejecuta.

La shell, un primer contacto

Vamos a hacer nuestras primeras pruebas con la shell, supongo que sabes abrir una shell, pero por si acaso lo explico:

Prueba a hacer login en una consola de texto de tu Linux. Si estás en un linux normalmente configurado en modo gráfico, te recuerdo que puedes ir a cualquiera de las 6 consolas de texto pulsando <Control><Alt><Fx> (siendo Fx cualquiera de las teclas F1 a F6), y volver al modo gráfico pulsando <Contro><Alt><F7>. Entendemos por ‘hacer login’ introducir el nombre de usuario y la password que se nos solicita.

También, desde el modo gráfico, puedes simplemente abrir una terminal gráfica (xterm, konsole, gnome-terminal), en este caso no se te pedirá login ya que ya estás identificado como usuario. Pero venga, que haces leyendo… ya estás tardando en probar todo lo que te he dicho…

Supongo que ya estás en la shell si es así a la izquierda del cursor seguramente habrá una frase corta seguida de un signo ‘$’, en mi caso tengo:

[redy@bbs redy]$ _

Ese es el prompt de usuario, si estás utilizando la cuenta del root en vez de un ‘$’ lo más probable es que tengas un ‘#’, es la forma que tiene la shell de avisarte que andes con cuidado con lo que haces pues puedes hacer de todo, (incluso cargarte el sistema). Normalmente todas las pruebas debemos hacerlas como usuario, a no ser que yo os indique lo contrario, así iremos más seguros.

Si estáis en Linux, lo más probable es que vuestra shell por defecto sea bash, que es a la que va destinada este curso, ¿como saberlo?, vamos a preguntárselo a la propia shell, así teclearemos nuestro primer comando del curso en la shell: escribid ‘echo $SHELL’ (sin las comillas) y darle al intro. Recordad que en Linux no es lo mismo escribir las cosas en mayúsculas que en minúsculas, hay que teclearlo exactamente como yo os lo pongo.

A partir de ahora y durante todo el curso cuando tengáis que teclear algo lo indicaré dentro de una etiqueta [code], así lo veréis con otro tipo de letra, y precedido del prompt '$' si debéis hacerlo como usuario o '#' si es necesario que hayáis hecho login como root. Ese primer caracter '$' o '#' no hay que teclearlo, es el que representa el prompt. Si hay más signos de '$' o '#' en la línea si deberéis teclearlos. Ni que decir tiene que siempre debéis acabar la línea con un intro (salvo que yo indique lo contrario).

$ echo $SHELL

Cuando quiera representar lo que os responde la shell al teclear un comando lo pondré también dentro de la etiqueta 'code' pero en otro color así será más fácil de entender que es lo que tecleáis y cual es la respuesta que se supone que debéis obtener. Por ejemplo con el comando anterior yo obtengo (y vosotros probablemente también): '/bin/bash', o sea que según lo acordado escribiré.

$ echo $SHELL
/bin/bash

Si no es eso, (o algo muy similar pero que también termina en bash) lo que habéis obtenido es que vuestra shell por defecto no es bash. ¡Oh! estamos siguiendo un curso de bash y nuestra shell por defecto no es bash. Esto hay que arreglarlo enseguida....

No os preocupéis si de momento no entendéis bien lo que significa lo que tecleamos, para eso estamos aquí, para aprender este lenguaje, pero tiempo al tiempo...

En el apartado anterior os dije que se podía cambiar la shell, el curso está pensado para la shell bash, así que si esta no es vuestra shell por defecto ya la estáis cambiando, ahora os explico como.

Para saber que shells hay disponibles en vuestro sistema debéis usar el siguiente comando:

$ chsh -l
/bin/bash
/bin/sh
/bin/tcsh
/bin/csh
/bin/ash
/bin/bsh


El resultado en vuestro caso puede diferir en función de que shells estén instaladas, el '/bin/' que precede a los nombre de la shell es el directorio donde se encuentra (puede variar en algunos casos, pero no es lo usual).

Para cambiar de shell usaremos el comando:

$ chsh
Changin shell for redy
password:


Aquí teclearemos nuestro pasword de usuario y luego nos preguntará

New shell [/bin/bash]:

A lo que le teclearemos una de las shells que obtuvimos con el comando anterior, como por ejemplo '/bin/sh' (sin las comillas ¡eh!). Si no nos equivocamos nos dirá algo como...

Shell changed.

Indicando que la nueva shell está activada, y será la que se cargue en nuestra próxima sesión, así que si estamos en una consola de texto pura (<Ctrl><Alt><F1-F6>) teclearemos:

$ logout

y volveremos a entrar con el usuario, si ahora consultamos que shell estamos usando veremos que ha sido cambiada. (Recordad que si no habéis hecho login desde una consola de texto, sino que habéis abierto vuestra sesión desde un terminal gráfico no nos sirve este método, porque al abrir un terminal gráfico no se hace login realmente. Habría que cerrar nuestra sesión gráfica y volverla a abrir desde el login).

$ echo $SHELL
/bin/sh


Otra forma de hacer lo mismo es poniendo la shell que queremos como parte de la orden de esta forma, así ya no nos la preguntará luego, lo que si os preguntará siempre es la password.

$ chsh -s /bin/bash
Changing shell for redy.
Password:
Shell changed.

Haced todas las pruebas de cambio de shell que queráis, al final dejad como shell por defecto la bash, que es en la que se centra el curso...

Ordenes simples

Ya hemos visto como la shell espera que le introduzcamos una orden, indicándonoslo con el prompt, si comparamos el lenguaje bash con el castellano, podríamos decir que cada orden es como un frase. Cada orden consta de varios elementos (palabras) y tiene significado propio, puede ser interpretada y ejecutado por la shell. Como en nuestro idioma, toda frase debe tener normalmente un verbo, en bash los verbos son los comandos, que
generalmente van al principio de la orden. También, como en nuestro idioma el elemento que separa las palabras es el espacio en blanco, y no importa si ponemos uno o varios espacios entre palabras.

Hay ordenes que no tienen más que el comando, y hay otras que llevan argumentos adicionales.

• Ejemplo de órdenes sin argumentos:

$ ls
$ jobs
$ groups

• Ejemplo de órdenes con argumentos:

$ ls /bin
$ echo "Buenos días $USER"
$ tar -zxvf archivo_comprimido.tar.gz

En todos los ejemplos que hemos visto el comando es la primera palabra de la orden, esto es siempre así exceptuando algunos casos en los que el comando se omite, por ejemplo:

$ VAR=5

En esta orden VAR no es en realidad un comando, podríamos decir que esta orden sólo tiene argumentos.

$ DISPLAY=urano.home.net:0 gedit

En esta orden el comando es gedit, y no va en primer lugar, pero esto, claro está, son excepciones.

Todos los ejemplos vistos hasta ahora son ordenes simples, también existen ordenes compuestas, que veremos con más detalle más adelante. Para formar las ordenes compuestas se usan caracteres especiales como separadores, que funcionan del mismo modo que en nuestro idioma lo hacen las conjunciones. Las conjunciones sirven de nexo de unión entre frases simples para formar una frase compuesta y estos separadores de igual manera sirven de nexo de unión entre varias ordenes simples para formar una compuesta.

Por ejemplo la siguiente orden es compuesta porque consta de tres comandos que se ejecutarán uno tras otro y siempre y cuando el anterior haya finalizado con éxito.

$ ./configure && make && make install

(No pretendas entenderlo ahora, simplemente lo pongo como ejemplo de una orden compuesta).

Argumentos

Vale, entonces y por norma general la primera palabra de una orden simple es el comando. Luego separados por espacios van los argumentos. Y ya hemos dicho que para bash es lo mismo encontrar un espacio que varios consecutivos, así las dos órdenes siguientes hacen exactamente lo mismo.

$ echo Hola Pepe
$ echo Hola      Pepe


¿Hay diversos tipos de argumentos? Pues si, esto no es algo propio de bash. En Linux normalmente distinguimos los argumentos que denotan opciones, del resto, y dentro de las opciones hay opciones de un solo carácter y opciones de varios caracteres. Esto se explica mejor con ejemplos.

• Comando simple sin argumentos

$ ls

• Comando con opciones de un solo carácter (levan delante un '-')

$ ls -a -t -l

• Si hay varias opciones de un solo carácter se pueden poner también todas juntas en forma abreviada, la orden anterior es igual que

$ ls -atl

• Opciones de varios caracteres, las opciones de varios caracteres llevan casi siempre dos '-' en vez de uno, ya que de lo contrario se podría entender que son varias opciones de un solo carácter en forma abreviada.

$ ls --color

• Otros argumentos:

$ ls /usr/bin

• O todo mezclado:

$ ls -atl --color /usr/bin

Entre las utilidades GNU suele cumplirse la regla de que las opciones de un solo caracter llevan un simple signo menos y las de varios caracteres llevan un doble signo menos. Pero no hay regla sin excepción, y en linux podemos encontrar un conjunto tan heterogéneo de utilidades que no todos los programadores la respetan y así encontraremos por ejemplo casos como el comando:

$ ps axu

en el que la a, la x y la u son ociones de un solo caracter pero que no llevan el signo menos delante. Igual que ocurre en el siguiente comando con la j, la x, la v, y la f.

$ tar jxvf fichero.tar.gz

O incluso comandos con opciones largas de varios caracteres que no llevan el doble signo menos. Por ejemplo en los siguientes comandos lo suyo es que las opciones 'resize' o 'scanbus' fuesen precedidas de doble signo menos pero no es así.

$ convert foto.jpg -resize 800x600 foto_800x600.jpg
$ cdrecord -scanbus

Ante la duda solo queda recurrir a la documentación del comando.

Introduciendo órdenes, y atajos de teclado

Hasta ahora vimos que hay un prompt, ante el que tecleamos órdenes sencillas, y cuando damos al intro se ejecutan. A partir de ahora habrá que ir trabajando con el bash, así que este es el momento de explicar más a fondo todas las posibilidades de bash a la hora de introducir órdenes, ello nos facilitará mucho la tarea...

En un Linux bien configurado, y siempre que estemos en un terminal Linux, mientras le introducimos una orden a bash, podemos movernos por ella a la izquierda o a la derecha con las teclas del cursor, o borrar con la tecla de retroceso (backspace) o con la tecla de suprimir. Esto que parece tan normal, no siempre funciona ya que podemos encontrarnos en una consola remota (accediendo por telnet o por ssh desde otra máquina) que no permite o que no tiene configuradas esas teclas de control como lo espera Linux. Eso no será ningún problema si conocemos los siguientes atajos de teclado. Procuraré acompañar las secuencias de teclas de ciertas reglas nemotécnicas, la mayoría asociadas a palabras inglesas, para que sean más fáciles de recordar. Estas reglas las pongo entre paréntesis (Generalmente si una tecla combinada con <Control> hace algo con una letra, esa misma tecla combinada con <Alt> hace lo mismo pero con una palabra.):

Aquí hay que hacer notar que en una consola de texto pura no tendremos problemas, pero si estamos en el entorno gráfico es posible que en nuestro desktop alguna de esas combinaciones de teclas esté asignada como 'hotkey', o que el emulador de terminal gráfico la asigne a algun menú. Por ejemplo en el gnome-terminal <Alt>U despliega la ayuda, con lo cual el bash jamás recibirá esa combinación de teclas orque es atrapada antes, y no tendrá el efecto esperado.

• <Control>A Ir al principio de línea (La A está al principio del alfabeto).
• <Control>E Ir la final de línea (E de End=Final).
• <Control>F Hace lo mismo que la flecha hacia la derecha, avanza un carácter
• <Alt>F Avanza una palabra (Recordad F de forward=adelante)
• <Control>B Hace lo mismo que la flecha hacia la izquierda, retrocede.
• <Alt>B Retrocede una palabra (B de Back=atrás)
• <Control>L Borra la pantalla dejando solo la línea que estamos escribiendo (L de limpiar)
• <Control>D Borra el carácter bajo el cursor como la tecla <Supr> (Delete)
• <Alt>D Borra desde el cursor hasta el final de la palabra.
• <Control>H Borra el caracter anterior al cursor.
• <Control>W Borra desde el cursor hasta principio de la palabra. (Ya sé que atendiendo a la lógica debiera ser <Alt>H pero no es así supongo que la W es por 'word': palabra ).
• <Control>K Borrar desde el cursor hasta el final de la línea (trunKar).
• <Control>U Borrar desde el cursor hasta el principio de la línea.
• <Control>Y Generalmente cuando borramos una o varias palabras o un bloque, podemos luego mover el cursor a otra posición si es necesario y volver a pegar el bloque borrado en la nueva posición con esta combinación de teclas.
• <Control>C Limpia la orden que estamos tecleando como si no hubiésemos tecleado nada (Clear=limpiar)

Estas quizá sean menos útiles, pero ahí van...

• <Alt>U Convierte a mayúsculas desde el cursor hasta el final de la palabra (Upper case=Mayúsculas).
• <Alt>L Convierte igual pero a minúsculas (Lower case=Minúsculas).
• <Alt>C Pone la letra en la que está el cursor en mayúsculas y el resto hasta el final de la palabra en minúsculas (Poner en letra Capital).
• <Control>T Intercambia el caracter sobre el que está el cursor con el inmediatamente anterior, por ejemplo si hemos escrito 'fihcero' y ponemos el cursor sobre la 'c' al pulsar esta combinación de tecla se intercambia la c con la h quedando 'fichero' (T de transponer)
• <Alt>T Lo mismo con palabras si escribimos 'Rodriguez Redy' y con el cursor en cualquier posición de la segunda palabra, pulsamos esta combinación, se intercambiarían las dos palabras quedando 'Redy Rodriguez'

Historial de ordenes: Esto si que es muy interesante, todas las órdenes que vamos escribiendo, quedan en un historial, podemos recuperar de nuevo las últimas ordenes tecleadas con la flecha hacia arriba. Bueno en realidad podemos navegar por el historial con las flechas arriba y abajo. Y como decía arriba, si las flechas no funciona podemos usar las siguientes teclas para navegar por la historia de ordenes:

• <Control>P Recupera la orden anterior en la historia (P de previo).
• <Control>N Recupera la orden siguiente (N de Next=Siguiente).

(Se pueden usar también las flechas del cursor. Flecha arriba va a la orden anterior y flecha abajo a la siguiente.)

• <Alt> < Va a la primera orden de la historia.
• <Alt> > Va a la última orden de la historia. Esto en algunos Linux esats dos últimas combinaciones pueden no funcionar con la configuración del teclado en castellano.
• <Control>R Busca una palabra hacia atrás en la historia.

Pulsamos <Control>R y el prompt cambiará por algo similar a

reverse-i-search :

empezamos a escribir una palabra. La última orden que hayamos tecleado que contenga esa palabra se mostrará y desde el momento que pulsemos cualquier tecla de edición cesa la búsqueda y podremos modificarla, o simplemete introducirla tal como está pulsando Intro.

Autocompletar: Más interesante todavía que la historia es la posibilidad de completar de forma inteligente lo que vamos escribiendo, para autocompletar se usa la tecla del tabulador <tab>.

¿Como funciona esto? pues si estamos escribiendo la primera palabra de una orden, la shell espera, como es lógico, un comando; así que si tecleo por ejemplo 'ec' y pulso el tabulador, bash busca todos los posibles comandos que empiezan por 'ec' como solo hay uno, que es echo pues lo completa. Si hubiese varios comandos que empezaran por 'ec' primero daría un aviso sonoro indicando que no es capaz de saber que es lo que quiero teclear, si insisto con el tab me mostrará todas las posibilidades, para que pueda teclear alguna letra más y volver a pulsar el tab si quiero. Si ya tecleé el comando y estoy el la segunda o sucesivas palabras, intenta completar con los nombres de archivo, o con lo que más sentido tenga por ejemplo si intento autocompletar una palabra que empieza por $ lo hará con los nombres de las variables definidas, etc... (no te preocupes si no sabes lo que es una variable, ya lo veremos más adelante). En algunos terminales, dependiendo de como estén configurados, puede que el aviso sonoro no se escuche o que sea sustituido por uno visual.

Hay un paquete adicional, que no viene con la instalación por defecto de bash llamado bash completion, que mejora el comportamiento del autocompletado de bash hasta el punto de que si usamos tabulador después de determinados comando consulta la ayuda de se comando para ver que argumentos admite y nos los muestra y muchas mas facilidades. Si está disponible para tu distribución, no dejes de instalarlo, te hará la vida en la consola un poco más fácil.

Bueno una cosa más en cuanto a la introducción de órdenes: Decía al principio que el prompt normalmente puede tener un '$' si estamos como usuarios o un '#' si estamos como root, hay que decir que en algunos casos se pueden mostrar otros prompts. Cuando bash, pese ha que le hemos tecleado un intro entiende que la orden no está todavía terminada, muestra el prompt '>' para indicarnos que debemos seguir. Por ejemplo si abrimos unas comillas y nos olvidamos de cerrarlas, al pulsar el intro bash sabe que falta algo, y nos lo pregunta con ese prompt. Luego hay un tercer y un cuarto prompt pero ya los veremos más adelante, no quiero adelantar acontecimientos.

]]> http://redy.fotolibre.net/2007/09/16/curso-de-bash-para-fotografos-linuxeros-1-toma-de-contacto/feed/ 0 http://redy.fotolibre.net/2007/09/13/curso-de-bash-para-fotografos-linuxeros/ http://redy.fotolibre.net/2007/09/13/curso-de-bash-para-fotografos-linuxeros/#comments Thu, 13 Sep 2007 10:19:28 +0000 Redy http://redy.fotolibre.net/como/curso-de-bash-para-fotografos-linuxeros/ Siguiendo el hilo de lo que decíamos en un mensaje del foro, no es imprescindible que un fotógrafo sepa nada de bash, pero para el que quiera aprender, igual le puede llegar a resultar útil, aunque solo sea para enmarcar fácilmente sus fotos preferidas Aunque la idea surgió en el foro, dado que la temática Seguir leyendo «Curso de bash para fotógrafos linuxeros»
]]>


Siguiendo el hilo de lo que decíamos en un mensaje del foro, no es imprescindible que un fotógrafo sepa nada de bash, pero para el que quiera aprender, igual le puede llegar a resultar útil, aunque solo sea para enmarcar fácilmente sus fotos preferidas

Aunque la idea surgió en el foro, dado que la temática se aparta un poco de lo que es en esencia fotolibre.net; he preferido no poner esto en el foro, sino en mi blog. Pero como quiero que sea algo interactivo, y sé que surgiran dudas, puntualizaciones, y correcciones el hilo en el foro está abierto para cualquier clase de comentarios….

Introducción:

Este curso está destinado a usuarios noveles de Linux, no se requieren conocimientos especiales. Si has instalado Linux en tu ordenador y lo usas podrás seguir este curso sin problemas. El curso irá adentrándose en el conocimiento de la shell más habitual en Linux, el bash, partiendo desde cero. El objetivo es que al final seas capaz de utilizar bash en modo interactivo, con comandos simples y complejos, de configurarlo, e incluso de escribir tus propios scripts.

Es conveniente que se tenga a mano un ordenador con Linux donde probar los ejemplos que se irán dando a lo largo del curso, así se podrá comprobar y comprender mejor todos los conceptos. Se puede usar el bash en windows, pero dado que la shell está tan ligada a una serie de utilidades gnu yo recomiendo encarecidamente que se haga desde Linux. No obstante y si ello no fuese posible, aconsejo la instalación de cygwin. Cygwin es una colección de herramientas, que incluye, por supuesto, bash, desarrollada por Cygnus Solutions para proporcionar un comportamiento similar a los sistemas Unix en Windows. La compatibilidad no está asegurada al 100% pero creo que la mayoría de los ejemplos propuestos funcionaran sin problemas y los menos lo harán con muy pocos cambios.

¿Que es la SHELL?

Un es el programa que sirve de intermediario entre la máquina por una parte, y los programas de aplicación o el usuario por otra. La shell es en los entornos UNIX la capa de del sistema operativo que sirve de interfaz con el usuario en modo texto. Es el ‘interprete de comandos’, su misión es analizar lo que le tecleamos e interpretarlo para ordenarle al sistema operativo lo que debe hacer.

La palabra inglesa ‘shell’ significa concha, caparazón o cáscara, lo cual parece no guardar mucha relación con la definición anterior. La historia de Unix comienza a mediados de los 60 cuando se crea el sistema operativo MULTICS (MULtiplexed Information and Computer Service) en los laboratorios Bell. Multics fue un fracaso, pero un ingeniero de Bell, Brian Kernighan, necesitaba un sistema operativo para un PDP 7, y tomando ideas de MULTICS, inició el desarrollo de uno menos ambicioso, y le llamó UNICS, luego se cambiaría la terminación CS por una X, que en inglés suenan igual. En el MULTICS al interfaz de usuario ya se le llamaba shell porque no creaba nuevos procesos cuando ejecutaba programas de usuario, simplemente los enlazaba dinámicamente y los llamaba como si fuesen una rutina propia; de ahí parece venir su nombre, era como un programa esqueleto o caparazón.

Siguiendo con un poco de historia, el Unix de Brian Kernighan fue mejorado por Dennis Ritchie y Ken Thompson de AT&T, el interprete de comandos utilizado era el sh, también conocido como Bourne Shell, escrito por Stephen Bourne. Poco más tarde la Free Software Foundation buscaba un interprete de comandos para su sistema operativo GNU, no podían utilizar la shell de Bourne porque su licencia no era del todo libre, y así se escribió la llamada ‘Bourne Again Shell’ (La shell de Bourne de nuevo) más conocida por sus iniciales BASH, que mejoraba y ampliaba a la shell original de Bourne. Hoy en día, aunque que existen otras muchas alternativas, csh, ksh, zsh, tcsh… la shell bash es la más usada en Linux.

Toda esta historia está muy bien para ponernos en antecedentes pero todavía no he contestado a la pregunta que da título a este capítulo: ¿Que es la shell?. Podemos definir una shell como un intérprete que ejecuta las órdenes escritas en un lenguaje específico que el usuario le proporciona o que lee desde un fichero. Así que si queremos dominar el manejo de la shell debemos conocer bien la sintaxis del lenguaje que utiliza, y ese es el objetivo de este curso.

En la definición anterior queda claro que la shell tiene dos modos de funcionamiento, uno en el que el usuario le proporciona las ordenes escribiéndolas directamente, a este modo le llamaremos ‘shell en modo interactivo’, y otro en el que la shell lee e interpreta las ordenes que previamente fueron escritas en un fichero. Al fichero dónde se guardan las ordenes que luego serán interpretadas por una shell en modo no interactivo se le llama ‘script de shell’, y es un fichero de texto que podemos crear con cualquier editor.

¿Porqué es interesante conocer la shell?

‘En el principio fue la línea de comando’, es el título de una obra de Neal Stephenson sobre Linux. Que gran verdad hay en ese título que parafrasea al Génesis de la biblia.

Lo cierto es que así era, cuando se planteó la necesidad de que los ordenadores tuviesen sistemas operativos, la única forma de que el hombre se relacionara de una forma fácil con la máquina era la línea de comando. Los tiempos han cambiado mucho. Grandes avances en el software y en el hardware, hacen posible que, hoy en día, la línea de comando esté empezando a usarse menos. Gracias a los maravillosos entornos gráficos de que disponemos podemos hacer muchas tareas de forma intuitiva, y sin necesidad de aprender ningún lenguaje de comandos. No obstante todavía quedan muchos ‘gurús’ que prefieren hacerlo todo prescindiendo de esos entornos gráficos. Yo no estoy en ninguno de los dos extremos, uso ambas cosas, para ciertas cosas me parece mucho más cómodo el entorno gráfico, pero hay ciertas otras que prefiero hacerlas con comandos, y considero que hay cosas que en un entorno gráfico son mucho más complicadas de hacer que con un comando.

A ver: el que esté limpio de pecado que tire la primera piedra. ¿Quien de vosotros nunca ha usado la línea de comandos? ya sea en Linux o en otro sistema operativo. Creo que nadie, todos hemos necesitado meter un comandillo de vez en cuando.

Muchos podéis pensar que más o menos ya os defendéis con la shell, que con lo que sabes ya os basta. Bueno, es posible, pero si no intentáis aprender un poco más nunca sabréis lo que os estáis perdiendo.

Pienso que pese a que los entornos gráficos nos facilitan multitud de tareas, necesitamos la línea de comandos. Para poder usar adecuadamente la línea de comandos debemos conocer bien el lenguaje de la shell. Si conocemos bien el lenguaje, le perderemos el miedo. Si conocemos bien el lenguaje podremos hacer tareas que nos parecían muy complicadas de forma muy sencilla. Si conocemos bien el lenguaje evitaremos cometer muchos errores que nos darán más de un quebradero de cabeza.

Por otra parte, el lenguaje de la shell de Linux es muy potente, nada comparable al lenguaje de comandos de los sistemas operativos tipo DOS. ¿Por qué usar algo tan potente solo a su 10%?. ¡He visto hasta un programa de contabilidad escrito en lenguaje de bash! Si no tenemos idea de programación, este puede ser un buen comienzo, el conocer el lenguaje de la shell nos permitirá hacer nuestros primeros programas, y puede ser una especie de iniciación que luego nos lleve a conocer lenguajes de programación más potentes todavía. Si ya programamos en otros lenguajes, conocer la shell nos puede ser muy útil para realizar programas sencillos, que no merece la pena escribir en algún lenguaje compilado, y que sabemos que funcionarán en cualquier Linux, (y hasta en cualquier Unix) porque todo Unix tiene una shell.

Recuerdo que uno de mis primeros escarceos con la shell fue un script para mantener mi colección de palíndromos. Soy aficionado a los palíndromos, esas frases que son iguales si las lees al derecho que al revés. Tengo un archivo de texto con más de 2000, el script en cuestión solo son 24 líneas, y me permite añadir frases a mano o procedentes de un archivo, comprobando que efectivamente sean palíndromos, y que no estén ya repetidas. Estoy seguro de que a medida que vayáis conociendo la shell, y sobre todo cuando empecemos a hacer scripts, le iréis encontrando multitud de aplicaciones…

Cualquier duda, consulta, opinión sobre este tema hazla en este hilo del foro de la Comunidad FotoLibre. Las criticas no constructivas redireccionaleas directamente a /dev/null

]]> http://redy.fotolibre.net/2007/09/13/curso-de-bash-para-fotografos-linuxeros/feed/ 0 http://redy.fotolibre.net/2007/05/18/muuuuuu%e2%80%a6chas-vacas/ http://redy.fotolibre.net/2007/05/18/muuuuuu%e2%80%a6chas-vacas/#comments Fri, 18 May 2007 15:41:07 +0000 Redy http://redy.fotolibre.net/fotolibre/muuuuuuchas-vacas/ ¿Ya os he dicho que Vigo estaba lleno de vacas? Vaca Doble de Muuuuzarella: Vaca Forever Young: Fashion Cow: Pre-Cow-Ción: ¿Onde vas Rianxeira?: Turi-Cow: Tami: Irmá Vaca (Hermana Vaca): Cow-Lumbus: Vaca-miño (Esperando el autobús.): Cocovía (Una vaca descansado tras un día de compras.) Esta creo que es Keith (la de los cuernos, las otras dos Seguir leyendo «Muuuuuu…chas vacas»
]]>


¿Ya os he dicho que Vigo estaba lleno de vacas?

Vaca Doble de Muuuuzarella:




Vaca Forever Young:


Fashion Cow:


Pre-Cow-Ción:


¿Onde vas Rianxeira?:


Turi-Cow:


Tami:


Irmá Vaca (Hermana Vaca):


Cow-Lumbus:


Vaca-miño (Esperando el autobús.):


Cocovía (Una vaca descansado tras un día de compras.)


Esta creo que es Keith (la de los cuernos, las otras dos son Ada, mi hija y Belén mi mujer…  ):


Unas más originales y otras menos, decoradas por diversos artistas y patrocinadas por no menos diversas entidades este montón de vacas de fibra de vidrio pueblan las calles de mi ciudad. El caso es que dan un poco de color a nuestras calles, y un poco de polémica también…

Si os gustan otro día os pongo más…

Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2007/05/18/muuuuuu%e2%80%a6chas-vacas/feed/ 0 http://redy.fotolibre.net/2007/05/08/batalla-de-flores-en-vigo/ http://redy.fotolibre.net/2007/05/08/batalla-de-flores-en-vigo/#comments Tue, 08 May 2007 08:38:32 +0000 Redy http://redy.fotolibre.net/fotolibre/batalla-de-flores-en-vigo/ Más modesta que la de Laredo, y recuperada de la historia de nuestras fiestas populares después de más de 30 años en el olvido, Vigo celebra por tercer año consecutivo su batalla  de flores. No faltaron en esta edición dedicada al mar, sirenas, piratas, peces, mariscos y otras criaturas marinas… Pero lo que más abundó Seguir leyendo «Batalla de flores en Vigo»
]]>


Más modesta que la de Laredo, y recuperada de la historia de nuestras fiestas populares después de más de 30 años en el olvido, Vigo celebra por tercer año consecutivo su batalla  de flores. No faltaron en esta edición dedicada al mar, sirenas, piratas, peces, mariscos y otras criaturas marinas… Pero lo que más abundó fué el confetti disparado a cañonazos desde las carrozas y las serpentinas de papel.

Como la batalla se celebró cerca de dónde vivo fuimos dando un paseito, y por el camino mi hija se paró a mirar una de las muchas vacas que estos días podemos ver por nuestras calles:
 



Un par de langostinos charlaban poco antes de comenzar el desfile…



Como podeis ver el confetti lo inundaba todo:





Peces de colores, niños y  flores (sintéticas ¡eh!, que no está el mundo para andar tirando flores de verdad) fueron los protagonistas de esta fiesta:







No podía faltar el popular pez payaso Nemo que se esconde en su inseparable anémona:



Y las sirenitas:





Tiburones mecánicos, medusas, peces, y diversos engendros accionados a pedales intentaban asustar al público que les arrojaba serpentinas:



Los piratas tampoco podían faltar:









Las fotos estan hechas con la Kodak C875, que creo que ha sido una buena compra, solo le veo un defecto, se traga las pilas en un plis plas, pero bueno todo es cuestión de hacerse con unas cuantas pilas recargables de no menos de 2500mAh y llevar un cargador rápido en el coche. Por lo demás la cámara está genial, 8 megapixels, Zoom 5X es pequeñita. Quizá se queda un poco escasa en angular (equivalente a 38, es lo mínimo que abre), pero ya he visto un accesorio que se le puede acoplar para multiplicar por 0,45. Por otra parte tiene un modo totalmente automático, abundates programas de los típicos, y modos manuales en los que puedes elegir iso, apertura y velocidad. Prioridad al diafragma, Prioridad a la velocidad. Vamos que estoy contento con ella, como cámara compacta, (si grabase en raw ya sería la leche)…

Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2007/05/08/batalla-de-flores-en-vigo/feed/ 0 http://redy.fotolibre.net/2007/02/11/unas-de-hipica/ http://redy.fotolibre.net/2007/02/11/unas-de-hipica/#comments Sun, 11 Feb 2007 08:20:20 +0000 Redy http://redy.fotolibre.net/reportajes/unas-de-hipica/ Estos días se celebró la sexta edición del concurso hípico internacional de Vigo, y aproveché para hacer algunas fotillos, estas son del sábado: Las mejores del domingo son estas: Mi mujer y mi hija viendo absortas los zancudos y las animadoras en el descanso mientras yo buscaba una posición mejor… Un zancudo se acerca… Alehop… Seguir leyendo «Unas de hípica»
]]>


Estos días se celebró la sexta edición del concurso hípico internacional de Vigo, y aproveché para hacer algunas fotillos, estas son del sábado:
















Las mejores del domingo son estas:


Mi mujer y mi hija viendo absortas los zancudos y las animadoras en el descanso mientras yo buscaba una posición mejor…


Un zancudo se acerca…


Alehop…


(Los tonos raros son porque había cañones de luz de colores)


[ Una de caballos, para que se sépa que estábamos viendo el concurso hípico, y no en el circo ]

Podeis ver más aquí

Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2007/02/11/unas-de-hipica/feed/ 0 http://redy.fotolibre.net/2006/01/21/una-tecnica-para-hacer-duotonos-sepia/ http://redy.fotolibre.net/2006/01/21/una-tecnica-para-hacer-duotonos-sepia/#comments Sat, 21 Jan 2006 20:28:00 +0000 Redy http://redy.fotolibre.net/?p=8 Hay muchas formas de convertir una foto en duotono, esta es una que particularmente me gusta. He de decir que no es mía, es casi simplemente una traducción de lo que nos cuenta Eric R. Jeschke en gimpguru.org, espero que os sea útil: Partimos de una imágen en color como esta, que ya sé que Seguir leyendo «Una técnica para hacer duotonos (sepia)»
]]>


Hay muchas formas de convertir una foto en duotono, esta es una que particularmente me gusta. He de decir que no es mía, es casi simplemente una traducción de lo que nos cuenta Eric R. Jeschke en gimpguru.org, espero que os sea útil:

Partimos de una imágen en color como esta, que ya sé que no es ninguna joya en cuanto a composición se refiere… pero para el ejemplo puede valernos:



Lo primero es pasarla a blanco y negro (ver este artículo). En este caso usé el mezclador de canales con rojo y verde al 50%, sin nada de azul, y luego le pasé un filtro de alto contrase de blanco y negro (http://registry.gimp.org/plugin?id=4513) retocando un poco las transparencias de las capas que genera, y el resultado es este:



Venga, ahora empezamos la faena: Primero añadimos una capa transparente encima. (Capa -> Capa Nueva -> Transparencia). Esa capa la pintamos enteramente del color que nos interesa hacer el tono. Para ello hacemos doble click en el color de frente en la caja de herramientas y seleccionamos el color que nos interesa en mi caso seleccioné R=160, G=120, B=110. Con ese color y haciéndo uso de la herramienta de rellenar (el bote de pintura) rellenamos toda la capa. En el cuadro de diálogo de capas ponemos el modo de esta capa en 'color'. Ahora añadimos un máscara de capa, (Capa -> Máscara -> Añadir máscara de capa -> Negro, Transparencia total). Nos vamos a la capa de abajo seleccionamos todo y lo copiamos, ahora en la capa de arriba, la que tiene la máscara lo pegamos. Ahora podemos hacer los ajustes de nivel que nos interesen, en mi caso solo toqué las curvas poniendo una curva como ésta:



Y éste es el resultado:



Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2006/01/21/una-tecnica-para-hacer-duotonos-sepia/feed/ 0 http://redy.fotolibre.net/2005/12/13/vuelta-al-mundo-de-yates-de-volvo/ http://redy.fotolibre.net/2005/12/13/vuelta-al-mundo-de-yates-de-volvo/#comments Tue, 13 Dec 2005 16:01:33 +0000 Redy http://redy.fotolibre.net/fotolibre/prueba-de-entrada/ El 12 de Octubre en Vigo se daba la salida a la primera etapa de la vuelta al mundo de yates patrocinada por Volvo.Seguir leyendo «Vuelta al mundo de yates de Volvo»]]>


El 12 de Octubre en Vigo se daba la salida a la primera etapa de la vuelta al mundo de yates patrocinada por Volvo.

Es la primera vez que tal evento parte de un puerto fuera de Gran Bretaña, y el punto de partida elegido fué la la ciudad donde yo vivo así que aproveché para ‘afotar’ lo que pude el evento. Y hay que decir que pude menos de lo que quise, ya que ese fin de semana a mi señora le tocó trabajar y mis deberes como papi son ineludibles…

Pues bien aunque soy un auténtico profano en el mundo de la naútica, me quedé sorprendido con la belleza de algunos de los veleros que con motivo del evento atracaron en nuestro puerto, muchos menos que cuando nos visitó la regata patrocinada por Cutty Shark allá por el siglo pasado (1999), pero muy bellos eso si. Y no me refiero a los veleros participantes en esta regata, que segun algunos es a la vela lo que el Paris-Dakar es al automovilismo, si no a estos veleros de época:


El Gotheborg III es una réplica de un navío mercante armado Sueco de 1738, que se encargó de dar el cañonazo de salida de la Vuelta al Mundo de Yates de Volvo.

La brigantina holandesa Swan Fan Makkun

Como dije antes no pude afotar tanto como quise, así que del resto de veleros de época, no tengo fotos de plano general (había mucha gente, no llevaba una objetivo más angular…). Pero si saqué algunos detalles de la también holandesa goleta Thalassa, del velero britanico Astrid, entre otros…


Llama la atención la sirena del mascarón de proa del Thalassa. AL fondo la proa del Astrid






Y en cuanto a los modernos veleros que participan, pues pude hacer estas instantanesa de la salida desde la ventana de mi casa, teleobjetivo, dia lluvioso, torretas del muelle de carga que estorban, pero es lo que hay…




Y alguna más que teneis en http://www.fotolibre.org/thumbnails.php?album=80

]]> http://redy.fotolibre.net/2005/12/13/vuelta-al-mundo-de-yates-de-volvo/feed/ 0 http://redy.fotolibre.net/2005/11/09/blanco-y-negro-en-un-abrir-y-cerrar-de-ojos/ http://redy.fotolibre.net/2005/11/09/blanco-y-negro-en-un-abrir-y-cerrar-de-ojos/#comments Wed, 09 Nov 2005 09:38:53 +0000 Redy http://redy.fotolibre.net/?p=9     Me encarga el master que cuente un poco como va esto del blanco y negro. Y voy a intentarlo, aunque seguro que hay foreros por aquí que dominan más la técnica del blanco y negro que yo, así que les animo a que corrijan y amplien lo que yo intento esbozar en este Seguir leyendo «Blanco y negro en un abrir y cerrar de ojos»
]]>


    Me encarga el master que cuente un poco como va esto del blanco y negro. Y voy a intentarlo, aunque seguro que hay foreros por aquí que dominan más la técnica del blanco y negro que yo, así que les animo a que corrijan y amplien lo que yo intento esbozar en este mensaje:

1º Disparar la foto

    Aunque muchas cámara tienen la posibilidad de hacer tomas en blanco y negro o incluso diversos efectos, como sepia o duotonos, si realmente queremos obtener buenos resultados, lo mejor es disparar siempre en color, y luego usar el GIMP (u otro programa) para procesar la imagen como nos interese. Cuando hacemos una foto en color, en realidad obtenemos tres imágenes una para cada canal de color RGB: Rojo, Verde y Azul y cada imagen contiene la cantidad de luz del color correspondiente que los objetos fotografíados reflejan. El ojo humano, salvo en personas con problemas de visión (daltonismo, ceguera de color…) percibe las diferencias entre colores y generalmente percibe con más intensidad la luz de ciertas tonalidades, pero el ojo, y el cerebro se adapta a lo que ve, o a lo que le interesa ver, y no hay una regla fija de como mezclar esos colores para obtener una imágen en blanco y negro que nos valga para todas las situaciones, por eso lo mejor es disponer de la máxima información en la toma y esta máxima información sólo la tenemos cuando disparamos en color.

2º La conversión

    Bien, ya tenemos la imágen en colores, ahora solo se trata de convertir la información de color, las tres capas, en una única capa que muestre la intensidad de luz que refleja cada objeto, pero ya sin la información de color, simplemente en tonos de gris. Esto que parece fácil a la hora de la verdad no lo es tanto, y en principio podemos usar varios métodos que iré explicando uno a uno:

Convertir a escala de grises

   La manera más simple, aunque la que menos aconsejo, de convertir una imágen en color a blanco y negro, es la que todo programa de retoque trae de 'convertir a escala de grises'. En GIMP debemos elegir el menú Imagen -> Modo -> Escala de grises.



   La forma en que GIMP convierte a grises aunque parezca un misterio, no lo es tanto: en realidad hace un mezclado de los tres canales (RGB) para obtener uno solo en gris tomando los siguientes porcentajes: Rojo 30%, Verde 59%, Azul 11%, que es segun los expertos lo más parecido a como nuestros ojos captan la intensidad de luz dependiendo del color de ésta.

   El resultado es más o menos este:



Desaturar

Como hemos comentado una de las formas más comunes de representar una imágen en color es mediante la codificación en RGB. Cada punto de la imágen viene definido por tres valores que representan la cantidad de luz roja (Red), verde (Green) y azul (Blue) que reflejan), Combinando esos tres colores en mayor o menor medida obtenemos toda la gama cromática que el ojo humano es capáz de distinguir. Otra forma completamente distinta de representar cada punto de la imágen es en HSV de este modo en lugar de dividir cada punto por la cantidad de luz que refleja de cada uno de los tres colores primarios, se le da un valor que coresponde al tono (Hue), este valor define el color en una escala cromática que contiene toda la gama tonal y que va desde el rojo al violeta. El segundo valor corresponde a la saturación (Saturation), este valor representa la cantidad de color que tiene un punto, de tal manera que a menos saturación el punto tendrá un aspecto más apagado, más grisaceo, y a mayor saturación tendrá un aspecto más colorido (en la tonalidad que cooresponda segun el primer valor, claro). Y el tercer valor es la lúminosidad (V de Value), es decir la cantidad de luz que refleja el punto, de tal forma que a mayor más brillante será el punto en cuestión.

Existe complejas fórmulas matemáticas que permiten convertir un valor expresado en RGB al mismo valor expresado en HSV, así por ejemplo un color amarillo claro como podría ser en RGB el R=241 G=241 y B=50, en HSV se representaría como H=60 S=79 y V=95



Se usan estos distintos sistemas de codificación porque en algunos casos convienen más unos que otros para determinadas manipulaciones, por ejemplo suponed que queremos darle más brillo a una imagen si trabajamos en HSV basta con subir la V, en cambio en RGB habría que incrementar cada color proporcionalmente, manipulando los tres valores.

Para los efectos que nos interesa, una fiorma de convertir una imágen en color a tonos de gris es suprimiendo totalmente la saturación de modo que solo nos quede como valor significativo la luminosidad. Este efecto, en el gimp, lo podemos consegir de tres formas (aunque son la misma, pero digamos que está en tres menús distintos): En el menú de Capa tenemos dos posibilidades: elegir colores -> desaturar, con lo que quitamos la saturación de un plumazo, o bien elegir colores -> tono-saturacion, con lo cual tendremos un nuevo cuadro de dialogo en el que bajaríamos la saturación al mínimo. Y a este mismo cuadro de diálogo también llegamos por Herramientas -> Herramientas de color -> tono-saturación. Cada uno que elija el que más le plazca.



El caso es que desaturando laimagen también obtenemos una imágen en blanco y negro, pero esta vez todos los colores tienen porcentajes iguales, ved las diferencias con el método anterior:



Si os fijais convirtiendo a escala de grises se obtienen tonalidades más claras para los amarillos y más oscuras para los rojos, en cambio desaturando apenas hay diferencia. Por otra parte y si os centrais en  la caja azul de la izquierda, que es toda del mismo tono, pero tiene tres niveles de luz distintos en sus tres caras, en la opción de convertir a grises a penas se aprecian diferencias, mientras que en la de desaturar esas diferencias de luz son mucho más marcadas.

Mezclador de canales

Este método parte de separar los tres canales de color: R, G y B y mezclarlos en una sola capa gris de manera similar a como lo hace el gimp en el primer método del que hablábamos, pero en lugar de usar porcentajes fijos, elegiremos los que a nosotros nos interesen:

Seleccionaremos Filtros -> Colores -> Mezclador de canales



Y elegiremos los porcentajes de cada canal:



Como lo que nos interesa es convertir la imágen a blanco y negro marcaremos la casilla 'monocromo'.

La casilla 'conservar luminosidad' provoca que los valores seleccionados se ajusten proporcionalmente hasta sumar 100%. A veces nos interesará desmarcarla para conseguir un efecto de sub o sobreexposición.

Hay muchos plugins que se basan en este mezclador de canales, que equivalen más o menos a un revelado analógico en una ampliadora usando o no filtros, como ya se apuntaron en este foro: http://registry.gimp.org/person?id=4503 http://registry.gimp.org/plugin?id=6731

Para guiarnos un poco pongo una lista de valores RGB y el efecto de filtro que conseguiríamos con ellos, y una imágen de como quedarían:

Sin filtro: 30%, 60%, 10%
Filtro rojo: 90%, 10%, 0%
Filtro naranja: 78%, 22%, 0%
Filtro amarillo: 60%, 28%, 12%
Filtro Verde: 10%, 70%, 20%
Filtro verde-amarillo: 35%, 48%, 17%
Filtro Verde oscuro: 50%, 0%, 50%
Filtro Azul suave: 50%, 50%, 0
Filtro Infrarrojo: 40%, 140%, -80%



Ëste creo que es el método más versátil, y que nos permite hacer prácticamente lo que queramos con total control sobre la imágen. Hay que tener en cuenta que:

El canal rojo aporta más ruido que el verde, pero menos que el azúl, tiene menos dispersión atmosférica por lo que nos puede ayudar a suprimir bruma o niebla, aclara el tono de la piel.

El canal verde  suele aportar la mejor información lumínica, y generalmente incrementar ese canal no aumenta demasiado el ruido, oscurece los cielos azules y aligera los tonos de la vegetación, no modifica sustancialmente el tono de la piel.

El canal azul es el más ruidoso, pero puede ser útil para corregir el tono del cielo, que suele tener un componente azul muy alto.

Descomponer


La última técnica se basa en descomponer la imágen en capas y eliminar algunas de ellas total o parcialmente segun nos interese.
Ya vimos antes que normalmente las imágenes se codifican en RGB, pero también existen otros sistemas, como el que también ya vimos, de luminosidad, tono y saturación por ejemplo.
Atendiendo a la síntesis de colores (como en el RGB) existen dos métodos fundamentales: el RGB o aditivo y el CMY o sustractivo.


En el primero se utilizan los colores base Rojo Verde y Azul para obtener todos los tonos posibles sumando varios niveles distintos de dichos colores. En el CMY se usa los colores básicos Cian, Magenta y Amarillo para obtener los distintos tonos por substración, o incluso se añade un cuarto color negro (CMYK). Este método es más usado en impresión, porque las tintas sobre el papel responden mejor a este sistema, por contra los monitores funcionan en RGB. Tambié existe el sistema RYB (Rojo Amarillo Azúl) más usado por pintores, y que también es aditivo.
Con los sistemas de luminancia pasa algo parecido: aparte del HSV, que ya vimos; existen otros métodos. Uno muy parecido al HSV pero más lineal es el HSL. Y luego está el YUV También llamado YCbCr, en YUV también tenemos tres componentes, uno de luminancia, la Y y dos de crominancia, la componente azul (U) y la Roja (V) de tal manera que sobre un plano en donde representemos Y y V como dos coordenadas obtenemos todos los posibles colores:



Y luego tenemos el LAB que es muy similara a éste último, la L indica la luminancia, y la A y la B el color, para la A los valores negativos indica más verde y los positivos más rojo. Y la B va del azul (negativo) al amarillo (positivo)



En GIMP podemos descomponer una imágen en capas gracias a un plugin que tenemos en Filtros -> Colores -> descomponer. Creo que viene por defecto con todas las versiones recientes de gimp pero por si teneis un gimp muy viejo lo podeis instalar desde http://registry.gimp.org/plugin?id=227. Al seleccionar este plugin, se nos presntan muchas opciones segun como queramos dividir los distintos canales. Seleccionando una de las opciones obtenemos una imágen nueva con tres o cuatro capas de tonos de gris cada una con la información del canal correspondiente (o tres o cuatro imágenes nuevas si no marcamos la opción 'descomponer en capas'):



Descomponer RGB

Como su nombre indica obtenemos 3 capas, una con el canal Rojo otra con el Verde y otra con el Azul. (Y una cuarta con el canal alpha si hemos descompuesto en RGBA).



Ahora jugando con el nivel de opacidad de  las dos capas superiores, podemos obtener el resultado que nos interese, por ejemplo un 60% de verde y un 10% de azul suele dar un resultado interesante. Podemos cambiar el orden de las capas si queremos, o el modo en que se combinan. Como estámos jugando con los canales RGB más o menos es válido todo lo dicho para la técnica de 'Mezclador de canales'.

Descomponer CMY

La técnica es la misma solo que las capas obtenidas serán Magenta, Cyan y Amarillo (y una cuarta con el Negro si elegimos CMYK en vez de CMY).  Lo que ocurre es que con estos canales como usan el método sustractivo, la imágen la obtenemos como en negativo, así que antes de nada iremos capa por capa e invertiremos los colores:



Luego ya podemos jugar con las opacidades. Una buena técnica es descomponer en CMYK poner el negro abajo de todo, y después de invertir el color de todas las capas, poner a cero las opacidades de las capas Cyan, Magenta y Amariilo e ir subiendo un poco las que nos interensen para conseguir el tono que queremos.

Descomponer HSV

La capa que contendrá la información más interesante será la del Valor, las otras dos pueden valernos para corregir un poco. Por ejemplo tomando la capa de valor como base y usando la de saturación para ennegrecer (quizá habiéndole aplicado antes un filtro de desenfoque a dicah capa) podemos obtener una imágen en la que se resaltan los brillos:



Descomponer LAB

Pues es una técnica parecida a la anterior, en este caso la imformación más interesante estará en la capa L. Un método interesante es el que propone Francisco Guzman en este tutorial para PS y que en GIMP se haría descomponiendo en LAB, eliminando o desmarcándole el ojo a las capas A y B, duplicando la capa L y sobre la superior elegir el método multiplicar y la opacidad que nos interese.



Descomponer YCbCr

En este caso la lúminosidad estará en la capa Y (Luma) y las capas (Azul y Roja) nos servirán para las correcciones, por lo demás el sistema es como los anteriores.

Y con esto doy por finalizado el tutorial, me ha quedado bastante extenso, pero espero que os sea útil. También espero que aporteis sugerencias y que me corijais en lo que no os parezca bien.

Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2005/11/09/blanco-y-negro-en-un-abrir-y-cerrar-de-ojos/feed/ 0 http://redy.fotolibre.net/2005/05/12/como-conseguir-efecto-de-velocidaaaaaaaad-con-el-gimp/ http://redy.fotolibre.net/2005/05/12/como-conseguir-efecto-de-velocidaaaaaaaad-con-el-gimp/#comments Thu, 12 May 2005 08:54:56 +0000 Redy http://redy.fotolibre.net/?p=6    Todos los aficionados hemos intentado más de una vez (con mayor o menor éxito) sacar esas fotos de eventos deportivos, en las que seguimos con la cámara, haciendo un barrido al sujeto que circula a gran velocidad, disparando con una velocidad no demasiado rápida, para intentar que el fondo aparezca movido y el sujeto Seguir leyendo «Como conseguir efecto de velocidaaaaaaaad con el GIMP»
]]>


   Todos los aficionados hemos intentado más de una vez (con mayor o menor éxito) sacar esas fotos de eventos deportivos, en las que seguimos con la cámara, haciendo un barrido al sujeto que circula a gran velocidad, disparando con una velocidad no demasiado rápida, para intentar que el fondo aparezca movido y el sujeto lo más nítido posible, con eso se logra una sensación de movimiento muy expresiva. Hoy vamos a intentar simular este mismo efecto pero usando el gimp.

Tomando una foto sacada con velocidad alta simularemos el efecto movido en el gimp, así tenemos un alto índice de probabilidad de que la foto nos quede bien y en el gimp podemos repetir las veces que queramos hasta conseguir lo que nos interesa, con la cámara, en estos eventos normalmente solo podemos disparar una vez (Normalmente no podemos pedirle a Fernando Alonso que por favor dé otra vuelta, que no nos ha quedado bien su paso por meta ).

   Bueno para los ejemplos voy a coger una foto del Boss…



   Lo primero, ya sabeis que a mi me gusta trabajar con capas, duplico la capa, y trabajando sobre la de abajo aplico un efecto de 'Desenfoque en movimiento'







Ahora con la herramienta de 'seleccionar formas de imagen' (la tijerita con las línea curva) selecciono el contorno del personaje.



Añado una máscara de capa, invierto la selección y relleno de negro con el bote de pintura, con esto el fondo se hace transparente y veo la capa inferior (movida).



Retoco los bordes con el aerógrafo de presión variable, y luego aplico la máscara, mezclo las capas y este es el resultado



Creo que me ha quedado demasiado exagerado, pero lo importante es la idea….

Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2005/05/12/como-conseguir-efecto-de-velocidaaaaaaaad-con-el-gimp/feed/ 0 http://redy.fotolibre.net/2005/05/06/como-usar-capas-canal-alfa-y-mascaras-en-gimp/ http://redy.fotolibre.net/2005/05/06/como-usar-capas-canal-alfa-y-mascaras-en-gimp/#comments Fri, 06 May 2005 12:15:56 +0000 Redy http://redy.fotolibre.net/?p=5 El uso de capas en gimp permite trabajar con varias imágenes superpuestas como si estuviesen colocadas en films transparentes unas sobre otras. Esta característica es de una gran ayuda en muchas tareas, como hay mucha gente que no tiene muy clara la utilidad de las capas, voy a escribir un minitutorial con un ejemplo obvio Seguir leyendo «Cómo usar capas canal alfa y mascaras en gimp»
]]>


El uso de capas en gimp permite trabajar con varias imágenes superpuestas como si estuviesen colocadas en films transparentes unas sobre otras. Esta característica es de una gran ayuda en muchas tareas, como hay mucha gente que no tiene muy clara la utilidad de las capas, voy a escribir un minitutorial con un ejemplo obvio en el que cambiaremos el fondo de una foto.

Para ello tomé prestadas dos fotos del almacen, de la galería de Belit, que espero que no se moleste por destrozarle sus creaciones , una de ellas con unas interesantes nubes que usaremos para el fondo:



Y la otra con un bonito faro rojo:



Yo uso el gimp 2.x , pero si alguno usais el gimp 1.xx todo lo que cuento vale, aunque los menús puede que cambien un poco.

Lo primero que hice fué cargar la foto del faro:



Y a continuación tenemos que irnos al cuadro de diálogo de capas. Si no lo teneis visible os vais al menú de diálogos -> capas, o mejor todavía diálogos -> crear un empotrable -> Capas, canales y rutas. (En gimp 1.xx creo recordar que estaba en el menú de ver -> Capas Canales y caminos).

En dicho cuadro de diálogo vermos que tenemos una única capa. Lo primero que haremos será añadirle un canal alpha. Y ¿que es un canal alpha?: Cada punto de la imágen se define por sus valores de color, hay tres valores, uno para el rojo, otro para el verde, y otro para el azul. Pero si trabajamos con capas necesitamos un valor más, que define la transparencia de cada punto, tenemos que entender que debajo hay otras capas que serán más o menos visbles en función del valor de cada punto en el canal alpha. La única capa que no necesita tener un canal alpha es la última, la más inferior, todas las que estén por encima necesitan tener canal alpha. Así que como esta del faro va a tener un fondo por debajo, lo primero que haremos será añadirle el canal alpha (pinchando con el botón derecho y seleccionando la opción del menú) y luego crear una capa nueva que con ayuda de los iconos de las flechas situaremos debajo:




En este momento tenemos dos capas, yo les he cambiado el nombre, puedes hacerlo haciendo doble click en el nombre o pinchando con el botón derecho y seleccionando editar atributos de capa. A la capa del faro le llamé 'Faro' y a la nueva 'Nubes' (original que es uno), y como ya dije, la de las nubes estará por debajo. Pues bien ahora selecciono la capa de las nubes pinchando en ella con el ratón: se marcará en azul,, eso significa que todas las operaciones subsiguientes en la ventana de edición se harán sobre esa capa, y no sobre la del faro que está por encima. Para ver lo que vamos haciendo es conveniente desactivar el ojo de la capa del faro (pinchando sobre él), para que no se haga visible, ya que si no la capa que está por encima no nos dejaría ver en la que estamos trabajando.



Pues bien en esta situación abrimos el otro fichero, el de las nubes. Seleccionamos todo, copiamos, nos vamos al cuadro de edición del primero y lo pegamos. Luego con la herramienta de redimensionar lo ponemos al 200% de tamaño.



Y finalmente la rotamos -30 grados y la centramos (usando la herramienta de rotar claro)



Para que todo quede en su sitio fijamos la selección flotante sobre la que estábamos trabajando desde que dimos a pegar usando el botón del ancla o bien la opción Anclar la capa del menú que sale pinchando con el botón derecho sobre ella.



Ahora que ya tenemos las dos capas empezaremos a trabajar con las transparencias:

Tal como en cada uno de los canales de colores (RGB) podemos modificar los niveles y darle más o menos intensidad a cada uno, en el canal alpha también se puede hacer esto, en principio la capa del faro tiene opacidad total, y oculta totalmente a la de las nubes. Si, teniendo la capa seleccionada, modificasemos la barra de opacidad la podríamos hacer más o menos transparente de modo que se dejase ver más o menos la capa inferior. Pero si quisieramos hacer más o menos transparente solo una zona concreta y no toda la imágen, habría que modificar (oscurecer o aclarar) solo los puntos que nos interesan del canal alpha, lo cual podemos hacer seleccionando solo dicho canal en la pestaña de canales. Pero hay una forma más sencilla de trabajar sobre el canal alpha y sin hacer realmente cambios en él hasta que consigamos el resultado que buscabamos, y es añadiéndo una máscara de capa. Podemos pintar sobre la máscara en tonos de gris de tal manera que cuanto más blanco sea un punto en la máscara más opaco resultará dicho punto en el canal alpha una vez aplicado, el resultado lo vemos inmediatamente segun vamos trabajando, pero el canal alpha no se modifica hasta que apliquemos la máscara de tal manera que si no nos gusta el resultado siempre podemos borrar la máscara sin aplicarla y dejar todo como estaba.

En nuestro caso comenzaremos añadiendo a la capa del faro una máscara totalmente blanca (o sea totalmente opaca) y con las herramientas de pintura iremos dándole tonos más o menos negros donde nos interesa hacerla más o menos transparente con lo que conseguiremos ir revelando la capa inferior (la de las nubes) en las zonas que nos interese dejando opacas otras (el faro). Os animo a que una vez que añadais la máscara probeis diversas herramientas, brochas, aerógrafo, blanquear o ennegrecer, difuminar con el dedo…. con distintos tonos de gris para ver el efecto que se consigue. Después de experimentar podeis volver a pintar toda la máscara de blanco o simplemente borrarla y crear una nueva máscara blanca.



Una vez añadida la máscara y teniéndo en cuenta que el cielo es de un azul casi uniforme usé la herramienta de la varita mágica (seleccionar regiones continuas para seleccionar toda la parte superior del cielo, y lo repetí pulsando la tecla de mayúsculas para agregar a la selección en los espacios entre las barandillas del faro, obteniendo este resultado:



Sobre esta selección uso el bote de pintura para rellenarla toda de negro (Recuerda que pintar de negro en la máscara significa hacer transparente la imágen). Luego con una brocha fina y con la herramienta de difuminar retocamos un poco la zonas delicadas como los bordes del faro o suavizamos la transición inferior del cielo de la capa de abajo con la de arriba en la parte inferior de la imágen:



Quitad y poned el ojo de la capa del faro para ver el efecto de transparencia…



Si nos gusta el resultado solo falta aplicar la máscara:



Y finalmente combinar las capas en una sola imágen, como la capa de las nubes la ampliamos y la rotamos es mucho más grande que la imágen, así que cuando nos pregunte que hacemos con lo que sobra le diremos que la recorte al tamaño de la imágen…



Este es el resultado:



Seguro que podeis mejorarlo….

Opina sobre este tema en el foro de la Comunidad FotoLibre.

]]> http://redy.fotolibre.net/2005/05/06/como-usar-capas-canal-alfa-y-mascaras-en-gimp/feed/ 0