Steel Bank Common Lisp

"Tobias C. Rittweiler" <tcr@...> writes:

> Hi,
> 
> (open "/tmp/foo*.lisp") where the file `foo*.lisp' does in fact exist in
> /tmp/ signals an error about "bad place for a wild pathname."
> 
> Next to knowing nothing about CL's pathname machinery, is this behaviour
> sensible? If yes, what can I do about it?

It's at least justifiable. The alternative would be for (directory
"/tmp/foo*.lisp") to not do what people expect. You can write
"/tmp/foo\\*.lisp" instead, or have a look at sb-ext:parse-native-namestring.

-- 
Juho Snellman

Juho Snellman <jsnell@...> writes:

> "Tobias C. Rittweiler" <tcr@...> writes:
>
> > Hi,
> > 
> > (open "/tmp/foo*.lisp") where the file `foo*.lisp' does in fact exist in
> > /tmp/ signals an error about "bad place for a wild pathname."
> > 
> > Next to knowing nothing about CL's pathname machinery, is this behaviour
> > sensible? If yes, what can I do about it?
>
> It's at least justifiable. The alternative would be for (directory
> "/tmp/foo*.lisp") to not do what people expect. You can write
> "/tmp/foo\\*.lisp" instead, or have a look at sb-ext:parse-native-namestring.

Thanks for the prompt answer. I encountered this error by trying to C-c
C-k a file named `let*.lisp'. 

Is calling SB-EXT:PARSE-NATIVE-NAMESTRING without any further arguments
sensible in the relevant bits of SBCL's SWANK backend? (It seems to DTRT
for the example under discussion, but I'd like to double-check because I
can't say that I comphrehend what its docstring wants to tell me.)

  -T.

"Tobias C. Rittweiler" <tcr@...> writes:
> Juho Snellman <jsnell@...> writes:
> Thanks for the prompt answer. I encountered this error by trying to C-c
> C-k a file named `let*.lisp'. 
> 
> Is calling SB-EXT:PARSE-NATIVE-NAMESTRING without any further arguments
> sensible in the relevant bits of SBCL's SWANK backend?

Yes.

> (It seems to DTRT
> for the example under discussion, but I'd like to double-check because I
> can't say that I comphrehend what its docstring wants to tell me.)

It's saying that the namestring will be parsed according to the
conventions of the platform, not the conventions of the Lisp
system. So e.g. we don't do wildcard expansion, since on Unix normal
programs don't do it either.

-- 
Juho Snellman

Juho Snellman writes:
> "Tobias C. Rittweiler" <tcr@...> writes:
> > Juho Snellman <jsnell@...> writes:
> > Thanks for the prompt answer. I encountered this error by trying to C-c
> > C-k a file named `let*.lisp'. 
> > 
> > Is calling SB-EXT:PARSE-NATIVE-NAMESTRING without any further
> > arguments sensible in the relevant bits of SBCL's SWANK backend?
> 
> Yes.

I disagree.  If the user has set *DEFAULT-PATHNAME-DEFAULTS* to a
logical pathname and SWANK doesn't rebind *D-P-D* to a physical
pathname, P-N-N will error.  (Right now the error we signal is a bug
(I'm about to commit the fix), but P-N-N is meant not to work for LPNs.)
AFAIK, the only exported, *D-P-D*-insensitive interface in SBCL for
getting at the physical pathname host is to call USER-HOMEDIR-PATHNAME
with no arguments.  So SWANK could do this:

(defvar *physical-pathname-host* (pathname-host (user-homedir-pathname)))

and then call PARSE-NATIVE-NAMESTRING with *PHYSICAL-PATHNAME-HOST* for
a host argument.

--
Richard

Richard M Kreuter <kreuter@...> writes:

> Juho Snellman writes:
> > "Tobias C. Rittweiler" <tcr@...> writes:
> >
> > > Is calling SB-EXT:PARSE-NATIVE-NAMESTRING without any further
> > > arguments sensible in the relevant bits of SBCL's SWANK backend?
> > 
> > Yes.
>
> [...] So SWANK could do this:
>
> (defvar *physical-pathname-host* (pathname-host (user-homedir-pathname)))
>
> and then call PARSE-NATIVE-NAMESTRING with *PHYSICAL-PATHNAME-HOST* for
> a host argument.

I committed this. Thanks folks!

  -T.