miércoles, 18 de diciembre de 2013

Actualización del traductor de consola gtr

El exceso de trabajo me impide introducir por el momento algunos nuevos scripts y trucos de línea de comandos que he ido pensando y desarrollando en los últimos meses, por lo que de momento me conformo con actualizar algunos viejos scripts y hoy le toca a gtr, el traductor Ingles-Español Español-Inglés de consola hecho en Bash y que utiliza Google Translate. Había dejado de funcionar por algunos cambios en la web pero tras unos ligeros retoques ya vuelve a estar operativo. Aquí está el nuevo código:
#!/bin/bash

## gtr - Traduce palabras y frases usando Google Translate ##
##       v0.3 por Rodia (daltonico.net) 2013               ##

gtserver="http://translate.google.com"

browser=$(which lynx)
if [ -z "$browser" ]; then
   echo "$(basename $0): error: falta 'lynx' y no se puede seguir"
   exit 1
fi

sl="en"
tl="es"

case $# in
     0) echo "Uso: $(basename $0) [-r] palabra o frase a traducir"
        exit 1;;
     1) query=$1;;
     *) if [ "$1" == "-r" ]; then
           sl="es"
           tl="en"
           shift
        fi
        query=$(echo $* | sed 's/ /%20/g');;
esac

$browser -dump -nolist "$gtserver/?hl=en&eotf=0&sl=$sl&tl=$tl&q=$query"\
         > /tmp/gtr.tmp 2>/dev/null

if [ "$?" -ne "0" ]; then
   echo "$(basename $0): error: no se pudo conectar a $gtserver"
   exit 1
fi

entrada=$(grep -B1 'Please help' /tmp/gtr.tmp | head -1 | cut -b 4-)

if [ -n "$entrada" ] && [ "$entrada" != "$query" ]; then
   echo -e "\n $entrada\n"
fi

exit 0

sábado, 30 de noviembre de 2013

Entrevistas a programadores en Big Think

Recientemente tropecé navegando por algún blog tecnológico anglosajón con un enlace a Big Think, un portal en la línea del famoso TED (que hasta tiene un programa en la televisión pública española) en cuanto a sus contenidos relacionados con la ciencia, el medio ambiente, la tecnología, la demografía, el fomento de la creatividad y la innovación, etc. Pero, en lugar de usar el formato charla/disertación, se dedican a entrevistar a los supuestos gurús haciendo preguntas relevantes sobre sus respectivos campos de competencia y sus trayectorias personales y profesionales. 

Para mi gusto hay demasiados políticos y burócratas en su lista (además de la previsible cuota de vendedores de humo) pero, rascando un poco bajo la superficie, di con cuatro entrevistas a programadores de renombre:
  • Bjarne Stroustrup: el creador del lenguaje C++, al que le preguntan sobre el origen del mismo, sus diferencias con C, la vigencia de ambas tecnologías, el futuro de la programación, su opinión sobre el open source, los 5 lenguajes que considera más importantes, sus hábitos de trabajo y algún consejo para programadores de C++.
  • Larry Wall: el excéntrico creador de Perl, el lenguaje de programación que ayudó a montar la web dinámica a mediados de los 90 (Yahoo es el ejemplo más conocido por el gran público y Slashdot por el público más friki) y ya se venía usando como la cinta adhesiva (junto a Bash y otras shells y herramientas) en miles de servidores Unix. En la entrevista le preguntan sobre el origen del lenguaje, su enfoque post-moderno, su idoneidad como primer lenguaje, y su relación con el lenguaje humano y otros lenguajes de programación. También le interrogan sobre su rol como líder de la comunidad surgida en torno al lenguaje y le hacen resumir los principios de la programación en cinco minutos y destacar cinco lenguajes. Por último le hacen mojarse opinando sobre Apple y las patentes software y le piden que hable sobre algunos de sus hábitos de trabajo.
  • David Heinemeier Hansson: el creador del framework de programación web Rails, hecho con y para el lenguaje de programación Ruby. Le preguntan sobre los orígenes del mismo, su elección de Ruby y porqué lo considera un lenguaje especial, sobre si a los programadores les deberían gustar los lenguajes que usan, la creciente facilidad para programar y los planes para el futuro de Rails. Después le preguntan sobre la hegemonía de Microsoft y su papel en el desarrollo de software, sobre las restricciones de Apple y la conveniencia del cloud computing. Por último habla sobre el open source y el sector del desarrollo de software.
  • Justin Frankel: el programador del famoso reproductor Winamp y posteriormente de Gnutella, la aplicación de intercambio de archivos. Le preguntan por sus motivaciones y los programadores a los que admira, por lo que en su opinión hace tan buenos a los mejores programadores, por lo que lo empujó a crear Winamp, por su opinión sobre iTunes y la compra por parte de AOL de su empresa; por su motivación a la hora de crear Gnutella, sus posteriores problemas con AOL al respecto y por último por sus hábitos de trabajo.
Las entrevistas no han perdido relevancia pese a que tienen ya tres años y lo único que hay que lamentar al respecto es que no siguieran entrevistando a más programadores, ya que es difícil encontrar ese tipo de contenidos fuera de libros o revistas especializados. Aunque las entrevistas en vídeo no están subtituladas y se puede perder algún detalle, por suerte están transcritas íntegramente bajo el reproductor multimedia.

martes, 19 de noviembre de 2013

Cómo oir un podcast mono en estéreo

Si uno es aficionado a oir grabaciones digitales de programas de radio (podcasts en la jerga "internetera") como los que pueden encontrarse en iVoox, seguro que alguna vez se ha topado con un archivo de audio, típicamente MP3, que sólo se oye por una canal, normalmente el izquierdo. Esto es debido a que ciertos programas utilizados para editar y/o codificar el audio grabado para su posterior publicación en internet, no manejan bien el asunto del sonido monoaural y lo codifican como un archivo estéreo con sólo un canal activo, en lugar de codificarlo como mono, en cuyo caso el reproductor alimentaría los dos altavoces con la misma señal. El asunto es especialmente molesto en caso de escuchar el audio con auriculares o a través de los pequeños altavoces de un portátil.

Afortunadamente, en la era digital y de internet, esto son minucias, y si uno usa Linux, posiblemente cuente con MPlayer y si no puede instalarlo con un par de clics o comandos usando el gestor de software del sistema. La potencia de este reproductor multimedia viene, además del alto número de códecs que soporta, de la cantidad de opciones que da al usuario, entre ellas el uso de filtros y la redirección de canales. Para oir el archivo de marras por los dos altavoces en un falso estéreo, solo tendríamos que reproducirlo desde la consola así:

mplayer -af channels=1 archivo_audio_podcast.mp3

Mucho mejor entonces... Podemos consultar la documentación online del programa sobre el uso de filtros y la manipulación de canales si queremos profundizar o simplemente experimentar un poco. Con software libre como ese, ¿quién necesita programas cerrados y de pago? ;-)

jueves, 31 de octubre de 2013

Listando equipos en redes Windows

No hace mucho que descubrí en la terminal de comandos de mi sistema Linux la utilidad smbtree. Acompaña a smblient (en el paquete del mismo nombre) y, como sugiere su nombre, muestra un pantalla un árbol con los distintos equipos detectados en la red que corran el protocolo SMB, usado típicamente en redes Microsoft donde se comparten carpetas e impresoras. Como la salida en pantalla es muy extensa, te obliga a paginarla (p. ej. con less) o a desplazarte varias páginas hacia arriba, y como el "dibujo del árbol" no es compacto, sigue sin ser fácil de captar de un vistazo. Una de las ventajas de Linux y Bash es la facilidad con que se pueden crear nuevos comandos o personalizar los existentes si no nos gusta su funcionamiento. En mi caso, lo que me interesaba era un simple listado de equipos conectados en la red, por lo que tras un par de pruebas en la línea de comandos filtrando la salida de smbtree, di con la tubería adecuada, que para poder usarla a partir de ese momento como un comando más, convertí en un alias de la siguiente forma:

alias smblist='smbtree -N|egrep '\''\\\\[^\\]+$'\''|awk '\''{print $1}'\'''

El festival de comillas simples repetidas (y algunas escapadas con \) es para poder utilizarlas dentro de las comillas simples más externas que definen el alias. A continuación paso a aclarar los comandos:
  • El parámetro -N de smbtree es para que no pida contraseña.
  • He usado egrep para poder usar el cuantificador + en la expresión regular, y significa "una o más ocurrencias del caracter anterior" (en este caso, cualquier caracter que no sea backslash).
  • La expresión regular completa podría traducirse por "cadena que empiece por dos backslash (\) seguidos y luego uno o más caracteres distintos a backslash y el final de la línea ($)". Lo que consigue es dejar solo las líneas con nombres de equipo en formato NetBIOS.
  • El comando awk final simplemente se queda con la primera columna de cada línea para acabar de limpiar los datos.
Guardando esa definición del alias en nuestro archivo .bashrc (o donde se definan los alias de usuario en nuestro sistema) tendremos un nuevo comando disponible, en este caso para listar los equipos de la red que "hablan" el protocolo SMB. De utilidad en redes SOHO ;-)

domingo, 20 de octubre de 2013

Lanzador de programas Java para Linux

Hace un tiempo tuve que mirar el asunto del deployment o despliegue de aplicaciones Java y pude ver cómo se recomienda el uso de scripts en el sistema operativo de destino para manejar la invocación del runtime java y el paso de parámetros al programa. En el caso de que éste se distribuya como un archivo JAR y se trate de una aplicación con GUI (interfaz gráfica de usuario) no es necesario, y lo más sencillo sería crear un lanzador o acceso directo al archivo JAR aprovechando que dicha extensión suele asociarse al runtime. El uso de un script intermediario tiene realmente sentido cuando el programa es de línea de comandos (sí, también se pueden hacer en Java ;) y se quiere invocar de forma fácil (como cualquier comando del sistema) desde una terminal y pasándole los argumentos necesarios. Como los ejemplos oficiales de script bash son demasiado sencillos y limitados, me propuse mejorarlos un poco. Mi idea era que el programa Java se instale en el sistema mediante un script de instalación o un paquete (.deb, .rpm, etc.) compatible con el gestor de software correspondiente. El archivo .jar (o los archivos .class junto a los archivos auxiliares de recursos, documentación, etc.) se instalaría en un directorio propio bajo /usr/share u otra ruta conveniente. En ese mismo directorio residirá el script lanzador al que yo he llamado jlauncher y que tendrá un enlace simbólico (creado durante la instalación) en un directorio de ejecutables estándar (p. ej. /usr/bin). El nombre del link será igual al del archivo JAR o la clase principal del programa pero en minúsculas (p. ej. jpodcastdl). Y el resto lo hace el código del script, que buscará la clase Java o el archivo .jar de nombre relacionado con el que se usó para invocarlo y ejecutará el runtime de Java con las opciones pertinentes y pasándole los argumentos necesarios. El código quedaría más o menos así:

#!/bin/bash

# jlauncher - lanzador para programas CLI hechos en Java

java=$(which java)

if [ -z "$java" ]; then
    echo "$(basename $0): error: falta el runtime de Java necesario">&2
    exit 1
fi

dir_name=$(dirname $(readlink $0))
script_name=$(basename $0)
class_name=$(ls -1 $dir_name | grep -i "$script_name.class")

if [ -z "$class_name" ]; then
    jar_name=$(ls -1 $dir_name | grep -i "$script_name.jar")
    if [ -n "$jar_name" ]; then
        java -jar $dir_name/$jar_name "$@"
    fi
else
    java -cp $dir_name ${class_name%.class} "$@"
fi

Otra cosa es que alguien elija Java para hacer un programa de línea de comandos para Linux pudiendo usar, por ejemplo, Python, pero bueno, el caso era trastear un poco y de paso allanar el terreno a quien le interese hacerlo...

lunes, 30 de septiembre de 2013

Revista Linux de referencia

Este verano he leído con satisfacción un par de números en papel (y en Inglés) de la revista Linux Magazine, una de las publicaciones de referencia de todo lo relacionado con el sistema operativo Linux (o para los puristas, GNU/Linux). Hacía años que no leía revistas de informática; la cantidad de información técnica (aunque la de calidad hay que buscarla) disponible cómodamente en la web, incluyendo sitios de noticias como The Inquirer o el más alternativo Barrapunto (o su imitado Slashdot) me fueron haciendo olvidar las publicaciones tradicionales en formato "árbol muerto". No, no es que piense volver a hacer ese gasto económico y espacial (lease "pilas de revistas viejas" ;) pero al visitar la web de la versión en español de Linux Magazine, descubrí con ilusión que, aunque de los números más recientes solo publican la lista de contenidos y pequeños extractos de los mismos, si uno no tiene demasiada prisa por estar a la última pero le interesan las distribuciones Linux y tecnologías relacionadas que van consolidándose en el mundo Linux, revisadas por expertos en la materia, resulta que los números anteriores (hasta un año de antigüedad) los van publicando íntegros en formato PDF en su archivo on-line. ¡Que aproveche!

martes, 16 de julio de 2013

Vigilar precios de Amazon con bash

Aprovechando el despegue del comercio electrónico en España y el exitoso desembarco de Amazon, voy a compartir un pequeño script Bash para programar alertas de bajada de precio de un artículo. Sí, ya sé que existen servicios como camelcamelcamel que permiten hacer eso vía Web y mediante el uso de extensiones para el navegador. Lo uso desde hace años con satisfacción, pero también me gusta el DIY (hágalo usted mismo) y es un buen ejemplo de problema cotidiano en la era de Internet que podemos resolver, aprendiendo algo de paso, si usamos Linux o Mac OS X, ya que ambos cuentan con la potente shell de línea de comandos Bash.

Como artículo de ejemplo he elegido el lector de libros electrónicos Kindle, ya que a veces se hacen descuentos interesantes y es un producto altamente recomendable para lectores en general y techies en particular.

Mi intención ha sido dejar el script lo más sencillo posible, pero sin perjudicar la legibilidad para una fácil adaptación a otros artículos (cambiando las variables donde se guarda el URL y el precio) y garantizando cierta compatibilidad entre sistemas Linux y Mac OS X. Para lograr esto último, el script puede usar dos formas distintas de descargar la página web para posteriormente comprobar el precio. En Linux suele estar preinstalado Wget, mientras que en Mac OS X puede confiarse en la presencia de cURL. Se usan filtros estándares como grep y cut, presentes en ambos sistemas, para extraer el precio. Para avisar al usuario en caso de detectar una bajada, he optado por la forma más sencilla que involucre al escritorio gráfico: abrir la página del artículo con el navegador web predeterminado. Para ello se usará open en los Mac y xdg-open en los Linux. El resultado queda más o menos así:

#!/bin/bash

# vigila-kindle: comprueba si ha bajado el precio
#                del artículo y abre su página web

url_prod="http://www.amazon.es/gp/product/B007HCCOD0"
pre_prod=79

if [ -n "$(which curl)" ]; then
    httpcli="curl -A 'Mozilla/5.0'"
else
    httpcli="wget -U 'Mozilla/5.0' -O -"
fi

if [ -n "$(which xdg-open)" ]; then
    open="xdg-open"
else
    open="open"
fi

precio=$($httpcli $url_prod 2> /dev/null \
                  | grep priceLarge \
                  | grep -o '[0-9][0-9]*,[0-9][0-9]*' \
                  | cut -d, -f1)

if [ -n "$precio" ]; then
    if [ $precio -lt $pre_prod ]; then
        $open $url_prod
    fi
fi

Para usarlo satisfactoriamente solo tendremos que copiarlo a un archivo llamado vigila-kindle (o el nombre del artículo si lo adaptamos a otro) en un directorio de ejecutables para los usuarios (p. ej. /usr/local/bin en Linux), darle permisos de ejecución y configurarlo para que se ejecute en el inicio de sesión o programar una tarea que lo ejecute una vez al día. Ya solo quedará esperar a que se nos abra la página del artículo mostrando un precio más bajo (con un poco de tiempo y de suerte ;)

domingo, 30 de junio de 2013

Descargando especiales rock sinfónico de Discópolis

Hoy voy a compartir un script bash que hice hace unos meses para automatizar las descargas de los programas especiales sobre rock progresivo y sinfónico que se han ido emitiendo en el espacio radiofónico Discópolis, de Radio 3. Por lo visto comenzó como una serie de 6 o 7 programas donde se pretendía hacer un resumen informal de los principales grupos que dieron lugar a este estilo musical en los años 70, pero la cosa se fue alargando (para deleite de los aficionados) y ya van más de 40 programas. Aprovechando su publicación en formato MP3 en la web de RTVE, pensé en hacer un script que automatizara la descarga para tener la colección completa y poder escucharla donde y cuando quiera. En principio debería funcionar en cualquier ordenador con Linux o Mac OS X, ya que ambos usan la shell Bash y he flexibilizado el uso del cliente HTTP para que use Wget (Linux) o cURL (Mac). Además no debería ser complicado adaptarlo para descargar otros programas de la misma web modificando la query string (principalmente los parámetros pageSize y ctx de la variable query) y las variables prog_pattern (el patrón de búsqueda) y prog_prefix (prefijo para nombrar los archivos). El código, listo para pegar en un archivo de texto, se puede ver aquí (no olvidar darle permisos de ejecución). That's all, folks!

viernes, 21 de junio de 2013

Funciones en un shell script: trackbin

Hace poco comentaba lo útil que podía resultar definir nuevas funciones en la shell y usarlas como si se tratara de nuevos comandos, nuestros propios comandos. El otro uso de las funciones shell, quizá más clásico, es dentro de scripts, como un recurso para que el programador organice su código. Cuando cierta secuencia de instrucciones (en este caso comandos) se utiliza repetidas veces a lo largo de un programa (en nuestro caso script) lo mejor es declararlo como una función que se invocará allá donde sea necesario, teniendo en cuenta ciertas cuestiones:
  • A una función se la invoca como a un comando o script, por su nombre y adjuntando si son necesarios los parámetros separados por espacios.
  • Dichos parámetros (para ser preciso argumentos, una vez dentro de la función), los recibirá en las variables especiales $1,$2, etc. solapando temporalmente las variables equivalentes donde el script recibe los parámetros pasados por el usuario desde la línea de comandos.
  • Si se necesita alguna variable local a la función, se puede usar la palabra reservada local antes de asignarle un valor por primera vez.
  • La función puede devolver con return un código de estado al igual que el script lo devuelve a la shell con exit. Éste se podrá usar para comprobar su éxito o no a modo de función que devuelve un valor booleano en lenguajes de programación tradicionales.
  • La forma de modificar y/o devolver otros datos más allá de ese valor de retorno, sería modificando variables globales (cualquiera definida en el script que no se haya "tapado" con una local del mismo nombre) o sacando datos a la salida estándar (un caso típico sería una función ayuda_de_uso()), que siempre podrían recogerse en el punto de la invocación dentro de una variable con la sustitución de comandos (mediante comando o $(comando) si no se quieren sacar aun por la salida éstandar.
Para ilustrarlo incluyo más abajo el código de un shell script llamado trackbin que rastrea los nombres de comandos hasta el archivo ejecutable último siguiendo los links intermedios:
#!/bin/bash

if [ -z "$1" ]; then
    echo "Usage: $(basename $0) BINARY_NAME"
    exit 1
fi

bin=$(which $1)

if [ -z "$bin" ]; then
    echo "$(basename $0): error: command '$1' not found"  
    exit 1
fi

function es_enlace {
    ls -l $(which $1) | grep -q ' -> '
    return $?
}

function donde_apunta {
    local destino=$(ls -l $(which $1) | awk '{print $NF}')
    if ! echo $destino | grep -q '/'; then
        destino=$(dirname $1)/$destino
    fi
    echo $destino
}

while es_enlace $bin
do
    bin=$(donde_apunta $bin)
done

echo $bin

exit 0

viernes, 31 de mayo de 2013

Crea tus propios comandos con funciones de Bash

En programación, una función no es más que una secuencia de instrucciones que realizan una tarea específica, a la cual se le da un nombre que puede invocarse cuando se necesite llevar a cabo dicha tarea en cualquier punto del programa.

Las shells potentes como Bash, que cuentan con sus propios comandos internos y estructuras de control para poder programarlas, también permiten definir funciones. Podemos obtener ayuda al respecto usando el comando interno help, indicado para obtener ayuda básica sobre cada comando interno de Bash: help function. La otra forma de obtener ayuda en el propio sistema sobre los comandos internos de Bash, es consultar la página de manual de los mismos ejecutando: man bash-builtins.

Según puede leerse en la ayuda oficial, podemos crear una función de las siguientes formas (si se escribe un comando por línea no es necesario el punto y coma para separarlos):

function mi_funcion { comando1; comandoN; }
mi_funcion () { comando1; comandoN; }

Ejemplos (hay que tener en cuenta que una tubería de comandos se considera un solo comando, de hay solo el punto y coma final):

function usuarios_totales { grep '/bin/bash$' /etc/passwd | wc -l ; }
usuarios_actuales () { who | cut -d ' ' -f1 | uniq | wc -l ; }

Aunque el uso más conocido de estas funciones de la shell es el de estructurar el código de un shell script de forma que no se repitan secuencias de instrucciones y además facilitar la reutilización de código en otros scripts, la aplicación práctica que me parece más interesante para un usuario avanzado de Linux es poder crear nuestros propios comandos. En el artículo anterior ya vimos como hacerlo con alias, y podríamos usar las funciones de igual modo:

function top_files { ls -lhS | grep ^- | head ; }

o:

topdirs () {
    du -h -d1 | sort -hr | grep / | head
}

Hasta aquí nada nuevo, ya que la funcionalidad que proporcionan es similar a la de los alias y su sintaxis es un poco más compleja. Es cuando se necesita ejecutar distintos comandos (no solo una tubería de ellos) en cierta secuencia, comprobar condiciones o iterar en bucles, cuando los alias se muestran limitados o directamente inútiles (no son más que sustituciones simples) y las funciones empiezan su "función" ;-) También cuando necesitamos pasar algún parámetro que modifique la forma en que se ejecutan los comandos. Por ejemplo, en el caso de las funciones anteriores que hemos adaptado de los alias correspondientes, podríamos controlar el número de archivos o directorios a listar en el ranking:

function top_files {
    local lines
    if [ -z "$1" ]; then
        lines=10
    else
        lines=$1
    fi
    ls -lhS | grep ^- | head -n $lines
}

topdirs () {
    local lines
    if [ -z "$1" ]; then
        lines=10
    else
        lines=$1
    fi
    du -h -d1 | sort -hr | grep / | head -n $lines
}

Como puede verse, el paso de parámetros a la función funciona de la misma forma que el paso de parámetros a un script, por lo que en $1 tendremos el primer parámetro pasado, presumiblemente el número de líneas a filtrar del listado final. El comando local se usa para definir variables locales a la función que no interfieran con las definidas a nivel del script (si la función estuviera dentro de uno, si no el ámbito sería la shell actual). Además hay que mencionar el comando interno return, que se usaría para salir de la función (anticipadamente o no) devolviendo un código de estado, tal y como se hace con exit a nivel de un script.

Las funciones definidas en línea de comandos, al igual que los alias, tienen una vida efímera vinculada a la shell actual. Para que sean útiles deben perdurar en el tiempo, para lo que editaremos el archivo de nuestro usuario .bashrc y añadiremos en él la definición de las mismas. La ventaja sobre un shell script sería la rapidez, ya que se encuentran pre-cargadas en memoria, aunque por eso mismo deberían reservarse para tareas cotidianas cuya secuencia de comandos no sea demasiado grande...

martes, 28 de mayo de 2013

Crea tus propios comandos con alias

Una de las mayores ventajas de cualquier sistema Unix en general, y de Linux en particular, es su capacidad para ser adaptado a las necesidades del usuario. Originalmente desarrollado por y para hackers, entre sus principios de diseño se encuentra la idea de disponer de una generosa colección de herramientas especializadas que puedan combinarse a voluntad para crear nuevas herramientas caseras con las que solucionar los problemas cotidianos surgidos en el sistema informático.

La propia shell (el programa que hace de intermediario entre el usuario y el sistema) cuenta con características que permiten adaptarla y extenderla a las preferencias y necesidades del usuario. En el caso de Bash, la potente shell de GNU presente por defecto en sistemas Linux e incluso en Mac OS X, una característica de este tipo que ofrece al mismo tiempo sencillez y potencia es la definición de alias

Un alias no es más que un sinónimo, un nombre alternativo que el usuario puede definir para un comando ya existente. Podemos examinar los alias existentes ejecutando el comando interno del mismo nombre: alias.

Observando la salida en pantalla de dicho comando se pueden ver algunos alias típicos que suelen definirse por defecto en distribuciones Linux (luego veremos dónde):
  • Por ejemplo, suele haber un sinónimo para ls -l, uno de los comandos más usados, al que se ha bautizado ll. O uno llamado la para el comando ls -a. La idea es darle un nombre corto a ciertos comandos habituales acompañados de distintas opciones de uso, con lo que ahorraremos pulsaciones de teclado y con ello tiempo.
  • Otro tipo de alias muy usado es el que sustituye a un comando externo, p. ej. ls, por su invocación con cierta opción predeterminada, como ls --color=auto. Así cuando se ejecute el comando estándar ls con cualquiera de sus opciones, será como si lo ejecutáramos además con esa útil opción que lo hace colorear su salida de datos en pantalla. Pero sin tener que escribirla cada vez que lo queramos usar. Una variante de este uso es definir alias para ciertos comandos cuyo uso puede tener cierto riesgo, como puede ser el borrado de archivos con rm, por una variante que pregunte al usuario: rm -i. El problema de éste enfoque es que el usuario podría acabar dando por hecho que el comando en cuestión siempre pregunta cuando eso no será cierto en otros sistemas donde no exista dicho alias.
La forma de definir nuevos alias es mediante el comando alias de la forma siguiente:

alias nombre_sinónimo='comando_a_ejecutar'

Por ejemplo, podríamos llamar lla a la combinación de ls con sus opciones -l y -a de la forma:

$ alias lla='ls -la'

Otro uso típico es para acortar simplemente nombres de comando largos que se usan a menudo, por una variante más corta:

$ alias cl='clear'

$ alias p='ping'

O proporcionar un sinónimo conocido para usuarios que vienen de otros sistemas operativos y estén dando sus primeros pasos:

$ alias cls='clear'

$ alias dir='ls'

El último alias podría ser innecesario si existe en el sistema el comando dir. Lo ideal sería comprobar, antes de definir un nuevo alias, si existe algún comando con el nombre elegido para evitar conflictos...

Para eliminar un alias previamente definido, usaremos el comando unalias de la forma:

unalias alias_a_eliminar

Debemos tener en cuenta que los alias que definamos sólo existirán en la shell actual. Si queremos que persistan entre distintas sesiones o incluso reinicios del sistema operativo, tendremos que definirlos, en lugar de en la línea de comandos, en uno de los archivos de configuración de la shell. Para bash, el archivo adecuado sería .bashrc o mejor .bash_aliases en caso de existir.

Hasta aquí el uso básico de los alias, pero donde comienza su verdadera potencia es cuando se usan para dar nombre a tuberías de comandos, es decir a combinaciones de comandos que proporcionan soluciones a medida para problemas concretos. Un par de ejemplos:
  • alias topfiles='ls -lhS | grep ^- | head' # Nuevo comando que lista, ordenados por tamaño y empezando por el mayor, los 10 archivos más grandes del directorio actual.
  • alias topdirs='du -h -d1 | sort -hr | grep / | head' # Nuevo comando que lista, ordenados por tamaño y empezando por el mayor, los 10 directorios que más espacio consumen bajo el directorio actual.
Si los comandos de la tubería no requieren ningún parámetro variable que controle su ejecución, los alias pueden ser una primera alternativa a los shell scripts. La segunda, que introduciré en el siguiente post, son las funciones de la shell.

martes, 30 de abril de 2013

¿Qué hardware y software usan los creadores?

The Setup (usesthis.com) es un interesante sitio web donde se publican entrevistas, clasificadas por medio de etiquetas, a profesionales de distintos ámbitos y perfiles, pero con el denominador común de utilizar ordenadores y otras tecnologías de forma creativa en su vida cotidiana. 

Aunque el tipo de entrevistas que más he leído tiene que ver con la programación y con el uso de sistemas Linux, hay diseñadores, periodistas, bloggers y todo tipo de ocupaciones relacionadas con Internet y las nuevas tecnologías. Se pueden leer entrevistas con creadores de lenguajes de programación como Java o Erlang, con gente que desarrolla el kernel Linux o programa para Debian, con vacas sagradas de la computación y los sistemas operativos, con el principal evangelista del software libre, con un notable hacker del open source, etc. Abundan también sujetos jóvenes implicados en diseñar o programar la Internet de hoy y del mañana...

Algunas conclusiones o mejor, impresiones curiosas que a uno le quedan tras leer más de una docena de entrevistas:
  • Los productos de Apple arrasan entre las "élites tecnológicas", sobre todo los portátiles y netbooks de esta compañía y, aunque a veces se percibe el componente trendy de este hecho y no hay que olvidar que los entrevistados deben de ganar lo que en Hispanistán sería "un pastizal", también queda claro que la calidad, potencia y usabilidad de dichos productos está más allá de toda duda.
  • Se usa (y se crea) mucho software libre, muchas veces combinado con productos puntuales de Apple y otras compañías punteras del sector.
  • Git es el sistema de control de versiones más apreciado y utilizado por los desarrolladores de software, tanto en proyectos colaborativos como individuales, y GitHub es el repositorio online más utilizado.
  • Aún se pueden encontrar rastros de la antigua predilección de los hackers por los portátiles ThinkPad.
  • Se teletrabaja a menudo, y se utilizan diversos servicios "en la nube".
  • Linux es un sistema operativo muy habitual, y no solo en el back-end.
  • Los editores más utilizados son los dos grandes clásicos de la tradición Unix: Vim y Emacs, incluso sobre OS X y entre gente por debajo de los 40, y en general se aprecia cierto desdén o indiferencia por los IDEs.
  • Los hackers de Unix/Linux son bastante minimalistas y parecen apreciar mucho los gestores de ventanas en mosaico, que evitan distracciones y favorecen la productividad.
En definitiva, una web muy recomendable para cualquiera involucrado en las TIC que esté interesado en saber qué herramientas usan los principales talentos del sector y poder así inspirarse y aspirar a mejorar, o al menos a romper ciertos esquemas mentales que suelen atraparnos...

martes, 23 de abril de 2013

Fuentes para programar y cómo añadir alguna en Linux

Hace poco estaba leyendo un par de artículos como éste y éste otro sobre las fuentes (o tipos) de letra más apreciadas por los programadores y, aparte de aprender algunas cosas, me di cuenta de que hay sibaritas en todos los rincones de la actividad humana ;-)
Habiendo pasado años frente a líneas de código, o simplemente usando emuladores de terminal, nunca me había cuestionado los valores estéticos de la fuente utilizada más allá del tamaño y el color, aunque esa experiencia me había hecho consciente de ciertas características habituales (y deseables): el ancho uniforme de todos los caracteres (el mismo que el espacio), la habitual ausencia de adornos (serifas) y un diseño que suele permitir una clara distinción entre el 0 (cero) y la O (o mayúscula) y entre el 1 (uno), la l (ele minúscula) y la I (i mayúscula). Por lo demás, es como si uno asumiera inconscientemente la monotonía de las fuentes de ancho fijo y aceptara sumisamente las predeterminas de editores y terminales. Pero parece haber vida más allá de la Courier de IBM, la Courier New de Microsoft y las Monospace o Free Mono habituales en sistemas Linux. Estas son algunas de las alternativas:
  • Una fuente más moderna muy apreciada parece ser Bitstream Vera Sans Mono, con una licencia bastante abierta, incluida en GNOME, y con una presencia aceptable en sistemas Windows y Mac. Su versión de dominio público DejaVu Sans Mono es más exclusiva de sistemas Linux, donde tiene una gran implantación.
  • En los ordenadores de Apple, los programadores han tenido ocasión de apreciar las bondades de las fuentes Monaco y sobre todo, de Menlo (basada en Bitstream Vera), que la sustituyó como fuente predeterminada de ancho fijo del sistema OS X en 2009.
  • Inconsolata es una nueva fuente de licencia abierta diseñada por Ralf Levien, anteriormente implicado en el desarrollo de Ghostscript y actualmente empleado por Google para trabajar en la plataforma Android. Sus atractivas curvas y sus ceros tachados al estilo de los años 80 la han convertido en mi nueva fuente de ancho fijo predeterminada ;-)
Para instalar nuevas fuentes en una distribución Linux moderna como Linux Mint, podemos hacerlo simplemente copiando los archivos correspondientes al directorio de fuentes bajo /usr/share/fonts, y actualizando la cache de fuentes con el comando fc-cache (instrucciones más detalladas) para que las aplicaciones gráficas las vean en su lista. 
En fin, que puede ser agradable un cambio de fuente en la terminal de comandos o el editor de código si pasamos frente a ellos unas cuantas horas a la semana...

domingo, 31 de marzo de 2013

Actualizando el software instalado en Ubuntu

Cualquier usuario no novato de Ubuntu, Linux Mint o cualquier otra distribución Linux derivada de Debian (incluyendo la propia Debian, claro) sabe que dispone de un potente sistema de gestión de paquetes: APT, que facilita enormemente la búsqueda, descarga, instalación y configuración de software.

Se puede recurrir a una herramienta con interfaz gráfica como Synaptic (o la alternativa predeterminada del escritorio correspondiente) o usar los comandos disponibles desde cualquier terminal para tales menesteres. Lo bueno de estos comandos es que son estándares y siempre podremos encontrarlos en cualquier sistema, de escritorio o de servidor, basado en Debian. Además no son difíciles de utilizar en la mayoría de los casos.

Es bien conocido que antes de poder buscar un paquete software (con apt-cache search) o instalarlo (con apt-get install) debe actualizarse la lista de paquetes disponibles mediante apt-get update. Pero lo que realmente quería resumir son las distintas formas de actualizar el software instalado en el sistema usando comandos en la terminal:
  • apt-get upgrade : lleva a cabo una actualización de los paquetes instalados que cuenten con una nueva versión en los repositorios, siempre que ésta no implique la instalación de nuevos paquetes o la desinstalación de paquetes ya instalados. Es la forma más frecuente y segura de actualizar el sistema, equivalente a usar aptitude safe-upgrade.
  • apt-get dist-upgrade : a diferencia del comando anterior, éste intentará instalar nuevas versiones de paquetes instalados aunque impliquen la instalación de nuevos paquetes o la eliminación de paquetes instalados. Es por tanto menos conservador, aunque la resolución de conflictos entre paquetes suele llevarse a cabo sin problemas en la mayoría de ocasiones. Una situación típica en que deberemos usarlo es cuando hay paquetes retenidos, por ejemplo los correspondientes a un nuevo kernel. Sería equivalente a usar aptitude full-upgrade.
Por último comentar que aunque en Debian y derivadas puede usarse apt-get dist-upgrade (de ahí el nombre) para actualizar una distribución a su siguiente versión, en Ubuntu se recomienda usar en su lugar do-release-upgrade...

NOTA: los comandos anteriores que impliquen realizar cambios en el sistema necesitarán privilegios de superusuario, por lo que se tendrán que ejecutar precedidos por sudo o desde una consola de root.

sábado, 9 de marzo de 2013

Proteger archivos contra borrado en Linux

Puede darse la situación de que necesitemos proteger uno o más archivos en nuestro sistema Linux contra un borrado accidental o incluso contra el borrado premeditado por parte de un programa (p. ej. una aplicación creando un nuevo archivo de configuración). En tales situaciones podemos recurrir a la utilidad chattr, concebida para cambiar ciertos atributos especiales que tienen los archivos en la familia de sistemas de archivos más usada en Linux: extended file system (ext4 es su encarnación más reciente). Bastará con ejecutar como superusuario dicha utilidad para activar el atributo "i" (de inmutable) del archivo en cuestión:

sudo chattr +i nombre_archivo

Así no podrá ser eliminado hasta que le desactivemos el atributo protector. Y si más adelante nos encontramos con la situación de que un archivo no se borra "ni a tiros" (de superusuario ;) sería una buena idea recurrir a su utilidad hermana lsattr (ambas forman parte de e2fsprogs) para asegurarnos de que todo está en orden...

jueves, 28 de febrero de 2013

Próximo objetivo: Raspberry Pi

Llevo meses interesado en el ordenador de pequeño coste y tamaño (pero grandes posibilidades) Raspberry Pi. Se concibió como una plataforma asequible y abierta de aprendizaje y experimentación tecnológica, basada en un microchip de tipo SoC (System On a Chip) de Broadcom, que incluye una CPU de arquitectura ARM a 700 MHz, una GPU lo suficientemente potente para reproducir vídeo MP4 en formato HD y 256 MB de RAM, que en el modelo B se doblaron a 512. Esta ampliación de memoria y la inclusión de un puerto USB adicional y un adaptador Ethernet, lo catapultan a la categoría de micro-ordenador de propósito general, preparado para correr un sistema Linux como Raspbian (derivada de Debian) o Arch Linux, compatibles con su arquitectura.

Personalmente no me interesa su utilidad inmediata (y muy conveniente por su relación calidad / precio) como centro multimedia conectado a la TV vía HDMI, ya que tengo cubierta esa necesidad desde hace un par de años con un aparato especializado (y más caro que tengo que terminar de amortizar ;) Y eso que recientemente ha aparecido la versión final de una distribución Linux para el Raspberry Pi dedicada a tal fin: Raspbmc, un híbrido entre la citada Raspbian y XBMC. Lo que me parece más interesante es su uso como servidor de bajo coste y bajo consumo, al estilo del que monté hace unos meses sobre un HTPC con chip VIA x86 y que dedico a descargas y streaming vía UPnP. Sólo que éste será más pequeño y tendrá menos consumo, y de momento se me ocurren algunos roles interesantes:
  • Servidor de archivos estilo NAS (junto a un disco externo USB) o incluso servidor de copia de seguridad en red usando BackupPC.
  • Servidor web ligero y móvil (quizá con lighttpd en lugar de Apache)...
  • Servidor de seguimiento y descarga de podcasts de audio y emisión radiofónica casera (usando un cacharrito de estos).
En cualquier caso, hay una abundante comunidad de usuarios que le están dando todo tipo de usos muy interesantes (algunos delirantes ;) y antes de decidirme le echaré un vistazo a los distintos proyectos de los foros oficiales y a esta revista electrónica mensual que tiene muy buena pinta. Espero poder meterle mano al asunto en unas 3 o 4 semanas y empezar a comentar aquí las distintas pruebas...

sábado, 16 de febrero de 2013

Manual de comandos Linux: ¿español o inglés?

Es normal y deseable que los distintos paquetes software de una distribución Linux incluyan también la traducción de las páginas de manual (visibles con man) a nuestro idioma, pues facilitan el acceso a la documentación técnica al común de los mortales, y le permiten sacar partido a los numerosos comandos y herramientas de consola disponibles. Para ello incluso podemos instalar paquetes opcionales disponibles en los repositorios (al menos en Debian y derivadas como Ubuntu) que recopilan las diversas páginas de manual traducidas, como son manpages-es y manpages-es-extra.

El problema viene cuando uno está intentando entender cómo funciona un programa leyendo los detalles de su uso en la página de manual (traducida) correspondiente, y hay algo que no encaja tras llevar a cabo sin éxito las pruebas pertinentes. Unos cuantos minutos y pruebas después, a punto de cuestionar sus propias capacidades intelectuales a la hora de interpretar la documentación, o incluso empezar a desconfiar de la calidad del propio programa, cae en la cuenta de que el problema puede estar en la documentación, que no deja de ser una traducción del original hecha por voluntarios (que bastante hacen donando su tiempo a la comunidad) y por tanto susceptible de contener errores. Por supuesto, la documentación original también podría contenerlos, pero el hecho de que la generen los propios programadores o gente más cercana al desarrollo y además haya muchos más usuarios en la comunidad angloparlante para detectarlos y corregirlos, lo hace menos probable.

En situaciones así conviene saber cómo forzar al programa man a que nos muestre la documentación original en inglés, que no es más que especificándole dicha localización para que se salte la predeterminada en el sistema (que podemos ver con locale):

man -L en programa_en_cuestión

Como ocurre con muchos aspectos de la informática y las nuevas tecnologías, más vale pelearse con documentación técnica de calidad en inglés, que hacerlo con una mala traducción al español. He dicho.

miércoles, 30 de enero de 2013

Indicador de bloqueo de mayúsculas en Linux

En la entrada anterior comentaba la solución (casera, a base de script para Bash) que había encontrado a un problema relacionado con el touchpad de mi portátil, o más bien con la forma en que lo gestionaba el sistema operativo Linux (Mint 13) y en concreto el escritorio MATE (una variante de GNOME 2).
En esta nueva entrada quiero recomendar una solución que he encontrado recientemente a una carencia que presentan en su hardware cada vez más ordenadores portátiles, entre ellos mi Lenovo ThinkPad Edge. Se trata de la ausencia de algo tan simple y básico como un LED que se encienda cuando se pulse la tecla de bloqueo de mayúsculas. Al no tener ese feedback, uno acaba cometiendo errores al teclear comandos o introducir contraseñas. La solución es un paquete software no oficial para Ubuntu (y distros derivadas) llamado Indicator for Lock Keys, que instala un applet que se encargará de detectar y mostrar en el area de notificación el estado de las teclas de bloqueo (mayúsculas, números, etc.). Como tantas veces ocurre, el software al rescate del hardware ;-)

domingo, 20 de enero de 2013

Desactivar el touchpad en Linux

Hoy he tenido algo de tiempo sobrante y he decidido ocuparme (por fin) de un pequeño problema con mi portátil, un Lenovo Thinkpad Edge. Resulta que cuando te acostumbras al track point te sobra el touchpad, ya que lo rozas sin querer al apoyar las manos y te mueve el puntero del ratón cuando menos lo necesitas ;-) El caso es que en Windows 7, al incluir el applet del panel de control oficial del fabricante sí había podido desactivarlo fácilmente, pero no en Linux Mint 13 (con escritorio MATE), cuyo diálogo de preferencias del ratón no contempla tal posibilidad. Investigando un poco, resulta que hay una utilidad de línea de comandos (¡cómo no!) llamada xinput, cuyo cometido es gestionar todo periférico de entrada en el sistema X Window. Tras un rato de buceo en su página de manual y unas cuantas pruebas he dado con la forma de activar y desactivar el dichoso touchpad de forma independiente. Para que no se me olvide y además facilitar la operación lo he metido en un pequeño script que automatiza la consulta y establecimiento de la propiedad correspondiente sobre el dispositivo de marras. Pego sus escasas líneas más abajo por si a alguien más le sirve. Espero volver con más trucos Linux en breve... en serio ;-)

#!/bin/bash
# touchpad-onoff: activa / desactiva el touchpad del portátil

device_id=$(xinput --list | grep -i touchpad | cut -d= -f2 | \
            cut -f1 )
property_value=$(xinput --list-props $device_id | \
                 grep 'Device Enabled' | cut -f3)
if [ "$property_value" == "0" ]; then
  xinput --set-prop $device_id 'Device Enabled' 1
else 
  xinput --set-prop $device_id 'Device Enabled' 0
fi