Re: [Sbcl-commits] master: pathnames: fix dot escaping with multiple preceding escapes
Richard M Kreuter via Sbcl-devel <[email protected]> Tue, 14 Apr 2026 10:41:27 -0400
| Newsgroups | gmane.lisp.steel-bank.devel |
|---|---|
| Message-ID | <[email protected]> |
Stas Boukarev <[email protected]> wrote: > I didn't change the dot escaping inside []. Ok, my mistake. > I wouldn't say that [a\\] is really an incompatible change, only if > somebody depends on a buggy implementation. > Comparing it to shell, > in bash, [ab\] doesn't work, (The difference of \\ might be confusing, > due to the lisp string escaping). I guess this is Hyrum's Law then, since I've found the correspondence usable & useful or years: $ touch a b \\ $ ls [a\\] \ a $ sbcl --noinform --quit --eval '(format t "~{~A~%~}" (directory "[a\\]"))' /private/tmp/z/\\ /private/tmp/z/a (To be fair, I guess a user has to know that POSIX shell only does filename expansion on unquoted pieces of text, and that a backslash needs to be escaped when it occurs unquoted.) So I think the question is why the left column would be a more preferable notation than the right? "x[\\]abc]" or "x[^]abc]" "x[]abc]" "x[\\.abc]" or "x[^.abc]" "x[.abc]" "x[\\\\abc]" (Unix) "x[\\abc]" "x[^^abc]" (Windows) "x[^abc]" As I see things, the right is always shorter, doesn't have to vary across Unix and Windows in the first 2 rows, and could be made to mean the same to SBCL as it does to some other programs. (It already did except in the second row.) What's the advantage to a longer, less portable-across-OSes, and SBCL-specific notation? Regards, Richard