Tag bash - Userlinux.net

Estaba creando un pequeño script en BASH en el que necesitaba variables a partir de los nombres de otras variables, en tres palabras, "variables de variables". Pensé que sería sencillo, cuestión de jugar un poco con los caracteres que definen las variables -$(){}- no debería complicarse demasiado.

Sin embargo el método chino de prueba/error no sirvió de mucho porque despues de un buen rato seguía como al principio pero con menos paciencia y nulas ganas de perder más tiempo navegando entre manuales, Google y otros recursos que no me hacían avanzar.

Las alternativas, preguntar al amigo Juanjo (en cierto modo el script tenía relación con él), desconectar durante un rato y/o matar a un gatito. Visto que la última no era ni justa ni real -ni lo admitiría aunque lo hubiese hecho-, las dos anteriores si consiguieron sus frutos:

Me acabo de encontrar en el twitter de @javier_fazouro con uno de los enlaces más interesantes y divertidos en mucho mucho tiempo. Se trata de cómo dormir a un bebé con un bash script de 5 lineas. Primero leed el script y luego podéis ver el vídeo:

while [ 1 = 1 ]
do
	eject
	eject -t
done

No tiene desperdicio, la imaginación de la gente es bestial. ¡Buenísimo!

Hace poco más de mes y medio escribí un post que se refería a un script para controlar los cuelgues de MySQL. En dos palabras: no funciona.

El motivo es el siguiente, en ese script se monitoriza el %CPU de un ps y se compara con el valor homónimo en top, craso error, puesto que ni de lejos son lo mismo:

• %CPU top: Uso de CPU en porcentaje real.
• CPU ps: Porcentaje de uso de CPU durante todo el tiempo de vida del proceso (una media entre CPU y tiempo de vida).

Mientras que el primero es instantáneo y ofrece porcentajes reales, el segundo no ofrece más que una media y, en procesos con tiempo de vida muy largo -como puede ser un mysqld- lo lógico es que ese porcentaje no sea muy elevado.

Lección aprendida, a ver si Monit o cpulimit nos pueden ayudar con este desaguisado.

Imagino que hablar de controlar se me antoja demasiado duro, pero bueno, una máquina que nos trae fritos con la carga de MySQL y todavía no hemos localizado el motivo, así que dejo esto en el cron:

#!/bin/bash
LOG_FILE='/var/log/compruebamysql.log'
MYSQL_PID=`pidof mysqld`
CPU_LOAD=`ps up $MYSQL_PID | tail -1 | awk '{ print $3 }'`
CPU_LOAD2=`echo $CPU_LOAD | sed "s/\./\,/g"`
CPU_INT=`printf "%.0f" $CPU_LOAD2`

if [ "$CPU_INT" -gt "80" ]; then
        echo "[ `date +'%d-%B-%G %H:%M:%S'` ] - Se ha reiniciado MySQL por sobrecarga" >> $LOG_FILE
        /etc/init.d/mysqld restart
fi

Tan simple como comprobar que la carga de CPU no excede un porcentaje concreto (el 80% en este caso) para hacer un restart y escurrir el problema. Sé que no es óptimo pero espero que me cubra algunos días.

A mi se me ha pasado alguna vez por la cabeza, pero por no ponerme a abrir todos los archivos del proyecto e ir sumando cual homínido cavernícola, me he decidido a usar el bash power:

# for i in `find trunk/ -name *php -type f`; do cat $i >> tmp.txt; done ; wc -l tmp.txt ; rm tmp.txt
83986 tmp2.txt
#

Seguro que hay formas más elegantes de obtener dicho número, pero -as ever- ha resultado curioso llegar a la solución del jeroglífico.

Por cierto, ya estamos cerca de las 90k, creo que hay libros que tienen menos así que otro objetivo vital cumplido (¡cáscaras!, no valen libros colaborativos, tendrá que ser algo propio).

Screen es una de esas herramientas de uso diario que -por lo menos a mi- me resulta imprescindible, extensible a cualquier sysadmin, linuxero y/o amante del la consola (terminal).

Y cada vez encuentro tips que la hacen más imprescindible si cabe. Lo penúltimo -nunca pierdo la esperanza- ha sido el fichero .screenrc, donde además de definir las preferencias de la aplicación, puedes organizar las ventanas y lo que se va a abrir en ellas:

Una de las pocas limitaciones que había visto en el uso diario de screen tenía que ver con abrir varios de forma anidada, puesto que los comandos de control (ctrl+a+a, ctrl+a+"...) solo funcionan dentro del primer screen.

Para hacer que funcione uno dentro de otro tan solo tenemos que cambiar la forma de acceder a los comandos de control, por ejemplo en vez de hacerlo con ctrl+a usar ctrl+e.

Entonces, a la hora de lanzar/recuperar un screen dentro de otro podemos indicarle esto mismo en linea de comandos con la siguiente opción:

$ screen -DRU -e^Ee

Así recuperaremos la última sesión detacheada del screen con soporte para utf-8 y comandos de control marcados por ctrl+e. Totalmente compatible con su predecesora.

Tip sacado de Unsec.

That's the question. Aunque estas 4 lineas que a continuación voy a pegar son un nano-script para comprobar si se está comprimiendo en servidor y la diferencia de tamaño con la versión plana:

#!/bin/bash
wget -q -O plano $1
wget -q -O gzip --header="Accept-Encoding: gzip" $1
du -h plano gzip
rm plano gzip

Totalmente basado en ésta anotación del amigo Juanjo. Poco más que un copy&paste en toda regla, espero que un trackback lo arregle ;). Thanks anyway.

¿Y si queremos buscar un paquete apt y no recordamos la sintaxis del apt-cache?, tampoco sabríamos hacer este script, pero bueno:

#!/bin/sh
# Buscar un paquete apt (mysearch.sh)
if [ "$1" == "" ] ; then
    echo "Has de especificar un paquete..."
    exit
fi
apt-cache search $1 | grep $1

Otro de los mini ejercicios de aprenda bash como si estuviera en primero que propuse durante la docencia.

Empiezo una serie de mini tips en bash para publicar varias notas que tenía en el olvido y empezar la migración de contenidos del wiki a la web. Con este pequeño post se pretende inaugurar la sección de código.

El script es sencillo, comprobar la conectividad con google (por ejemplo):

#!/bin/sh
# Respuesta $? (0 si todo es OK)
PEPE=`ping -c 1 google.es`
echo $?

Redirigir a /dev/null y 2>&1 para que los errores stderr (2) vayan al mismo sitio que la stdout (1):

#!/bin/sh
PEPE=`ping -c 1 google.es`
echo $?

PEPA=`ping -c 1 loro.yar > /dev/null 2>&1`
echo $?

Y vereis la diferencia entre una sentencia que se ejecuta correctamente y otra que no.