La extravagante posibilidad de los espacios en los nombres de archivos.

Tiempo atrás, hace muchos, muchos años, los nombres de archivos en MS-DOS estaban limitados a 8 caracteres + 3 caracteres de extensión para un PC (no, Linux todavía no existía, o quizás sería mejor decir que ni era capaz como ahora ni era conocido por el gran público). Al fin y al cabo, estamos hablando de los primeros años 90, mientras que Linux con su EXT3 no estaría disponible para el gran público y sus PC's hasta principios de los 2000 (personalmente, yo lo hice a través de Mandrake Linux).

Un buen día los ingenieros de Microsoft decidieron que era necesario permitir que los nombres de archivo pudiesen incluir espacios.

Y lo hicieron. De repente, se podían poner espacios en los nombres de archivos. Ya está. Solo recuerda poner dobles comillas (") cuando utilices espacios.

Además, confiamos tanto en nuestra capacidad, que hemos decidido que el directorio de usuarios, ese /home de *nix, se va a llamar "Documents and settings". Además, el directorio de las aplicaciones va a pasar a llamarse "Program files". En España, esto fue "Archivos de programa". ¿Qué puede salir mal, al fin y al cabo, cuando incluyes un carácter de control prohibido hasta ese momento (o simplemente no soportado) en la lista de posibles caracteres de un archivo?

Casi todo salió mal. Los programas dejaron de funcionar. Un problema aparentemente no había sido previsto por nadie: el número de caracteres máximo que soporta una línea de comando es 8191, pero muchos programas utilizaban tamaños de buffer mucho menores. Claro, una cosa es:

c:\bin\awesomeApp\awesome.exe c:\user\baltasarq\docs\midoc1.doc c:\user\baltasarq\docs\midoc2.doc c:\user\baltasarq\docs\midoc3.doc

Y otra, muy distinta...

c:\archivos de programa\awesomeApp\awesome.exe c:\documents and settings\baltasarq\docs\midoc1.doc c:\documents and settings\baltasarq\docs\midoc2.doc c:\documents and settings\baltasarq\docs\midoc3.doc

Empieza a multiplicar.

Pero el mayor problema era que los programadores no incluían las comillas cuando había espacios en sus nombres de archivo. Así que había que decidir: ¿dejamos que caigan, o corregimos sus errores silenciosamente?

Si has tomado la decisión de renombrar tu directorio de aplicaciones como "Program files", lo más probable es que te sientas inclinado a dejar que los programas fallen, y que sus programadores los corrijan. Pero estamos hablando de Microsoft, que quiere que utilices su sistema operativo, adalid por tanto de la compatibilidad hacia atrás.

En resumidas cuentas, cuando Windows debe ejecutar un programa como "c:\program files\AwesomeApp\awesome.exe", va a comprobar a poner las comillas de las siguientes formas, hasta que una funcione.

• "c:\program"
• "c:\program files"
• "c:\program files\AwesomeApp"

Si estamos en España, la cosa se complica:

• "c:\archivos"
• "c:\archivos de"
• "c:\archivos de programa"
• "c:\archivos de programa\AwesomeApp"

En fin, en Linux también se soportó el espacio como carácter válido para formar parte del nombre de archivos. Se soportó de dos maneras: con las famosas dobles comillas (", o incluso la comilla simple: '), y con la barra invertida.

"/usr/bin/awesome app"/app /home/baltasarq/docs/middoc1.doc

/usr/bin/awesome\ app/app /home/baltasarq/docs/middoc1.doc

Así, se puede crear un archivo con espacios mediante:

$ touch mi\ archivo.txt
$ ls
mi archivo.txt
$ touch "mi segundo archivo.txt"
$ ls
mi archivo.txt    mi segundo archivo.txt

Para mi, esto siempre ha sido una extravagancia, una rareza inútil que solo trae problemas insospechados de toda índole. Quizás porque empecé a trabajar con el PC en MS-DOS o qué sé yo, pero siempre me he preguntado: ¿por qué?

Y sobre todo: ¿por qué así?

Si estás utilizando un carácter para indicar que acaba un nombre de archivo y va a empezar otro, o un parámetro... ¡Es una locura permitir este carácter como nombre de archivo! O al menos, para mi lo es.

Replanteémonos este problema: quiero permitir que los usuarios puedan incluir espacios en sus nombres de archivos.

De acuerdo, pero, ¿quiere decir esto que tengo que permitir literalmente espacios dentro de los nombres de archivos? Yo creo que no. Si yo soy el programador tras el sistema operativo, puedo hacerle pensar el usuario que puede utilizar espacios en sus nombres de archivos, ofreciéndole una vista sobre sus nombres de archivos.

Yo ofrecería una codificación, una de alto nivel. Yo utilizaría el carácter subrayado ("_", también conocido como guión bajo), de manera que una pequeña capa superior del sistema de archivos se encargaría de traducir los espacios en subrayados, y viceversa.

#include <stdio.h>
#include <stdlib.h>
#include <string.h>


const int MAX_FILE_NAME = 254;


const char *sys_file_name_from_usr_file_name(char *usr_file_name)
{
    for(char * ptr = usr_file_name; *ptr != '\0'; ++ptr) {
        if ( *ptr == ' ' ) {
            *ptr = '_';
        }
    }

    return usr_file_name;
}

const char *usr_file_name_from_sys_file_name(char *sys_file_name)
{
    for(char * ptr = sys_file_name; *ptr != '\0'; ++ptr) {
        if ( *ptr == '_' ) {
            *ptr = ' ';
        }
    }

    return sys_file_name;
}

Y permitiría "dejar pasar" los subrayados sin modificar. Es más, no lo escondería: todo lo contrario. Todo el mundo sabría que un subrayado en el nombre de archivo es un espacio.

$ touch mi_archivo.txt
$ ls
mi archivo.txt

$ touch mi_segundo_archivo.txt
$ ls
mi archivo.txt    mi segundo archivo.txt

$ touch otro archivo.txt
$ ls
mi archivo.txt    mi segundo archivo.txt
otro              archivo.txt

Para mi tiene todas las ventajas: es legible, se "entiende" como un espacio, pero no lo es. El carácter de control para indicar que termina un archivo y comienza otro (o un parámetro) sigue siendo el mismo, y funcionando igual.

Y desde el punto de vista de una interfaz gráfica de usuario, ni siquiera sería necesario conocer la existencia del subrayado, aunque de nuevo no haría ningún daño saberlo.

Se ve que lo que tenemos ahora... ¿es mejor? Yo creo que no, y siempre hay extraños casos de uso produciendo errores. Pero yo qué sé.