Re: Handling files with problem characters in their names?
Jeff Cunningham <[email protected]> Fri, 20 Dec 2024 21:56:41 -0500
| Newsgroups | gmane.lisp.steel-bank.general |
|---|---|
| Message-ID | <20241220215641.18a253cd@Isabelle> |
I will - that looks very useful. Thanks. On Fri, 20 Dec 2024 21:20:37 +0000 Hraban via Sbcl-help <[email protected]> wrote: > 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 _______________________________________________ Sbcl-help mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/sbcl-help