Nightly build » Tools

Shell tip: getting a canonical absolute path from a relative path

slack — Mon, 16 Nov 2009 17:08:14 +0000

$ readlink -f relative/path

Gives a full path equivalent to the relative path, and follows every symlink in every component of the name in order to canonicalize it.

Useful aliases

slack — Wed, 04 Nov 2009 15:23:53 +0000

alias top = htop

Htop is a top replacement, with colors, per-cpu load indicators, scrolling (specially horizontal scrolling so you can see the whole command line for each process), searching, a nicer interface to kill/renice processes, mouse support, and the ability to call strace/ltrace/lsof easily on the process you want.

alias info = pinfo
alias man  = pinfo -m

Pinfo is a lynx-style info and man browser. The main reason to use this, IMHO, is that GNU Info simply sucks as a browser. I’m not so sure about replacing man, as I’m confortable with less-style keybindings, but the ability to follow links to related manpages is a great feature :D

Both are included in all popular distros, so installation is only a matter of looking for the packages in the distro repositories.

Valgrind: tracking the origin of undefined values

slack — Fri, 16 Oct 2009 15:55:49 +0000

Today I was wondering if one of those warnings about uninitialized values was located in library code or in my own code, and I noticed a new message in Valgrind’s output:

Use –track-origins=yes to see where uninitialised values come from

This feature was first added to Valgrind 3.4.0 back in January, and it’s great! I wish I had known it before, because it would have spent me a few headaches in the past months, so I decided to write it here just in case I can help someone :)

Bash tip

slack — Fri, 02 Oct 2009 15:23:52 +0000

Sometimes we have to do something like this:

$ generate_things > tmp1
$ generate_other_things > tmp2
$ process_both tmp1 tmp2

With bash, it’s possible to avoid creating these temporary files:

$ process_both <(generate_things) <(generate_other_things)

Trazas con gdb

slack — Sun, 10 Feb 2008 21:03:06 +0000

Todo programador ha pasado alguna vez por la experiencia de depurar un programa a golpe de printf(), con los inconvenientes que ello supone, sobre todo recompilar cada vez que se quiere cambiar la información que se imprime en la traza.

Pues resulta que es posible hacer las cosas “bien” :)

Con gdb podemos imprimir los valores de variables de nuestro programa, eso es algo que todos sabemos PERO tambien podemos darle una serie de órdenes a ejecutar al pasar por un breakpoint.

Veamos un ejemplo. Sea el siguiente programa en C:

#include 

int main()
{
        int i;
        double x=2.0f;
        for (i=0; i<64; i++)
                x*=2;
        return 0;
}

Si compilamos con -g (para debug) y lo lanzamos en gdb podemos visualizar los valores de x así:

(gdb) break 8 Breakpoint 1 at 0x400463: file a.c, line 8. (gdb) commands 1 Type commands for when breakpoint 1 is hit, one per line. End with a line saying just "end". >silent >printf "x=%g\n",x >cont >end (gdb) r Starting program: /home/slack/a.out x=2 x=4 x=8 x=16 x=32 x=64 [...]

El “silent” del principio es para que gdb no imprima la información que suele mostrar al pararse en un breakpoint (fichero, número de línea, contador de programa, etc) y la traza salga más limpia.

Por supuesto se pueden hacer mas cosas. gdb permite definir variables externas al programa y ejecución condicional, así que podemos contar las veces que pasamos por algun sitio y lanzar órdenes en momentos concretos y tonterías similares :D

Happy coding!