Re: Handling files with problem characters in their names?

Confirmed the राम.txt works here too (mac, emacs, slime).

Wanted to echo Richard's point about converting to pathnames as early as 
possible: strings are rather ambiguous representations of pathnames in 
CL, as you're experiencing.

If you want a "Do-What-I-Mean" kind of function to convert strings to 
pathnames which is reasonably cross platform and cross lisp, have a look 
at uiop:ensure-pathname: 
https://asdf.common-lisp.dev/uiop.html#index-ensure_002dpathname



On 12/20/24 3:11 PM, 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