¿Quién dijo que la consola estaba muerta? no śe vosotros, pero personalmente es de lo primero que arranco cada mañana para trabajar. ¿Por qué? pues sencillamente por ser invariante en el tiempo, gnome cambia, kde cambia, mac os X cambia, cada vez las interfaces son mejores, pero mi consola responde igual desde el primer día que empecé a usarla. Más aun, te sirve para trabajar remotamente y muchas otras veces es la única opción para arreglar catástrofes (vamos, que no está de más aprender a usarla).

Pese a que a día de hoy hay aplicaciones gráficas para bajar ficheros, torrents, mover/copiar/pegar directorios, conectarse a unidades samba, etc… personalmente, en la mayoría de los casos, sigo prefiriendo arrancar una consola y hacerlo a mano, wget, cp/rm/mv/rsync, smbclient, smbfs, … ¿ya sabes, no?

Y si, como yo, eres un adicto a la terminal, conocerás screen el multiplexador-de-terminales (si no, o si quieres aprender a usarlo, prueba aquí ) multiplataforma, super funcional, y con la maravillosa opción de poder detachear y atachear sesiones.

Y qué hacer con las pantallas de hoy día, son grandes, muy grandes, caben muchas consolas, o una a pantalla completa con screen (que permite dividir la consola en varias regiones)… pues mejor que eso podemos usar terminator, del que ya podemos disfrutar en hoary. Terminator permite arrancar una terminal y, en vez de usar tabs, podemos dividir horizontal y verticalmente la consola las veces como queramos, sacando partido de verdad a los nuevos tamaños de pantalla que tenemos ahora.

Terminator is a program that allows users to set up flexible arrangements of GNOME terminals. It is aimed at those who normally arrange lots of terminals near each other, but don’t want to use a frame based window manager.

Gracias a que usa gnome-terminals se integra muy bien con las preferencias de gnome-terminal (toma los colores que use este, el tipo de letra, control+, control-, etc..) y tiene atajos de teclado para cambiar de región ($man terminator).

¡ Un placer !

No sé qué razón se oculta tras la configuración por defecto de mi vim/gvim que el auto-completado se ve de pena. Tenía un color rosa de fondo con letras blancas, con tan poco contraste que molesta. Para cambiar esta opción y que nuestro vim deje de tener pluma, podemos hacer lo siguiente:

highlight Pmenu guibg=blue guifg=white ctermbg=blue ctermfg=white
highlight PmenuSel guibg=white guifg=blue ctermbg=white ctermfg=blue

Esto en el ~/.vimrc y problema resuelto.

Gracias al vim-tip-1486

Estoy demasiado acostumbrado a como completa bash los nombres de ficheros, escribes un cacho le das a TAB y esperas a que complete hasta donde pueda… si insistes te saca una lista de opciones y vas completando hasta llegar al destino. Vim, cuando estás en modo comando, tiene la fea costumbre de completar todo el nombre con cada TAB… en un directorio con varios ficheros suele ser un suplicio llegar al que toca. Pero afortunadamente todo en vim es configurable, en este caso la opción se llama wildmode.

Para tener un comportamiento similar al bash, puedes poner esto en tu ~/.vimrc:

set wildmode=longest,list:longest

wildmode tiene hasta dos parámetros separados por ‘,’ el primero es lo que ocurre justo después del primer TAB, el segundo cuando el TAB se vuelve a pulsar. En este caso le estamos pidiendo que haga un match con la entrada común más larga posible (por defecto es full, que viene a decir un match completo), y si vuelves a presionar TAB mostará una lista y seguirá haciendo match con la entrada común más larga.

Para más info ‘:h wildmode’

Se me había olvidado que tenía hecho desde hace tiempo un script para pasar un video al formato del iphone (básicamente genera un mpeg4 con el tamaño adecuado para ahorrar espacio) y que además empotra los subtítulos si los encuentra. Todo ello usando mencoder y ffmpeg.

De alguna parte saqué las opciones pero ya no me acuerdo, el caso es que funciona (en linux por lo menos)

Buscando el último trailer de wall-e por youtube me encuentro con esto:

El autor pone “HD” por ahí pero se ve bastante mal. Haciendo scroll encuentro un tipet que dice:

añade &fmt=18 a cualquier url de youtube y se verá en alta resolución

así que probé:

http://youtube.com/watch?v=pC96tIhLDN0
http://youtube.com/watch?v=pC96tIhLDN0&fmt=18

y algo hace! El truco no es nuevo pero yo no tenía ni idea, por si algún despistado tampoco lo sabía… ahí queda.

Existe por ahí un script llamado woof usado principalmente para mandar ficheros de una forma sencilla, está escrito en python y bueno, no es que tenga una cruzada contra python, pero tampoco creo que tengamos que hacerlo ahora todo en python por muy de moda que esté. Concretamente woof no va bien en cygwin (o eso dicen), o bueno igual quieres usarlo desde tu fonera hackeada y no quieres/necesitas python… yo que sé, el caso es que hay formas más fáciles de mandar ficheros a-lo-servidor-web. Yo os propongo una que sólo hace uso de netcat (que siempre puedes usar a mano netcateando).

Se llama ncweb (de netcat-web) es muy simplón, no tiene opciones y ocupa más el comentario de la licencia que el propio fichero. La parte graciosa es cómo mandar algo con formato web, es decir cómo nos manda un servidor web un fichero:

# Execute netcat with http header
(
echo -e "HTTP/1.1 200 OK\r"
echo -e "Connection: close\r"
echo -e "Content-Length: $LENGTH\r"
echo -e "Content-Type: $TYPE\r"
echo -e "\r"
cat $1
echo -e "\r"
) | nc -q 1 -l -p $PORT


Para ver cómo se calcula y que son $LENGH, $TYPE, y $PORT mirad el código, el $1 es el argumento que nos pasan al script y poco más hay que decir. Con esto ya tienes para mandar ficheros por red de forma sencilla y rápida.

Por cierto, va bastante más rápido que woof…

Para hacer screenshots de un video, un truco fácil, rápido y sencillo:


ffmpeg -i video.avi -r 1 -ss 00:00:04 -t 00:00:01 -y video%d.jpg


• - i video.avi : fichero de entrada
• - r 1 : fija el framerate a 1 por segundo.
• - ss 00:00:04 : inicio de la secuencia a capturar
• -t 00:00:01 : duracion de la captura ( como hemos puesto el framerate a 1 solo capturará un frame)
• video%d.jpg : formato de nombre de salida, el %d se reemplaza por el numero de frame capturado (nota:el %d es obligatorio aquí)

Vamos a darle un giro de tuerca a lo que vimos en el post anterior, en este post veremos cómo compilar con cmake usando vim de forma productiva. En primer lugar, necesitamos algo que nos permita compilar un proyecto (de cmake) cuando estamos editando sus ficheros. Mientras editamos los ficheros solemos estar dentro de algún subdirectorio del proyecto con lo que nos bastaría un script que buscara el directorio build y el CMakeLists.txt y lanzara el make.

Es fácil escribir ese script, el mío lo llamo vim-cmake-makeprg y lo tengo accesible en ~/bin . Al ejecutarlo irá subiendo directorios hasta encontrar un CMakeLists.txt y un directorio build. El resultado es que cuando estoy dentro de un proyecto con este comando puedo compilarlo independientemente de donde esté.

Una vez tenemos el script, sólo nos queda decirle a vim que lo utilice para compilar, para ello editamos el ~/.vimrc y añadimos:

set makeprg=vim-cmake-makeprg


Ahora ya podemos trabajar en nuestro proyecto, editamos (con vim) cualquier fichero, empezamos a programar, y para compilar escribiremos:

:make


Aquí es donde comienza la magia de quickfix, en primero se pone a compilar, veremos la salida del proceso de compilación en el buffer de texto de vim. La salida se pasa por un filtro que va capturando los mensajes de error relevantes y los va añadiendo en una lista. Al terminar de compilar vim abrirá el primer fichero que contenga errores y posicionará el cursor en el primer error, también nos mostrará una versión resumida del error:

Podemos ver la lista completa de errores con el comando cl:

Finalmente, estos son algunos de los comandos que podemos usar con quickfix:

• :cl listar los errores
• :cc mostrar el mensaje completo del error actual
• :cn moverse al siguiente error
• :cp moverse al error anterior

Usando vim+quickfix, y cmake tendremos definitivamente una forma mucho más eficiente de programar-compilar-corregir-programar…