Again: list-directory replaces [ characters in filenames with \\[, resulting in an extra backslash...

[edicl]

Again: list-directory replaces [ characters in filenames with \\[, resulting in an extra backslash...

[stassats]

Try uiop:native-namestring

[hanshuebner]

cl-fad is a wrapper around the CL pathname system, and the CL pathname system is not able to deal with all possible file names that can occur. It is a portability wrapper around different file systems, and it only works reliably for files that one creates using it. Files with arbitrary path names created with other programs, or even with CL using non-portable characters in the name are causing portability problems, and cl-fad is not going to fix that. If you need to deal with arbitrary file names, don't use CL pathnames for it. One way to do this is by using IOlib.

If you have a fix for your problem in cl-fad, please submit a pull request.

[stacksmith]

As I understand it, the [ and ] characters are valid in all filesystems (see https://en.wikipedia.org/wiki/Filename for example). It is reasonable to expect cl-fad to handle valid characters in filenames.

I will see what I can do about fixing it, although I was hoping someone more qualified from the cl-fad team could do it better.

[hanshuebner]

Random Wikipedia pages are not a credible source to support your case.

When CL was created, different file systems were in common use and its pathname system is meant to support these. VMS, for example, would use path names like FOO::BAR$BAZ:[DIRECTORY.SUB-DIRECTORY]FILE-NAME.EXT;234 and Common Lisp would gladly support that.

[stacksmith]

And I thought correctness was something all Lisp programmers were concerned with.

Sorry, Hans, I guess VMS pathnames should be supported, but Linux, Windows and Apple - not so much.

By the way, cl-fad would read your VMS path as FOO::BAR$BAZ:[DIRECTORY.SUB-DIRECTORY]FILE-NAME.EXT;234 and choke.

[stassats]

Well, the thing is, cl-fad is working without issues with [ in pathnames coming from list-directory. And nothing in cl-fad or SBCL has changed recently in that area to affect it. So you are either misinterpreting your findings or are not showing us your complete test cases.

[hanshuebner]

@stacksmith I'm personally not interested in making cl-fad support funny characters in file names, because it would be a never-ending effort and I don't have the need for it. This has nothing to do with correctness, but with motivation. It helps to understand the history of CL to understand why the pathname system has difficulties with file names that contain characters which are considered to be delimiters in other, maybe obsolete or ancient systems. Your remark regarding "cl-fad"'s "inability" to correctly parse a VMS file name is besides the point, because you're not running on VMS. If you were running cl-fad on a CL implementation on VMS and it would fail to support a native VMS path, you'd have a bug to report.

Stas seems to have a different take and motivation and have questions regarding what you reported as a bug, so I'm leaving it up to him to send any further responses.

[stacksmith]

stassats, thank you for your reply. My software needs to handle filenames I have no control over, and on further investigation it appears that cl-fad is not at fault. Paths with double-backslash-open-brace can be opened inside Lisp. However, they are not displayed correctly and cannot be passed as parameters to outside applications. I understand if you feel that it is not a problem of cl-fad.

Do you have any suggestions for a clean way of creating a correct visual representation of a path (allowing the user to spell it out and still find the file in the file manager, for instance) as well as a string representation that could be passed outside to the OS?

I'd hate to have to yank backslashes out of the pathstring for this one case - and who knows what other cases there are...

Thanks

Perhaps I am misunderstanding the mission statement of cl-fad: "It is intended to provide some
unification between current CL implementations on Windows, OS X, Linux, and Unix." My assumption was that the unification means the ability to deal with pathnames allowed by the host OS for applications such as scripting and file managers (which require dealing with native files)