Nótese que esta entrada replica la publicada en este sitio.
Creo que todos los que usamos una computadora tenemos la posibilidad de resolver problemas que se presentan en su funcionamiento con un poco de paciencia, tiempo, voluntad de aprender y recurriendo a la información que hay en Internet. A partir de un error detectado a la hora de correr un programa que acababa de instalar en mi computadora, hace unas semanas me pude dar cuenta de la importancia que tiene el aprender a utilizar con provecho varias herramientas que suelen venir «de fábrica» con nuestras computadoras personales para, entre otras cosas, solucionar algunos problemas. Problemas, por otra parte, que parecen ser de lo más comunes actualmente, según me comentó hoy mi estimado amigo Francisco A. Moreno. Por ejemplo, algunos de los errores más comunes surgen cuando no hay compatibilidad entre el cómo se gestionan las diferentes codificaciones de lenguajes entre sistemas. No es lo mismo codificar mediante el Formato de Transformación Unicode de 8 bits (UTF-8) que mediante el American Standard Code for Information Interchange (ASCII). Y eso lo reconocen los programas y sus variantes, y por ese tipo de aparentes nimiedades dejan de funcionar, o se niegan a hacerlo. Pero siempre hay una solución y, curiosamente, está a la disposición de todos en cada máquina que utilizamos.
Hace unos años me propuse aprender el funcionamiento de los Sistemas de Información Geográfica (SIG), porque entendí que no solamente es una buena forma de producir cartografía de las regiones históricas que estudio (utilizarlos para visualizar mapas), sino también porque sirve como un recurso muy poderoso para analizar y poner a pruebas una serie de preguntas e hipótesis acerca de los procesos de conformación de territorios y jurisdicciones en siglos pasados. Pero sobre estas preguntas e hipótesis escribiré en otro lado para no perder por ahora el asunto principal de esta entrada.
El caso es que me decidí a utilizar un SIG que fuese software libre y de código abierto: el Quantum Gis [QGis (1.8.)]. Entonces lo utilizaba en OS X 10.8 y luego quise utilizarlo en Windows 8.1 Pro. (que era el sistema de la computadora de la oficina), pero cuando me enfrenté al problema de cargar GRASS en Windows dejé los experimentos por la paz. Como solamente utilizo el SIG con la finalidad de hacer borradores de mis mapas y pequeños análisis, y lo que me ofrece el programa sin usar el GRASS siempre ha sido más que suficiente. A fin de cuentas, cuando se requiera de un apoyo especializado, sé que el encargado del GIS de mi entorno laboral sabrá hacer las cosas mejor que yo, pero mi interés en cómo hace él su trabajo me permitirá comunicarme mejor y explicarle cuáles son mis necesidades.
Desde hace unas semanas volví a explorar sistemáticamente las posibilidades del QGis porque estoy dirigiendo un seminario sobre Historia y región – Tiempo y espacio en el trimestre enero-marzo, y quiero comunicarle a los asistentes que pueden aprovechar los SIG para la investigación histórica. Entonces aproveché la ocasión para instalar la nueva versión de QGis (2.12.1 ), y quise instalar la nueva versión de GRASS 7 para aprender más sobre sus posibilidades (para lo que se requiere tener alguna noción rudimentaria del lenguaje de programación Python), siguiendo cuidadosamente los pasos para la instalación previa de los diversos frameworks de William Kingesburye. Sin embargo, la terminal de OS X detectó un error a la hora de correr la aplicación:
ValueError: unknow locale: UTF-8
Esto es, el error más común que se presenta en el manejo de lenguajes entre sistemas. No voy a abundar más sobre ello por el momento. Los que conozcan más acerca de cómo funcionan nuestras PC sabrán que este error está relacionado con las variables de entorno, es decir, aquellos valores dinámicos que afectan al desempeño de un programa en un sistema determinado. Para los que no conozcan más a fondo el funcionamiento de sus máquinas (a fin de cuentas eso son: máquinas programables), no importa. La consigna es: «No entrar en pánico.»
Lo maravilloso es que este error me llevó a descubrir cómo utilizar mejor los recursos propios del sistema operativo de mi máquina (OS X 10.11.13), y que con un poco de imaginación se pueden ampliar a los demás sistemas operativos. Solamente necesitamos el editor de texto plano (TextEdit o NotePad) que viene como aplicación del sistema, así como un emulador de terminal (Terminal) o intérprete de comandos (Símbolo del Sistema o command prompt). Por supuesto que utilizar un editor de código resuelve muchas cosas, pero ésta última es una herramienta que no todos piensan utilizar mientras que las dos anteriores están presentes «de cajón» en sus computadoras.
Para solucionar el problema que tuve, en la Wiki de GRASS proponen crear o editar un pequeño programa que le permita a la computadora interpretar una serie de órdenes dadas por el usuario. Estos breves programas se deben crear mediante archivos bash que contienen las órdenes expresadas mediante líneas de comandos. En este caso, se recomienda crear uno llamado «.bash_profile» en el directorio raíz ($HOME o «~/elnombredemimac/»), que tenga las siguientes líneas:
export LC_ALL=en_US.UTF-8
export LANG=es_US.UTF-8
La solución implicó enfrentar dos tareas. En primer lugar, hacer visibles los archivos ocultos en el directorio raíz para confirmar que no había un archivo «.bash_profile» previo (cosa que suele ser así de fábrica) y, en segundo lugar, crear correctamente el archivo.
La forma más rápida de visualizar los archivos ocultos en OS X es mediante los comandos UNIX de Terminal:
ls -a
Pero si se quieren ver directamente en Finder es necesario utilizar Terminal para configurarlo de tal manera que aparezcan, mediante los comandos:
defaults write com.apple.finder AppleShowAllFiles -bool true
E inmediatamente hay que reiniciar el Finder con los comandos:
killall Finder
Para desactivar hay que hacer el proceso inverso:
defaults write com.apple.finder AppleShowAllFiles -bool false
killall Finder
Así, se pueden manipular los archivos ocultos desde Finder pero, aunque en apariencia es más sencillo hacerlo mediante la Interfaz Gráfica de Usuario (GUI) del Finder, en realidad lo más rápido es trabajar desde Terminal, además de correcto. Explico:
Crear el archivo «.bash_profile»
A falta de un editor de código, para crear un archivo «.bash_profile» es necesario utilizar un editor de texto que bien puede ser el TextEdit que viene incluido en el OS X. Sin embargo, encontré que es un error intentar crearlo desde la propia aplicación ya que a la hora de guardar el archivo no permite crear archivos sin extensión. Por un lado, borrar la extensión del nombre del archivo es difícil ya que no se puede editar un archivo oculto (todos los que empiezan por un punto) directamente desde la GUI del Finder así que hay que borrar la extensión desde el cuadro de información del archivo; y, por otro lado el archivo así creado guarda una serie de comandos «basura» dado que incluye información de estilo como si se tratase de un .rft o de un .html. Lo correcto es crearlo y abrirlo desde Terminal, cuidando de estar situados en el directorio raíz:
touch .bash_profile
open -a «TextEdit» .bash_profile
Se abrirá entonces la ventana de TextEdit sin ningún dato de estilo y podemos introducir los comandos arriba señalados:
export LC_ALL=en_US.UTF-8
export LANG=es_US.UTF-8
Para guardar es suficiente con salir de TextEdit. Si se tiene duda de la operación de los comandos del archivo «.bash_profile», basta con correrlo desde Terminal:
source .bash_profile
Una vez confirmado que no hay problema, GRASS corrió perfectamente y me pide que configure sus propiedades. Pero esto es cosa de hacer otra entrada. Mientras tanto, al estar navegando por Internet buscando la solución, me percaté de que este error de lenguaje no solamente esta relacionado con la instalación de GRASS, sino también de otros muchos programas que sirven para distintas cosas de interés en la investigación y divulgación del conocimiento.
Todo el proceso a mi me sirvió para aprender más. Espero que a alguien le sirva esta larga presentación.
cuaderno en crudo 