lunes, 28 de enero de 2013

Nada que no pueda hacer un script de bash (parte 2)

Siguiendo con esta idea de utilizar bash para combinar algunas de las cientos de pequeñas herramientas que se encuentran en casi cualquier GNU/Linux para automatizar tareas varias, en este segundo post traigo algunos ejemplos adicionales. Hay que aclarar, que al igual que en la primer parte, los ejemplos no están explicados 100%, sino que se comenta rápidamente qué hacen y cómo. Un lector con algunos conocimientos mínimos de programación y del uso de la linea de comandos debería poder entender los ejemplos, pero seguramente necesitará googlear un poco más o consultar los manuales para poder modificar estas ideas para sus propias necesidades. De todas formas, el objetivo era solo tirar la primera piedra, para despertar un poco la curiosidad, y si les interesa podrán encontrar fácilmente mucho más material.

lunes, 21 de enero de 2013

Nada que no pueda hacer un script de bash (parte 1)

El título de este post es una frase que uso mucho. Bash, el shell más común en sistemas GNU/Linux, es un intérprete de comandos en modo consola. Soy de esos que usan mucho mucho la consola, porque creen que así las cosas se hacen más rápido. Mucho más rápido, solo que hay que saber un montón muy grande de trucos, nombres comandos, y argumentos, en apariencia crípticos. Por eso la gente prefiere las ventanitas gráficas, porque no hay que recordar nada, todo es intuitivo. Y las ventanas son geniales para eso, pero es ridículo a mi criterio (y el de otros, recomiendo mucho esta vieja lectura, también en español), comparar las limitaciones de una interfaz gráfica simple, con la potencia de una simple linea de comandos.

Pero tampoco es que tengamos que recordar tantos comandos. Diría que la mayoría de los que usamos las terminales usamos regularmente un 5% de los comandos disponibles, y solo sabemos un 3% de sus argumentos. Es así, se puede hacer mucho con poco. Y si somos haraganes, o nos gusta automatizar todo, podemos tomarnos el trabajo de armar un script con las partes difíciles, largas o tediosas, para luego nunca más tener que escribirlas otra vez, sino simplemente invocar al script. Yo tengo mi notebook llena de pequeños scripts, para todo. Y por eso en realidad no sé tanto de bash, porque las operaciones simples son pocas, y las complicadas están dentro de scripts, así que no necesito memorizarlas. Pero sí necesité ejemplos en primera instancia para hacer esos scripts. Y de eso se tratan estos posts. Pienso presentar algunos ejemplos cortos y explicarlos para que vean la potencia de bash y otras herramientas con las cuales se combina, y para que vean el tipo de cosas que se pueden hacer. Espero que aprendan algo, los motive a acercarse a las lineas de comandos, y se les ocurran ideas para sus propias tareas.

jueves, 10 de enero de 2013

¿Todos para uno o uno para todo?

Ya expliqué hace poco que PSeInt está compuesto por varios programas separados, la mayoría de ellos independientes. El usuario percibe al conjunto de programas como si fuera uno, con varias partes trabajando en conjunto. wxPSeInt es el programa que se encarga de ser la interfaz con el usuario, y de gestionar la ejecución de los otros de forma más o menos transparente. Veamos ahora porqué esto es así y qué tiene de interesante o no, según mi experiencia con este modelo.

Empezando por el porqué, tengo que decir que es más bien una cuestión histórica. Primero que nada, lo que quería escribir cuando empecé con PSeInt era solo un intérprete (el módulo pseint), el editor de texto surgió inmediatamente como agregado necesario para poder mostrar las bondades del intérprete, pero los demás módulos no estaban previstos. Desde ese punto de vista, tendría solo dos módulos, un editor de texto y un intérprete de consola. La comunicación sería mínima: el editor guardaría el pseudocódigo en algún temporal y lanzaría el intérprete diciéndole por argumento en la linea de comandos donde estaba ese temporal. Si había errores, el camino de vuelta también sería mediante un archivo temporal. Esto sonaba razonable, y este era más o menos el modelo que seguían la mayoría de los IDEs en lenguajes reales, así que jamás se me cruzó por la cabeza plantear otra alternativa. Mucho tiempo después se fueron agregando algunos módulos nuevos que tampoco requerían de mayor comunicación, como el visualizador (no editor) de diagramas de flujo, o el que exporta a código C++. Por eso seguí con el mismo esquema. Tal vez la primer duda respecto a si este era el camino a seguir vino cuando quise integrar la ejecución paso a paso, y también más tarde para el análisis sintáctico en tiempo real.