Os dejo dos fotos de la Iglesia de San Andrés de Aljucén, que es donde yo vivo.
Espero os gusten, y ya se que el pu… cable molesta un montón, pero el Alcalde no me dejo quitarlo .

Un bichito que andaba pululando por el patio de casa.

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


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.

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
(más...)

El efecto que voy a explicar a continuación surgió para unas determinadas fotografías pensadas como serie a las que quise aplicar un efecto común. Los parámetros de los retoques y filtros deberían variar en función del tipo de imagen, luz, color etc… pero al no ser demasiados es cómodo para hacer pruebas y deshacer pasos.

Lo primero para aplicar esta técnica es echar un vistazo al "Cómo" pasar a b/n que explicó Redy en este hilo: Blanco y negro en un abrir y cerrar de ojos – Mezclador de canales. Una vez "inspirados" pasamos al tema a fondo.
En mi caso partí de esta imagen, originada en RAW que tras unos ajustes básicos se exporta al Gimp.

(más...)

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…

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