Noms de répertoires

[Yliur]

Bonjour

J'ai un petit problème avec des noms de répertoires.

J'ai chargé cl-fad avec quicklisp et quand je récupère des chemins de
répertoires contenant des crochets ouvrants [, j'obtiens parfois des
choses étranges :

Avec Clisp, il semble que tout aille bien :

(cl-fad:list-directory "/tmp/test")
-> (#P"/tmp/test/truc-1/" #P"/tmp/test/truc [hahaha]/")

Avec SBCL, j'obtiens des \\ devant les crochets :

(cl-fad:list-directory "/tmp/test")
-> (#P"/tmp/test/truc \\[hahaha]/" #P"/tmp/test/truc-1/")

Bon, peut-être que ce n'est qu'une représentation interne de SBCL...
Mais si je veux récupérer les noms des répertoires, les caractères
supplémentaires restent :

(directory-namestring #P"/tmp/test/truc \\[hahaha]/")
-> "/tmp/test/truc \\[hahaha]/"

D'après le manuel de SBCL
(http://www.sbcl.org/manual/Native-Filenames.html), on peut utiliser
une fonction pour récupérer le nom du répertoire sous une forme qui
convient au système hôte :

(native-namestring #P"/tmp/test/truc \\[hahaha]/")
-> "/tmp/test/truc [hahaha]/"


D'où les questions :

- Est-ce normal que SBCL introduise des caractères particuliers ?
Est-ce une manière pour lui de stocker certaines informations ?

- Y a-t-il une manière portable de récupérer de "vrais" chemins, qui
plaisent au système hôte ? Le problème de la représentation de SBCL
c'est que ça ne fonctionne que pour lui. Je ne sais pas si c'est
portable d'un système d'exploitation à l'autre, mais pas d'un
programme à l'autre (sauf écrit en Lisp et tournant sur SBCL).

- Pourquoi la fonction directory-namestring renvoie un chemin dans
cette forme particulière ?

Merci

Yliur

[Pascal J. Bourguignon]

Yliur <yl...@free.fr> writes:

> Bonjour
>
> J'ai un petit problème avec des noms de répertoires.
>
> J'ai chargé cl-fad avec quicklisp et quand je récupère des chemins de
> répertoires contenant des crochets ouvrants [,

Ce n'est pas une bonne idée. Renomme ces répertoires!

> j'obtiens parfois des
> choses étranges :

Pas surprenant...

> Avec Clisp, il semble que tout aille bien :
>
> (cl-fad:list-directory "/tmp/test")
> -> (#P"/tmp/test/truc-1/" #P"/tmp/test/truc [hahaha]/")
>
> Avec SBCL, j'obtiens des \\ devant les crochets :
>
> (cl-fad:list-directory "/tmp/test")
> -> (#P"/tmp/test/truc \\[hahaha]/" #P"/tmp/test/truc-1/")
>
> Bon, peut-être que ce n'est qu'une représentation interne de SBCL...
> Mais si je veux récupérer les noms des répertoires, les caractères
> supplémentaires restent :
>
> (directory-namestring #P"/tmp/test/truc \\[hahaha]/")
> -> "/tmp/test/truc \\[hahaha]/"
>
> D'après le manuel de SBCL
> (http://www.sbcl.org/manual/Native-Filenames.html), on peut utiliser
> une fonction pour récupérer le nom du répertoire sous une forme qui
> convient au système hôte :
>
> (native-namestring #P"/tmp/test/truc \\[hahaha]/")
> -> "/tmp/test/truc [hahaha]/"
>
>
> D'où les questions :
>
> - Est-ce normal que SBCL introduise des caractères particuliers ?
> Est-ce une manière pour lui de stocker certaines informations ?

Oui.

> - Y a-t-il une manière portable de récupérer de "vrais" chemins, qui
> plaisent au système hôte ?

Non.

> Le problème de la représentation de SBCL
> c'est que ça ne fonctionne que pour lui. Je ne sais pas si c'est
> portable d'un système d'exploitation à l'autre, mais pas d'un
> programme à l'autre (sauf écrit en Lisp et tournant sur SBCL).
>
> - Pourquoi la fonction directory-namestring renvoie un chemin dans
> cette forme particulière ?

Parce que les pathnames peuvent contenir des wildcards, qui sont
spécifiques à chaque implémentation. Il vaut donc mieux éviter les
pathnames contenant des caractères tels que *, [, {, ?, }, ], etc.


--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.

[Yliur]

Le Sat, 12 Nov 2011 12:15:35 +0100
"Pascal J. Bourguignon" <p...@informatimago.com> a écrit :

> Yliur <yl...@free.fr> writes:
>
> > Bonjour
> >
> > J'ai un petit problème avec des noms de répertoires.
> >
> > J'ai chargé cl-fad avec quicklisp et quand je récupère des chemins
> > de répertoires contenant des crochets ouvrants [,
>
> Ce n'est pas une bonne idée. Renomme ces répertoires!

Euh... ce sont des noms valides sur le système hôte, donc c'est un peu
étrange de m'en passer sous prétexte qu'ils ne conviennent pas très
bien à SBCL. D'autant que si le programme est distribué je ne peux pas
décider de ce qu'il va rencontrer. :s

> [...]

Merci pour les réponses et explications. :)

[Pascal J. Bourguignon]

Yliur <yl...@free.fr> writes:

> Le Sat, 12 Nov 2011 12:15:35 +0100
> "Pascal J. Bourguignon" <p...@informatimago.com> a écrit :
>
>> Yliur <yl...@free.fr> writes:
>>
>> > Bonjour
>> >
>> > J'ai un petit problème avec des noms de répertoires.
>> >
>> > J'ai chargé cl-fad avec quicklisp et quand je récupère des chemins
>> > de répertoires contenant des crochets ouvrants [,
>>
>> Ce n'est pas une bonne idée. Renomme ces répertoires!
>
> Euh... ce sont des noms valides sur le système hôte, donc c'est un peu
> étrange de m'en passer sous prétexte qu'ils ne conviennent pas très
> bien à SBCL.

Le système hôte n'existait pas quand le standard Common Lisp a été
défini.

Si tu veux travailler avec des path POSIX, alors il faut utiliser
des STRING, pas des PATHNAME Common Lisp.

> D'autant que si le programme est distribué je ne peux pas
> décider de ce qu'il va rencontrer. :s

Utiliser opendir(3), readdir(3) et closedir(3) au travers de CFFI pour
collecter les path POSIX.

Note qu'il est possible que tu ne puisse pas ouvrir certains de ces path
POSIX avec CL:OPEN (en tout cas, de manière portable). Mais je suppose
que tu peux toujours utiliser open(2) au travers de CFFI...


Je n'ai pas étudié cl-fad, peut être il y a-t'il des utilitaires dedans
pour aider, et s'ils ont un comportement différent sur différentes
implémentations, c'est peu être une bogue pour cl-fad?

[Yliur]

Le Thu, 17 Nov 2011 07:06:43 +0100

"Pascal J. Bourguignon" <p...@informatimago.com> a écrit :

> Je n'ai pas étudié cl-fad, peut être il y a-t'il des utilitaires
> dedans pour aider, et s'ils ont un comportement différent sur
> différentes implémentations, c'est peu être une bogue pour cl-fad?

Il s'agit d'un dérivé des fonctions proposées dans le livre de Peter
Seibel, il n'y a pas l'air d'y avoir grand chose en plus. Et le
mainteneur a l'air très occupé actuellement, d'après sa réponse.

Pour l'instant je vais me contenter des fonctions de SBCL, on verra
plus tard pour un éventuel portage sur d'autres implémentations.