Re: Handling files with problem characters in their names?

I have somewhat related issue that sbcl is not really helpful in cases where directory contains files with different encodings. When trying to do any file iteration in such dir, the operation will fail with decoding error and sbcl offer a retry or abort restart for the operation. It would be better to provide more helpful restarts such as continue restart to skip problematic files or use-value restart replacing error bytes in such files. I opened a bug with simple patch for it: https://bugs.launchpad.net/sbcl/+bug/2080732
 
Timo

On Fri, Dec 20, 2024, at 22:11, Richard M Kreuter via Sbcl-help wrote:
> What error do you get for the second example (the one with the Devangari
> characters)? This works for me on MacOS:
>
> * (setq *default-pathname-defaults* #P"/tmp/")
> #P"/tmp/"
> * (with-open-file (f "राम.txt" :direction :output :if-does-not-exist :create)
>     (write-line "foo" f))
> "foo"
> * (probe-file "राम.txt")
> #P"/private/tmp/राम.txt"
>
> Anyhow, there are three ways file naming can go haywire in most CLs:
>
> 1. conversion from an not-validly-encoded C string into a Lisp string
>    (on OSes where that's possible),
>
> 2. parsing a Lisp string into a pathname (which all the standard CL
>    functions are required to do implicitly),
>
> 3. unparsing a pathname into a filename (which happens implicitly in
>    OPEN and the like, but which you might need to do anyplace you're
>    using an FFI or communicating with another program).
>
> Your "file with [brackets].txt" is an example of the second. SBCL offers
> an extension to cope with the difference between Lisp syntax and native
> syntax: SB-EXT:PARSE-NATIVE-NAMESTRING.
>
> If you're listing files with CL:DIRECTORY, you'll get back something
> like #P"/path/to/file with \\[brackets].txt" for that file; and
> FILE-NAMESTRING will return "file with \\[brackets].txt" for it, so if
> you'd written that pathname somewhere using the Lisp printer, you'd have
> the escape character. Given that you have the string, 
> "file with [brackets].txt", I'd expect this string comes from another
> origin, e.g., a database lookup, an FFI call, a pipe or file from
> another program, etc. If that's the case, I'd suggest putting
> PARSE-NATIVE-NAMESTRING calls as close as possible to the origin,
> because the nature of the source more or less determines what syntax to
> use for parsing the string.
>
> Regards,
> Richard
>
> Jeff Cunningham <[email protected]> wrote:
>
>> What is the best way to handle files whose names contain characters
>> that break functions like FILE-LENGTH, NAMESTRING, and OPEN?
>> 
>> I keep running into this problem where I have large numbers of files
>> from external sources - I have no control over how they are named and
>> shouldn't change their names. Here's an example:
>> 
>> "file with [brackets].txt"
>> 
>> The pathname functions think it's a wildcard specification. I can
>> escape the left-bracket it to work with most of those, but that
>> doesn't work. Here's another example:
>> 
>> "राम.txt"
>> 
>> I keep coming up with adhoc solutions but I'm wondering how better
>> programmers handle this?
>> 
>> Thanks.
>> 
>> -- Jeff
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> Sbcl-help mailing list
>> [email protected]
>> https://lists.sourceforge.net/lists/listinfo/sbcl-help
>
>
> _______________________________________________
> Sbcl-help mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/sbcl-help


_______________________________________________
Sbcl-help mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/sbcl-help