He aquí unos cuantos trucos, principalmente para GNU/Linux.
date -d "1970-01-01 1064435867 sec"rsync -avz -e ssh <em>directorio</em>
<em>usuario@servidor</em>:/ruta/remotakeycode 115 = Super_LAhora toca meter un xmodmap ~/.Xmodmap en nuestro ~/.xinitrc, ~/.xsession o el que usemos, y listo. No he conseguido hacer funcionar bien del todo la tecla de la derecha como Hyper_R en vez de Super_R, si alguien lo ha conseguido en condiciones... agradecería una ayuda.
keycode 116 = Super_R
keycode 117 = Menu
spamd -d --user-config --pidfile=/fichero/pid/
Luego basta con llamar a spamc desde procmail, maildrop o lo que
usemos.
enscript --highlight=lenguaje(c,bash...) -o salida.html \ --language=html --color fichero_con_códigofuenteCon source-highlight, podríamos ejecutar lo siguiente:
source-highlight --src-lang=lenguaje(c,bash...) \ --out-format=html --input fichero a colorear \ --output salida.html
perl -pi -e "s/antiguo/nuevo/g;" *
mkfs.msdos -F 32 /dev/fd0
Muchos nos habremos dado cuenta de que el bloqueo numérico no se activa automáticamente al arrancar las X Window, por lo que debemos hacerlo de forma manual una y otra vez.
Buscando en Google una solución al problema, encontré un mensaje publicado en un foro de Fedora. Lo que hay que hacer es bastante sencillo.
Nos bajamos este programita en C, al que yo he llamado numlockx. El código del mismo es el siguiente:
#include <X11/extensions/XTest.h>
#include <X11/keysym.h>
int main(void)
{
Display* disp = XOpenDisplay(NULL);
if (disp == NULL)
return 1;
XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, XK_Num_Lock),
True, CurrentTime);
XTestFakeKeyEvent(disp, XKeysymToKeycode(disp, XK_Num_Lock),
False, CurrentTime);
XCloseDisplay(disp);
return 0;
}Lo compilamos mediante la siguiente orden:
Ahora sólo tendremos que colocar el ejecutable numlockx en el directorio que queramos, y añadir a nuestro ~/.xinitrc, por ejemplo, una línea en la que ejecutemos el programa.
Diría que lo que voy a explicar a continuación es consecuencia de haberme planteado si es ético que se espíen las páginas web que visito con técnicas rastreras, pero realmente me he puesto manos a la obra por otro motivo.
doubleclick.net hoy no funcionaba, y las páginas que tenían algún tipo de treta de las que usa no terminaban de cargar en mi navegador. Para el que no lo sepa, doubleclick es una ¿empresa? que introduce imágenes en blanco, pequeñas funciones javascript, etc. en páginas web a cambio de una cantidad de dinero y que están destinadas a hacer estadísticas comerciales y mostrar publicidad.
Como además de esto, hoy doubleclick no funcionaba, he aprovechado para bloquear el dominio en mi ordenador.
El artículo explica cómo instalar un servidor tinydns sólo para esto, aunque como yo ya lo tenía instalado no me hizo falta. En mi caso ha sido un simple:
# cd /etc/tinydns/root # echo ".doubleclick.net:" >> data # make # cd /etc/dnscache/root/servers # echo "192.168.1.69" > doubleclick.net # svc -dx /service/dnscache # svc -u /service/dnscache
Y todo solucionado:
$ host ad.es.doubleclick.net Host ad.es.doubleclick.net not found: 3(NXDOMAIN)
En la utilidad daemontools hay una aplicación llamada readproctitle. Su finalidad es presentarnos algunos errores en el nombre del proceso. Ahora veremos cómo limpiar el texto que aparece, para no confundirnos leyendo un error que ya no se da pero que sigue ahí.
Podemos ver el error que existe observando la lista de procesos con ps. Normalmente aparecerá el proceso readproctitle seguido de varias líneas de puntos.
Si hay algún error, en cambio, aparecerá un texto descriptivo. Un ejemplo de este caso es el siguiente:
turing:/service# ps aux|grep readproctitle
readproctitle service errors: ...o /var/log/qmail/smtpd/current, pausing: out of disk space?......Supongamos que ya hemos solucionado el problema (en este caso habernos quedado sin espacio en disco 0:) ¿cómo podemos limpiar ese texto?
Encontré este truco en alguna web que no recuerdo, pero consiste básicamente en crear un nuevo servicio, por ejemplo readproctitle-clean, con el siguiente fichero run, al que deberemos dar permisos de ejecución.
#!/bin/sh
svc -d .
exec 1>&2
echo -n '..................................................'
echo -n '..................................................'
echo -n '..................................................'
echo -n '..................................................'
echo -n '..................................................'
echo '..................................................'
sleep 2
exit 0Cada vez que queramos limpiar el texto de readproctitle, habrá que activar el servicio mediante svc -u /services/readproctitle-clean.
Esta tarde hice una instalación de Apache 2.0.55 y de PHP 5.1.2, y tras instalar Drupal vi que obtenía un error diciendo que mail() no existía.
En php.net se puede ver que quizás no haya detectado el ejecutable de sendmail en tiempo de compilación.
Tiene su lógica, ya que uso nullmailer como pseudo-sendmail, que coloca su ejecutable en /usr/local/sbin/sendmail. La solución ha sido sencilla:
sendmail_path = /usr/local/sbin/sendmail -t -i
Existe un problema bastante recurrente a la hora de conectar mediante sftp/scp a una máquina. Es el fatídico:
mandarina:~ jorge$ sftp maquina Connecting to maquina... jorge@maquina's password: Received message too long 538976288
Es tan habitual que mucha gente se pregunta qué ocurre, y descripciones del problema hay a puñados. ¿Qué ocurre y cómo se soluciona?
Lo que ocurre es que al acceder mediante sftp o scp, el sistema ejecuta el fichero ~/.bashrc que tengamos, y si éste muestra texto por pantalla, nuestro cliente ssh recibe "basura" y falla. La solución es simple: organizar nuestro ~/.bashrc en dos partes. La primera contendrá todas aquellas órdenes que no produzcan salida por pantalla, mientras que la segunda contendrá el resto de órdenes.
Luego basta con encerrar esta segunda parte en un condicional como el siguiente:
if [ "$TERM" != "dumb" ]; then # Instrucciones que producen salida por pantalla fi
Y ya está: cada vez que conectemos mediante sftp o scp, no se ejecutará esa segunda parte y no fallará el proceso.
Referencia: Received message too long solution
¿No os ha pasado que estando conectados mediante telnet a algún sitio habéis querido salir y la única forma que os ha venido a la cabeza ha sido cerrar la ventana de terminal, si es que tenemos la suerte de estar haciéndolo en un terminal?
Pues hoy he encontrado la forma de hacerlo: pulsar Ctrl + Alt Gr + ç.
Lo encontré en el wiki de Catsec.