Quizás si algún fan de Apple lee esto no le guste, espero no herir sentimientos, pero estoy sintiendo cierta tendencia a dar popularidad a una idea estúpida, vieja y que siendo por lo visto algo "nuevo" de Tiger (o de donde puñetas a Steve Jobs le haya dado la gana meterlo) llamado "WriteRoom". Voy a resumir qué es: un vim/emacs/nano/ed para gilipollas. Pero es que además, la interfaz es "verde fósforo". ¿Crean un sistema operativo con cualquier cantidad de polladas y gráficos y animaciones como el Tiger para luego utilizar "eso"?
Por otra parte, puede que sea yo, pero me da a mi que la estupidez se contagia, porque vienen unos y dicen: "Hmmmm... buena idea, vamos a llevarlo a la web" y toma, un sitio en AJAX que ni siquiera voy a enlazar. Ah! Pero tenemos .Net y una gran cantidad de herramientas, librerias, un IDE super mega chupi y cantidades ingentes de estupidez: toma DarkRoom y toma Q10. Que además son de código cerrado. ¿Será que les da miedo que alguien vea como hacer semejante "programa"?
Especialmente me molesto la página de Q10 donde explicitamente pone: "No version for Linux or Mac is planned." No lo necesitamos! Esa gilipolles de software existe desde la prehistoria de la computación!
Eso me molesto, pero lo que realmente me pone los pelos de punta es que luego "usuarios" de Linux van y se bajan el programa para luego ejecutarlo con Wine!!!
¿Quieres un editor pantalla completa? ¿Qué tal si te pulsas Ctrl+Alt+F1 y ejecutas el puto vi que viene por defecto en cualquier distribución... Joder, es que en cualquier instalación de Unix y derivados viene por defecto, allí, esperando. Cambia los colores a la consola y listo!
Para rematar el tema, estos editores de ultima generación integran correctores ortográficos, temas de colores y quien sabe, quizás en un futuro alguna brillante mente piense mientras está escribiendo en estas aplicaciones de ultima generación: "y si añado marcas a mi texto para..."
Nada, mejor será que en la próxima versión del MacOSX HelloKitty los gurus de Apple se re inventen el TeX. O mejor aun, saquen una nueva versión HKP (HelloKittyPages) que "increíblemente" te permitirá añadir cosas tan guays como referencias y enlaces.
A ver si al menos así terminan de matar al jodido MSWord y dejan de enviarme "pantallazos" en un fichero .doc
Esto me pasa por leer blogs a estas horas... ainsh...
Editores Full Screen
Tarjeta Personal (Java)
Siguiendo la idea de Luis en su blog Mal Código me he currado una tarjeta personal con InkScape para valorar y contrastar los resultados. En la entrada original Luis utiliza Haskell para su tarjeta, en este caso he utilizado Java.
El código, en caso de que no sea legible dice algo así:
package the.world.spain.madrid;
public class BusinessCard{
public static void main(String[] args){
IngInformatico aayuso = new IngInformatico();
aayuso.setFullName("Alejandro Ayuso");
aayuso.setProfile("Programador");
aayuso.setContactNumber("**********");
aayuso.setEmailAddress("*************** at yahoo.com");
}
class IngInformatico extends HumanBeing{
private String fullname, profile, contact, email;
public void setFullName(String s){
fullname = s;
}
...
}
}
Ideas?
stderr, stdout y más
En uno de los posts anteriores explique un poco el tema del stdin y stdout. Sabemos que podemos encauzar la salida (stdout) de un programa como entrada para otro (stdin) y de esta manera realizar tareas complejas utilizando herramientas sencillas.
A parte de estos dos descriptores, tenemos el stderr o salida de errores. Básicamente, stderr es lo mismo que stdout pero contiene posibles errores que el programa quiera reportar por pantalla al usuario.
Por ejemplo, vamos a utilizar un error producido por "cat" y lo vamos a almacenar en un fichero utilizando ">"$cat foo.txt > foo.log
En este caso, foo.txt no existe. Dado que ">" es utilizado sólo para stdout, el fichero foo.log será creado, pero está vacío. En cambio, podremos ver en la consola el error devuelto por stderr:
cat: foo.txt: No such file or directory
Si queremos capturar este mensaje de error en un fichero foo.err tendremos que añadir el número "2" a ">":cat foo.txt 2> foo.log
Aquí le estamos indicando a Bash que capture el descriptor número 2 (stderr) y lo envié al fichero. Recordemos que stdin es 0 y stdout es 1.
De igual manera podemos mezclar stdout y stderr. La utilidad de esto la encontramos cuando queremos ejecutar algún programa de forma automática (utilizando cron, por ejemplo) o desde un script y deseamos capturar toda la información posible en algún fichero al que podamos acceder posteriormente.
Entonces, el tema es bastante sencillo. Vamos a hacer un "tail" de dos ficheros y todas las salidas vamos a enviarlas a dos ficheros foo.out y foo.err.$tail /var/log/dmesg foo.txt >foo.out 2>foo.err
dmesg sabemos que existe, por lo tanto las ultimas lineas devueltas por "tail" serán capturadas por el stdout al fichero foo.out. En cambio el error devuelto al no encontrar el fichero foo.txt será enviado por stderr a foo.err:
tail: cannot open foo.txt for reading: No such file or directory
También podemos enviar las dos salidas a un único fichero e incluso encauzarlas como stdin para otro programa. En el primer caso vamos a utilizar "2>&1" lo cual vamos a ver en muchos scripts.$tail /var/log/dmesg foo.txt >foo.out 2>&1
La mejor manera de silenciar a un programa para que no perturbe la ejecución de nuestro script es enviar todas las salidas a /dev/null.$tail /var/log/dmesg foo.txt >/dev/null 2>&1
Si nuestro script necesita ejecutar otro programa y necesita sólo de su "exit status" el usuario que ejecuta el script no verá cuales programas estamos utilizando y no recibirá los posibles errores que de otra manera aparecerían en pantalla.
En segundo lugar, podemos realizar otro tipo de comprobaciones dirigiendo stderr y stdout como stdin de otro programa. Supongamos que creamos un script que sólo funciona con OpenSSH. Para comprobar que la versión que está instalada en el sistema es OpenSSH podemos utilizar lo siguiente:$/usr/bin/ssh -v 2>&1 | grep -q OpenSSH ; echo $?
0
Si nuestro cliente de SSH no fuera el OpenSSH obtendriamos lo siguiente:$/usr/bin/ssh -v 2>&1 | grep -q OpenSSH ; echo $?
En el caso de que nuestra versión de "grep" no tenga la opción "q quiet" volvemos a utilizar /dev/null
1ssh -v 2>&1 | grep OpenSSH >/dev/null 2>&1 ; echo $?
0
Donde $? es una variable que contiene el "exit status" del último comando ejecutado, en este ejemplo es grep.
