$ 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.
$ 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.
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.
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 :)
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)
:)
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 también podemos darle una serie de órdenes a ejecutar al pasar por un breakpoint.
Veamos un ejemplo. Sea el siguiente programa en C:
#include <stdio.h> 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!