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