From: Mark T. <ms...@di...> - 2003-04-07 09:25:38
|
Hi everyone, I've hit a bit of a stumbling block with some code I'm working on. I have a file called "hello?.txt" (unix filesystem) that I'm trying to open using (with-open-file ..), but I'm getting the following: [1]> (with-open-file (test "hello?" :direction :input)) *** - wildcards are not allowed here: #P"hello?" Is there some way to escape the '?' character that I'm missing? I've been through the impnotes, and mined the archives of this list and c.l.l but haven't had much luck turning up answers. Relevant details: GNU CLISP 2.30 (released 2002-09-15) (built 3248584626) (memory 3258512962) running Debian unstable. Features: (ASDF MK-DEFSYSTEM COMMON-LISP-CONTROLLER CLX-ANSI-COMMON-LISP CLX CLOS LOOP COMPILER CLISP ANSI-CL COMMON-LISP LISP=CL INTERPRETER SOCKETS GENERIC-STREAMS LOGICAL-PATHNAMES SCREEN FFI UNICODE BASE-CHAR=CHARACTER SYSCALLS PC386 UNIX) Thanks for reading, any help is greatly appreciated. Mark -- Mark Triggs <ms...@di...> |
From: Hoehle, Joerg-C. <Joe...@t-...> - 2003-04-24 09:33:32
|
Marco Antoniotti wrote: >According to the CLHS (not directly), an implementation should provide >an implementation dependent way of quoting the implementation dependent >wild characters in the pathname component and/or namestring. Here is >the relevant bit. > 19.2.2.1.1 Special Characters in Pathname Components >Strings in pathname component values never contain special characters >that represent separation between pathname fields, such as slash in >Unix filenames. I do not think that this passage is relevant. It's about file system special characters, while the matter at hand is about a CLISP-specific and internal extension about "*" and "?", but acknowledged in CLHS as "implementation dependent special wildcard characters" (cf. ?19.2.2.3) What I believe is as follows: This topic (annoying behaviour of CLISP) is bound to disappear. It's an ancient CLISP bastion which is going to fall the more users complain about it, like two others did fall in the past, due to user complaints: - ".emacs" to be parsed as either :name ".emacs" or :name nil/"" :type "emacs" cf. custom:*parse-namestring-dot-file* - merge-pathname (:relative "foo") (:relative "bar") either fill :directory or append cf. custom:*merge-pathnames-ansi* I believe some people do use CLISP for scripting. I'm quite surprised that they haven't complained yet (often enough) about CLISP's inability to access any regular file that may be found in a file system. BTW, CLISP's impnotes still mentions the old ".dot-file" behaviour in various parts of section "Pathname components", and *parse-namestring-dot-file* doesn't seem mentioned. So maybe OPEN, TRUENAME etc. should just check against presence of :wild or :wild-inferiors, not against #\* or #\?, while DIR and DIRECTORY could maintain their portable-across-clisp pattern matching behaviour. But then, you must also suggest conforming behaviour for wild-pathname-p and ?19.2.2.3 http://www.lisp.org/HyperSpec/Body/sec_19-2-2-3.html Please suggest a custom:*nice-name* and convince Sam :-) BTW, why doesn't this work: [75]> (make-pathname :directory '(:absolute :wild) :name "foo") *** - MAKE-PATHNAME: illegal :DIRECTORY argument (:ABSOLUTE :WILD) -- I'd expect #p"*/foo" while this is accepted (which I consider equivalent): (make-pathname :directory '(:absolute "*") :name "foo") as well as(!): (make-pathname :directory '(:absolute :wild-inferiors) :name "foo") -> #p"**/foo" Regards, Jorg Hohle. |
From: Sam S. <sd...@gn...> - 2003-04-19 14:13:46
|
> * In message <878...@di...> > * On the subject of "[clisp-list] Using filenames which contain wildcard characters" > * Sent on Mon, 07 Apr 2003 19:25:29 +1000 > * Honorable Mark Triggs <ms...@di...> writes: > > I've hit a bit of a stumbling block with some code I'm working on. I > have a file called "hello?.txt" (unix filesystem) that I'm trying to > open using (with-open-file ..), but I'm getting the following: > > [1]> (with-open-file (test "hello?" :direction :input)) > *** - wildcards are not allowed here: #P"hello?" CLHS is quite explicit on OPEN: An error of type file-error is signaled if (wild-pathname-p filespec) returns true. It is possible to add an keyword option to OPEN to circumvent it, but it will not be portable. Maybe it would be better to avoid such pathnames? -- Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux <http://www.camera.org> <http://www.iris.org.il> <http://www.memri.org/> <http://www.mideasttruth.com/> <http://www.palestine-central.com/links.html> Bus error -- driver executed. |
From: Mark T. <ms...@di...> - 2003-04-20 09:36:08
|
Pascal Bourguignon <pj...@in...> writes: > Sam Steingold writes: [...] >> CLHS is quite explicit on OPEN: >> >> An error of type file-error is signaled if (wild-pathname-p filespec) >> returns true. >> >> It is possible to add an keyword option to OPEN to circumvent it, but >> it will not be portable. >> Maybe it would be better to avoid such pathnames? Absolutely, but unfortunately I'm at the mercy of whatever bogus names people have decided to give their files :o) > Or to use a unix API (linux package in clisp). See the current POSIX > thread on comp.lang.lisp... Thanks for the suggestions. Given that the hyperspec makes it clear that an error should be signalled (sorry to have missed that), the behaviour is understandable. The linux package should do the trick for my purposes anyway. Thanks again, Mark -- Mark Triggs <ms...@di...> |
From: Marco A. <ma...@cs...> - 2003-04-21 13:43:55
|
According to the CLHS (not directly), an implementation should provide an implementation dependent way of quoting the implementation dependent wild characters in the pathname component and/or namestring. Here is the relevant bit. ======================================================================== ========================================= 19.2.2.1.1 Special Characters in Pathname Components Strings in pathname component values never contain special characters that represent separation between pathname fields, such as slash in Unix filenames. Whether separator characters are permitted as part of a string in a pathname component is implementation-defined; however, if the implementation does permit it, it must arrange to properly ``quote'' the character for the file system when constructing a namestring. For example, ;; In a TOPS-20 implementation, which uses ^V to quote (NAMESTRING (MAKE-PATHNAME :HOST "OZ" :NAME "<TEST>")) => #P"OZ:PS:^V<TEST^V>" NOT=> #P"OZ:PS:<TEST>" ======================================================================== ========================================= It would look like that (by extension), you should be able to do something like (open "hello^V?" .....) However, this is going to be completely implementation dependent. As a personal preference, I wouldn't mix UNIX shell wildcards with CL pathname components. After all the C library does not care about '?' in file names. Cheers Marco On Friday, Apr 18, 2003, at 08:21 America/New_York, Sam Steingold wrote: >> * In message <878...@di...> >> * On the subject of "[clisp-list] Using filenames which contain >> wildcard characters" >> * Sent on Mon, 07 Apr 2003 19:25:29 +1000 >> * Honorable Mark Triggs <ms...@di...> writes: >> >> I've hit a bit of a stumbling block with some code I'm working on. I >> have a file called "hello?.txt" (unix filesystem) that I'm trying to >> open using (with-open-file ..), but I'm getting the following: >> >> [1]> (with-open-file (test "hello?" :direction :input)) >> *** - wildcards are not allowed here: #P"hello?" > > CLHS is quite explicit on OPEN: > > An error of type file-error is signaled if (wild-pathname-p filespec) > returns true. > > It is possible to add an keyword option to OPEN to circumvent it, but > it will not be portable. > Maybe it would be better to avoid such pathnames? > > -- > Sam Steingold (http://www.podval.org/~sds) running RedHat8 GNU/Linux > <http://www.camera.org> <http://www.iris.org.il> > <http://www.memri.org/> > <http://www.mideasttruth.com/> > <http://www.palestine-central.com/links.html> > Bus error -- driver executed. > > > ------------------------------------------------------- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > _______________________________________________ > clisp-list mailing list > cli...@li... > https://lists.sourceforge.net/lists/listinfo/clisp-list > -- Marco Antoniotti NYU Courant Bioinformatics Group tel. +1 - 212 - 998 3488 715 Broadway 10th FL fax. +1 - 212 - 998 3484 New York, NY, 10003, U.S.A. |