From: Zach B. <xa...@xa...> - 2011-05-03 16:32:19
|
Sam Steingold <sd...@gn...> writes: > I think my solution is simpler, cleaner, and more ANSI-compliant. > Your solution adds an extra (non-standard, i.e., non-compliant!) quoting rule. The syntax of wildcards in namestrings is implementation-defined. > Consider this: > (let ((*accept-wild-pathname* t)) > (dolist (f (directory "foo*")) > (print f) > (with-open-file (s "foo*") (print (read-line s))))) > #P"/.../foo*" > "Tue May 3 11:21:32 EDT 2011" > > Your solution requires me to quote the return values from DIRECTORY so > that this would work: > (dolist (f (directory "foo*")) > (print f) > (with-open-file (s "foo*") (print (read-line s)))) Did the "me" in "requires me to quote" mean "me, the implementor of CLISP" or "me, a user of CLISP"? If the former, then yes, if CLISP were to use a backslash escape convention for special characters in namestrings, that DIRECTORY would return results consistent with that convention. That is what other implementations do. Also, did you mean (with-open-file (s f) ...)? If you did, then your code would already work fine in e.g. SBCL without modification. > It also requires a un-quote function in case I want to pass a pathname > from DIRECTORY to an outside program. In SBCL, the model works like this: When working with CL functions on pathnames returned from DIRECTORY, everything works without any extra effort. Passing pathnames to external processes (an extra-standard activity) requires an extra-standard mechanism to get a compatible namestring. That model has worked pretty well for me in practice. Zach |
From: Pascal J. B. <pj...@in...> - 2011-05-03 18:47:26
|
Sam Steingold <sd...@gn...> writes: >> * Zach Beane <knpu@knpu.pbz> [2011-05-03 10:41:59 -0400]: >> Sam Steingold <sd...@gn...> writes: >> >>> "foo*" is a valid (although uncommon) pathname on most modern OSes but >>> it cannot be handled by clisp easily. >>> proposal: user variable *accept-wild-pathname* which will treat wild >>> pathname as non-wild in OPEN, DELETE-FILE et al.: >> >> Some other CLs handle this by interpreting a precding #\\ as a desire to >> inhibit processing the following character as a wildcard. Deleting the >> file in your example would look like: (delete-file #p"foo\\*"). >> >> This has the effect that the namestring of the pathname does not map >> exactly to the underlying filename. SBCL provides a NATIVE-NAMESTRING >> function to get it instead. > > I think my solution is simpler, cleaner, and more ANSI-compliant. > Your solution adds an extra (non-standard, i.e., non-compliant!) quoting rule. Both solutions are non-standard, but both can be used to write a conforming program, since they're both conforming implementation dependant behaviors, as long as they're documented. Any string introduced by #P, that is not in the logical pathname syntax, is parsed in an implementation dependant way. There's no problem with an implementation that parses \\* to mean a literal #\* instead of a :wild card. This is my prefered solution, since clisp already parses #\~ in an implementation specific way in namestrings. > I think the simplicity wins. >From the point of view of the users (both programmers and end-users), #P"foo\\*" is simplier to use than binding special variables. Foremost, it can be used with libraries without ill side effects. > BTW, should the strict *ANSI* mode set this to NIL? > I think it should, so the name must end with -ANSI* > So, it should be *wild-pathnames-ansi*, right? Parsing non-logical pathnames is implementation dependent anyways. I'm not sure there's value in multiplying the options and alternatives. #P"dir\\**/foo\\\*" should let you open the file named "dir**/foo\\*". -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Sam S. <sd...@gn...> - 2011-05-03 19:12:39
|
the problem with the escaping solution is that it is not backward compatible. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://thereligionofpeace.com http://iris.org.il http://pmw.org.il http://www.PetitionOnline.com/tap12009/ http://jihadwatch.org There are 3 kinds of people: those who can count and those who cannot. |
From: Pascal J. B. <pj...@in...> - 2011-05-03 20:23:28
|
Sam Steingold <sd...@gn...> writes: > the problem with the escaping solution is that it is not backward compatible. Do you know a lot of files with backslashes in their names? I say it the escaping solution is backward compatible in practice, because nobody in his sane mind would name a file with a backslash in it, so there are no such files, therefore no need to keep the meaning of names containing backslashes. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Sam S. <sd...@gn...> - 2011-05-03 20:28:38
|
> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2011-05-03 22:22:25 +0200]: > > Sam Steingold <sd...@gn...> writes: > >> the problem with the escaping solution is that it is not backward compatible. > > Do you know a lot of files with backslashes in their names? nope, and I don't know any files with "?" and "*" in their names either. > I say it the escaping solution is backward compatible in practice, > because nobody in his sane mind would name a file with a backslash in > it, so there are no such files, therefore no need to keep the meaning > of names containing backslashes. therefore this whole issue is purely academic, right? -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://iris.org.il http://memri.org http://honestreporting.com http://ffii.org http://thereligionofpeace.com http://www.memritv.org http://pmw.org.il Your mouse has moved - WinNT has to be restarted for this to take effect. |
From: Bruno H. <br...@cl...> - 2011-05-03 22:23:43
|
Hi Sam, > "foo*" is a valid (although uncommon) pathname on most modern OSes but > it cannot be handled by clisp easily. > proposal: user variable *accept-wild-pathname* which will treat wild > pathname as non-wild in OPEN, DELETE-FILE et al.: Very nice! > [6]> (let ((*accept-wild-pathname* t)) (delete-file "foo*")) > #P"/home2/sds/src/clisp/current/build-g/foo*" Let's go even one step further: (let ((*accept-wild-pathname* t)) (wild-pathname-p (pathname "foo*"))) => NIL Should this variable influence the parsing of pathnames or their interpretations in functions such as OPEN, DELETE-FILE, etc.? It needs to influence both, because (pathname "foo*") => #S(PATHNAME :NAME "foo*") (pathname "foo.x*") => #S(PATHNAME :NAME "foo" :TYPE "x*") regardless whether *accept-wild-pathname* is true. > a better name for the variable? Maybe *interpret-wildcards*, with default value t? Bruno -- In memoriam Zbigniew Iwański <http://en.wikipedia.org/wiki/Henryk_Iwański> |
From: Sam S. <sd...@gn...> - 2011-05-03 22:42:46
|
Hi Bruno, > * Bruno Haible <oe...@py...t> [2011-05-04 00:23:32 +0200]: > >> "foo*" is a valid (although uncommon) pathname on most modern OSes but >> it cannot be handled by clisp easily. >> proposal: user variable *accept-wild-pathname* which will treat wild >> pathname as non-wild in OPEN, DELETE-FILE et al.: > > Very nice! thanks. what do you think about the alternative (and much more complex) proposal if allowing users to escape wildcards? >> [6]> (let ((*accept-wild-pathname* t)) (delete-file "foo*")) >> #P"/home2/sds/src/clisp/current/build-g/foo*" > > Let's go even one step further: > > (let ((*accept-wild-pathname* t)) (wild-pathname-p (pathname "foo*"))) => NIL Doesn't look right to me. > Should this variable influence the parsing of pathnames or their > interpretations in functions such as OPEN, DELETE-FILE, etc.? > It needs to influence both, because > (pathname "foo*") => #S(PATHNAME :NAME "foo*") > (pathname "foo.x*") => #S(PATHNAME :NAME "foo" :TYPE "x*") > regardless whether *accept-wild-pathname* is true. How should it influence parsing? Why? I think that if we want to touch parsing we might as well implement wildcard escaping... >> a better name for the variable? > Maybe *interpret-wildcards*, with default value t? Sounds good. -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://thereligionofpeace.com http://jihadwatch.org http://ffii.org http://honestreporting.com http://dhimmi.com http://camera.org There are two ways to write error-free programs; only the third one works. |
From: Aleksej S. <as...@in...> - 2011-05-04 07:06:08
|
Sam Steingold <sd...@gn...> writes: >> * Pascal J. Bourguignon <cwo@vasbezngvzntb.pbz> [2011-05-03 22:22:25 +0200]: >> >> Sam Steingold <sd...@gn...> writes: >> >>> the problem with the escaping solution is that it is not backward compatible. >> >> Do you know a lot of files with backslashes in their names? > > nope, and I don't know any files with "?" and "*" in their names either. I made many such files in my life. You just need to make a mistake and invoke "something > file*", e.g. run ":>/tmp/test*" in Almquist shell derivative (NetBSD and FreeBSD sh, called "ash" or "dash" in linux-based systems). Files with question mark in name are met more frequently than that, mostly because it is perfectly valid to use them in book titles. >> I say it the escaping solution is backward compatible in practice, >> because nobody in his sane mind would name a file with a backslash in >> it, so there are no such files, therefore no need to keep the meaning >> of names containing backslashes. > > therefore this whole issue is purely academic, right? Right, the whole issue is purely academic, file names should be no longer than six RADIX-50 symbols (with optional extension no longer than three symbols). -- HE CE3OH... |
From: Sam S. <sd...@gn...> - 2011-05-04 14:02:17
|
> * Sam Steingold <fq...@ta...t> [2011-05-03 10:33:54 -0400]: > > proposal: user variable *accept-wild-pathname* which will treat wild > pathname as non-wild in OPEN, DELETE-FILE et al. this is no good because the users might want to treat _some_ '*' as wild and others as non-wild. e.g., search for all files under foo with a star in their names: (directory "foo/**/*\\**") -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://www.memritv.org http://dhimmi.com http://ffii.org http://truepeace.org http://honestreporting.com http://iris.org.il http://pmw.org.il NY survival guide: when crossing a street, mind cars, not streetlights. |
From: Sam S. <sd...@gn...> - 2011-05-10 17:45:06
|
It looks like the way to go is to implement escaping. Incidentally, clisp pattern matching seems somewhat counter-intuitive (if not buggy), e.g.: (translate-pathname "fooabar" "foo?bar" "foo1bar") ==> ERROR instead of #P"foo1bar" Bruno, is this intentional? Also, I understand that implementing matching in C was the way to go in 1990, but should we not rely on fnmatch (maybe from gnulib) in 2011? Bruno? Also, I don't think a single function MATCH justifies whole FFI module with a package &c. I think both MATCH and WILDCARD-MATCHER should go to the POSIX module, and the wildcard module should be removed from the source distribution (and, probably, the source tree also); we will keep the package and symbols for backward compatibility for a year or two. NB: modules/wildcard takes 428k (200k - configure; 188k - gnulib code; 1.5k - wildcard.lisp). Bruno, WDYT? -- Sam Steingold (http://sds.podval.org/) on CentOS release 5.6 (Final) X 11.0.60900031 http://www.PetitionOnline.com/tap12009/ http://www.memritv.org http://honestreporting.com http://camera.org http://iris.org.il A slave dreams not of Freedom, but of owning his own slaves. |
From: Jonathan J. <fra...@gm...> - 2011-05-14 04:57:56
|
May I suggest you have a dynamic variable for the wildcard character? Then you just have to find a character that's free. Along the lines of: (let ((*pathname-wildcard-character* #\:)) (directory "foo/:*:*")) This way you can pick a character that isn't even valid on a particular file system, letting you be very sure that it'll work without unintentional matches. This seems to get around several of the issues found earlier... Regards, Jonathan Johansen |
From: Pascal J. B. <pj...@in...> - 2011-05-14 08:35:52
|
Jonathan Johansen <fra...@gm...> writes: > May I suggest you have a dynamic variable for the wildcard character? Then > you just have to find a character that's free. Along the lines of: > > (let ((*pathname-wildcard-character* #\:)) > (directory "foo/:*:*")) > > This way you can pick a character that isn't even valid on a particular file > system, letting you be very sure that it'll work without unintentional > matches. This seems to get around several of the issues found earlier... It seems to me that a dynamic variable for this use is no good. In the case of CL primitives, we could assume that the implementation takes care of everything, but when calling "library" functions, there may be other pathnames used inside, that are not under the direct control of the client, and potentially changing their meaning with such a special variable could be dangerous. Also, I'm worried about *default-pathname-defaults*, (but slightly less, since the client who binds *pathname-wildcard-character* could check that it's not in *default-pathname-defaults*). The problem being that some (most) pathname/file operators accept only non-wildcard pathnames, and using such a special variable would change them to wildcard pathnames. -- __Pascal Bourguignon__ http://www.informatimago.com/ A bad day in () is better than a good day in {}. |
From: Jonathan J. <fra...@gm...> - 2011-05-15 06:10:50
|
On Sat, May 14, 2011 at 6:32 PM, Pascal J. Bourguignon <pj...@in...> wrote: > > Jonathan Johansen <fra...@gm...> writes: > > > May I suggest you have a dynamic variable for the wildcard character? Then > > you just have to find a character that's free. Along the lines of: > > > > (let ((*pathname-wildcard-character* #\:)) > > (directory "foo/:*:*")) > > > > This way you can pick a character that isn't even valid on a particular file > > system, letting you be very sure that it'll work without unintentional > > matches. This seems to get around several of the issues found earlier... > > It seems to me that a dynamic variable for this use is no good. That may be the case. Sorry if I'm coming in a bit 'fresh', but I just read http://clhs.lisp.se/Body/19_bbc.htm which states that the wildcard character(s?) are implementation dependent for (general) pathnames, and http://clhs.lisp.se/Body/19_ca.htm which states specific requirements for logical pathnames. So even if a dynamic variable was defined and used, logical pathnames must use asterisks, so the original issue remains. > > In the case of CL primitives, we could assume that the implementation > takes care of everything, but when calling "library" functions, there > may be other pathnames used inside, that are not under the direct > control of the client, and potentially changing their meaning with such > a special variable could be dangerous. I agree - good point. If I really want it, I'll consider implementing my suggestion as a read macro for pathnames on top of the eventual outcome of this discussion. Perhaps #f<wildcard-character>"pathname-with-custom-wildcard-characters". > > Also, I'm worried about *default-pathname-defaults*, (but slightly less, > since the client who binds *pathname-wildcard-character* could check > that it's not in *default-pathname-defaults*). > > The problem being that some (most) pathname/file operators accept only > non-wildcard pathnames, and using such a special variable would change > them to wildcard pathnames. Again - good point. > > -- > __Pascal Bourguignon__ http://www.informatimago.com/ > A bad day in () is better than a good day in {}. |