Os dejo una panorámica de el Embalse de Cornalvo hecha desde la presa.

La foto esta compuesta de 5 tomas, sin trípode ni artilugio para panorámicas, a la hora de tirar las fotos bloquee la exposición para todas las fotos igual. Están tiradas desde lo alto de la presa, por eso le falta algo en primer plano, había pensado incluir algún barquito de otra foto , pero no me gustaba como quedaba.
Están unidas con PS y luego corregido algunos defectillos sobre todo en las nubes donde si se notaba las uniones, eso fue lo mas complicado y creo que me quedo muy bien.
Después revele por zonas , pero salvo la parte de abajo a la derecha que tuve que ser mas cuidadoso (se me iba al negro), lo hice en grandes zonas.
Me explico; para que en el revelado no se notase diferente tonos entre cielo y agua seleccione las dos zonas y revele por igual con los mismos parámetros.
La parte de la tierra la revele también de corrido pero casi que no la toque mucho ya que de por si tenia mucha luz (ese momento se abrió las nubes y dio el sol directamente)los tonos amarillos son por la hora y creo que lo quedare así pues una característica de la foto muy particular, he probado a bajarlos y pierde mucho. También creo que se ve mucho mas diferente en grande que en pequeño, los tonos se “ablandan”
Al final algunos retoques para corregir pequeñas zonas y un poquito de enfoque.
Espero os guste.

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.

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


Buenas,

además de probar el estabilizador del 17-85 (ayudado por una columna), quería plasmar mi sorpresa tras volver a esta estación de Príncipe Pío un montón de años después. La primera ocasión (en 1989 o 90) no tenía más que los andenes, las vías y el edificio. Estuve tirando fotos con la Franka (aún no me había comprado la primera EOS) y tenía el ambiente romántico de las viejas estaciones de ferrocarril. Ahora, juzgad vosotros mismos.

(más...)

Buenas,

como rara vez paso las navidades en casa, no suelo poner ni el árbol. Estos son los de casa de mis padres.

Me gusta el ambiente nocturno que le da al belén el rincón en el que se monta, por lo que prefiero las fotos sin flash en la mayoría.

(más...)

…que dicen ¡compra, compra, compra!

(más...)

Buenas,

esta era una de las ideas que tenía en mente desde el principio y que en realidad es mi visión de la Navidad y la foto que hubiera presentado. Una bombilla que lleva la contraria apagándose mientras todas lucen.

Aunque normalmente son difíciles de encontrar porque lo que solemos ver en esos días son otras imágenes.
(más...)

Buenas,

pues en mi periplo con Maky por las calles (iluminadas) de Madrid, pillé algunos edificios de esos que ponen bonitos para que hagamos fotos.

La primera ya la conocéis algunos, ya que la he afinado con ayuda.

(más...)

Buenas,

hace unos días que unos amigos con los que jugaba de mozo me invitaron porque celebran un partidillo navideño todos los años. Como no estoy todavía para grandes esfuerzos, me fui con la cámara nueva con la idea de amortizarla. Con suerte esta es la última entrega que os hago de "pruebas", me leo todo lo que he escrito y trato de hacer fotos. 

Por si alguien no ha estado tratando de hacer fotos en un polideportivo, suelen adolecer de una luz bastante pobre. Este sin ser para tirar cohetes no era de los más oscuros que he visto, pero aún así. Y ello se junta con gran distancia al motivo (a partir de 20 m.) y con jugadores y balón en movimiento. El tema de luces se resolvería fácilmente con exposiciones largas, pero estas dan "barridos" involuntarios en los jugadores que pueden llegar a ser desagradables. En cuanto al flash, es de las ocasiones en que agradeces haberte gastado algo más de pasta y tener uno potente. No solo para que pueda llegar lejos, sino para que sea capaz de hacerlo en disparos muy seguidos incluyendo ráfagas.

La conclusión más triste es que debería haber hecho lo único que no hice. Tratar de tirar a velocidades más altas. Pero yo soy de esos que caemos en la cuenta de las cosas una vez hechas las fotos. Deben ser reminiscencias del esperar a que nos entregasen el revelado en el laboratorio.

Empecé tirando a 400 ISO y en el modo programa. Lo que me ponía velocidad de 1/60 pero esto me daba zonas más o menos bien iluminadas por el flash con fondos oscurecidos que no dan buen aspecto a la imagen.

(más...)