Windows and tilda expansion in directories

Bug #922117 reported by Fabrice Popineau on 2012-01-26
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Nikodemus Siivola

Bug Description


I'm using 1.055.1 64bits under windows.
I have the HOME environment variable set to "c:/Home".

CL-USER> (ensure-directories-exist "c:/home/")

However :
CL-USER> (ensure-directories-exist "~/")
can't create directory c:c:/Home\
   [Condition of type SB-INT:SIMPLE-FILE-ERROR]

I have to set HOME to "/Home" for making this work.
It should be relatively easy to check for the drive part ?
(However I am not familiar with the sources, so I have (yet) no clue
where to look for offering patch.)

Best regards and thanks for the work on SBCL.

Nikodemus Siivola (nikodemus) wrote :

What does

  (pathname-device "~/")

return for you?

> What does
>  (pathname-device "~/")
> return for you?

Hmmm ... actually, I'm using the non-official 64bits windows port by
Anton Kovalenko.
I wonder if that can make any difference ?

CL-USER(1): (pathname-device "~/")

CL-USER(2): (pathname-device "c:/home")



Jan Moringen (scymtym) wrote :

This may be related:

When the HOME environment variable is not set, (sb-impl::user-homedir-namestring) returns NIL.

This case is not handled properly in line 257 of UNPARSE-NATIVE-WIN32-NAMESTRING in win32-pathname.lisp (this is for SBCL 1.0.55).

The result is as follows:
* (probe-file "~/")

debugger invoked on a TYPE-ERROR in thread
#<THREAD "initial thread" RUNNING <23D68E51>>:
  The value NIL is not of type STRING.

Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL.

restarts (invokable by number of by possibly-abbreviated name):
  0: [ABORT] Exit debugger, returning to top level.

(WRITE-STRING NIL #<invalid object #x22F661>>[:EXTERNAL]

Changed in sbcl:
assignee: nobody → Nikodemus Siivola (nikodemus)
importance: Undecided → Medium
status: New → Triaged
Stas Boukarev (stassats) on 2012-12-18
tags: added: os-windows
Stas Boukarev (stassats) wrote :

In 772e2f4f22a7034fc6f9101d9f088163a0d32e77 and 1975bd0492ed33de669f92d8c03d75bca19ed011.

Changed in sbcl:
status: Triaged → Fix Committed
Changed in sbcl:
status: Fix Committed → Fix Released

I noticed that doing

(pathname-device "~")

still returns NIL

Is this expected with a HOME variable set to "C:/home/" ?

or would we expect "C" ?

I would say the latter, personally..

Stas Boukarev (stassats) wrote :

~ is not expanded to HOME, ~/ is.

Stas Boukarev (stassats) wrote :

And the location of HOME can change at any time, it is resolved at the last time, if you want to get the device, run it through probe-file.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers