Archivo por meses: marzo 2015

Personalizando zsh: oh-my-zsh

En la anterior entrada os comenté que zsh es un intérprete de comandos para GNU/Linux (también para otras plataformas, como MAC OS) que permite, entre otras cosas, un nivel de personalización mucho más alto que bash.

Para este fin nació oh-my-zsh, que no es más que una aplicación (un framework en realidad) que permite personalizar fácilmente nuestro zsh.

Para ello consta de multitud de plugins y temas y permite adaptar el aspecto y funcionalidad de zsh a nuestras preferencias personales. Es una forma sencilla (*) de realizar cambios en la configuración de zsh.

Para instalarlo, nada más fácil:

$ wget --no-check-certificate http://install.ohmyz.sh -O - | sh

Una vez instalado simplemente editamos el fichero .zshrc, que tendremos en nuestro directorio home.

Para cambiar el tema del prompt modificaremos el parámetro ZSH_THEME. Por ejemplo:

ZSH_THEME=robbyrussell

Si no queremos ningún tema (estaría todo como antes de instalar oh-my-zsh) lo dejaremos así:

ZSH_THEME=""

Existe una lista de temas para poder aplicar en el prompt de nuestro shell favorito, la podéis encontrar en este enlace.

Como indican aquí, también es interesante usar el tema random, que lo que hace es ir cambiando de un tema a otro aleatoriamente. De esta forma podemos ir viéndolos todos y quedarnos al final con el que más nos guste.

Los plugins permiten añadir cosas interesantes, como autocompletado de parámetros de comandos. Por ejemplo, al escribir zypper  (instalador de paquetes de openSUSE) y a continuación escribís in y pulsáis tabulador, os dirá qué parámetros acepta.

Aquí tenéis una lista de los plugins que existen para oh-my-zsh.

Para añadir un plugin simplemente tenéis que añadir el nombre del plugin a la lista entre paréntesis que hay tras el parámetro «plugins» dentro del fichero .zshrc. Por ejemplo:

plugins=(rails git ruby)

Si conocéis más formas de usar oh-my-zsh para mejorar la experiencia con zsh sentíos libres de dejar un comentario.

 

(*) En una próxima entrega veremos una forma de personalizar zsh aún más sencilla que ésta :-O.

Pasando de bash a zsh

Hace tiempo oí hablar de zsh, un shell bastante potente que tenía peculiaridades que lo hacían, a priori, mejor o, al menos, más completo que el archiconocido bash.

Por cuestiones de tiempo no lo pude probar en su momento, pero no hace mucho me decidí a instalarlo y echarle un vistazo.

Realmente, una vez instalado, zsh (o Z shell) es muy parecido al bash, por lo que si el uso que le dais al terminal es ocasional no vais a notar mucha diferencia en primera instancia. De hecho, en estos casos casi que os recomiendo que ni lo instaléis, porque bash funciona perfectamente y las bondades de zsh son útiles para uno uso más intensivo.

La única excepción que veo a esto es que, aunque no uséis mucho la terminal, queráis darle un aspecto más chulo (más colorido, mostrando más datos, más personalizado), ya que estos menesteres con zsh no son complicados y los resultados son bastante decentes.

Si le dais más uso sí que le sacaréis mayor provecho ya que muchas de las funcionalidades que zsh incorpora y de las que bash carece (*).

Hay un documento (una presentación web) de visita obligada si queréis ver qué puede hacer zsh y que otros shells no puede, y es ésta. En ella se muestran cosas que puedes hacer en zsh y que, por ejemplo, en bash no se puede.

En ella muestran ejemplos prácticos de por qué os puede resultar muy útil sustituir vuestro intérprete de comandos actual por zsh. Os comento algunas interesantes:

  • El tabulador que se usa para completar un comando, si lo usáis tras introducirlo, os va a completar con los parámetros del comando. Por ejemplo, si ponéis zypper in y le dais al tabulador, os va a mostrar los distintos parámetros de zypper que comienzan con las letras in, como pueden ser info o install, por ejemplo.
  • Si accedéis a una ruta de directorios muy profunda, como por ejemplo:
/home/amms/un/directorio/cualquiera/pero/profundo

y queremos ir al directorio:

/home/amms/otro/directorio/cualquiera/pero/profundo

no hace falta que reescribamos la ruta completa, sino que podemos poner esto:

cd un otro

y lo que hará será sustituir en la ruta actual el directorio un por otro, ahorrándonos mucho tiempo y la molestia de tener que reescribirla por completo.

  • Existe la posibilidad de poner una cadena como prompt derecho. Podemos usar distintos parámetros para personalizarlo (también el izquierdo), pudiendo ser éstos la fecha, la hora, la ruta, el usuario, usar colores, etc.
  • Se pueden usar lo que se denominan alias globales. Ejemplo:
alias -g p='-ef | grep'

que es muy útil, al menos para mí.

Para instalarlo podéis usar el gestor de paquetes de vuestra distro, porque está en todas las distros conocidas (si no lo está, cambiad de distro, ¡ya!). Una vez instalado tenéis que especificar que queréis que éste sea vuestro shell por defecto. Para ello, ejecutáis como root:

chsh -s `which zsh` $USER

Si os animáis a instalarlo y tenéis alguna pega me podéis poner un comentario y lo vemos.

En otro artículo os hablaré de cómo personalizar fácilmente zsh (sí, me refiero a  usar cosas como oh-my-zsh o antigen).

(*) Realmente hay algunas cosas que sí que se pueden implementar en bash con funciones pero es un poco más rudimentario que zsh en general para aspectos de personalización y de funcionalidad práctica en general.

Monitorizar temperatura de disco duro con hddtemp

hddtemp es un comando de Linux que permite monitorizar la temperatura del disco duro de vuestro equipo. Es un comando que hay que ejecutar como root (o con sudo). Hay que pasarle como parámetro el disco duro que queremos monitorizar. Ejemplo:

[ user ] [~] > /usr/sbin/hddtemp /dev/sdb
/dev/sdb: ST9750420AS: 39°C

Si lo queréis ejecutar con vuestro usuario debéis aplicarle el setuid bit de esta forma:

chmod u+s /usr/sbin/hddtemp

Con esto se consigue que el programa hddtemp adquiera los permisos el propietario del mismo (root).

Yendo un paso más allá, podéis incorporar esta información en conky. Conky es un programa para monitorizar cosas en vuestro PC y, en general, mostrar información al respecto. En este caso particular, nos mostraría constantemente la temperatura del disco duro.

Solucionar problema con excepción en Autokey

Hace tiempo os hablé de una herramienta que mejora nuestra productividad a la hora de usar el teclado: Autokey. Aunque funciona muy bien a veces os puede dar un fallo que impida que se ejecute con normalidad.

Aquí os voy mostrar un error que me ocurrió hace poco y cómo lo solucioné.

De repente observé que no funciona ninguna abreviatura, así que me fijé en los mensajes que soltaba en la línea de comandos. En concreto, los errores eran éstos:

Exception in thread KeypressHandler-thread:
Traceback (most recent call last):
 File "/usr/lib/python2.7/threading.py", line 810, in __bootstrap_inner
 self.run()
 File "/usr/lib/python2.7/site-packages/autokey/iomediator.py", line 204, in run
 target.handle_keypress(rawKey, modifiers, key, windowName, windowClass)
 File "/usr/lib/python2.7/site-packages/autokey/service.py", line 179, in handle_keypress
 currentInput, windowInfo, True)
 File "/usr/lib/python2.7/site-packages/autokey/service.py", line 304, in __checkTextMatches
 if item.check_input(buffer, windowInfo):
 File "/usr/lib/python2.7/site-packages/autokey/model.py", line 735, in check_input
 abbr = self._should_trigger_abbreviation(buffer)
 File "/usr/lib/python2.7/site-packages/autokey/model.py", line 134, in _should_trigger_abbreviation
 if self.__checkInput(buffer, abbr):
 File "/usr/lib/python2.7/site-packages/autokey/model.py", line 147, in __checkInput
 stringBefore, typedAbbr, stringAfter = self._partition_input(buffer, abbr)
 File "/usr/lib/python2.7/site-packages/autokey/model.py", line 194, in _partition_input
 stringBefore, typedAbbr, stringAfter = currentString.rpartition(abbr)
ValueError: empty separator

La causa está en que hemos introducido mal una abreviatura. A veces, al teclear la abreviatura puede que se inserte una coma «,». En este caso, el programa da error y, aunque aparentemente está funcionando (aparece el icono con forma de «A» en la bandeja del sistema -en la barra de tareas-) no lo está haciendo.

Una vez eliminada la coma queda subsanado el error y todo vuelve a funcionar con normalidad.

 

 

Levantando servicios tras el arranque con systemd

Hace no mucho comenté en un artículo que tras la adopción de systemd en openSUSE poco a poco ha ido cambiando la manera de gestionar el arranque del sistema.

Una ventaja -entre otras- es que arranca muy rápido, pero un inconveniente -para mí, al menos- es que no funcionan los scripts de if-up.d. Os recuerdo que estos scripts se ejecutan cada vez que la interfaz de red se levanta. Estoy me venía genial para levantar el servicio Mediatomb que configura mi PC como un servidor DLNA (para ver las pelis, las series, etc., en la tele).

En openSUSE 13.2 ya no funcionan los scripts if-up.d como comenté en dicho artículo. A partir de ahora hay que crear un servicio de systemd que arranque automáticamente en cada inicio. En systemd, los servicios se llaman units. Dado que hay mucha información sobre systemd en Internet, no voy a explicar cada aspecto nuevo. Simplemente diremos que unit es un archivo que especifica un proceso que  systemd arrancará y target es un conjunto de units. El target más importante para nosotros será el multi-user.target, que es equivalente al runlevel 5 de SysVinit.

A continuación vamos a comentar cómo crear un servicio personalizado (una unidad –unit-) para ejecutar el programa que queramos en el arranque. Además, veremos cómo especificar si éste depende de otro (*).

Básicamente, se trata de crear un archivo de texto plano en /etc/systemd/system con el nombre MISERVICIO.service. Lógicamente, reemplazáis MISERVICIO por el nombre que queráis. En mi caso se llama mediatomb.service y éste es su contenido:

[Unit]
Description=Mediatomb
After=mysql.service
Requires=mysql.service

[Service]
TimeoutStartSec=0
ExecStart=/usr/bin/mediatomb-mysql

[Install]
WantedBy=multi-user.target

Vemos tres secciones principales: Unit, Service e Install. Vamos a analizar los distintos parámetros de cada sección.

En la primera sección (Unit) especificamos una descripción. En la segunda indicamos que el servicio «mysql» debe estar arrancado antes que el nuestro. La opción Requieres indica que la activación/desactivación de nuestro servicio depende de la activación/desactivación del especificado en dicha opción.

En la sección Service especificamos, entre otros, el comando a ejecutar: ExecStart. El parámetro TimeoutStartSec es el tiempo tras el cuál, si el servicio no ha arrancado, se considera fallo y se detiene. Si se especifica «0», como ha sido el caso, se ignora este parámetro.

Por úlitmo, en la sección Install especificamos la cláusula WantedBy, en la que indicamos el target al que pertenece dicha unidad.

Aquí y aquí tenéis más información sobre los distintos parámetros que acepta este fichero.

Más información sobre las generalidades de systemd:

(*) Esto es fundamental en mi caso, pues tengo configurado mediatomb con mysql y necesito este último en ejecución antes de arrancar mediatomb.