Under SBCL, ACL and LW on MS Windows PROBE-FILE returns nil for
shortcuts. Isn't that wrong?
Under CLISP on Cugwin PROBE-FILE returns the full path of the file which
the shortcut is pointing to, so I was expecting that the other
implementations would do the same.
--
vedm
On Fri, 13 Oct 2006 14:11:32 -0400, vedm <··@ns.com> tried to confuse everyone
with this message:
>
>Under SBCL, ACL and LW on MS Windows PROBE-FILE returns nil for
>shortcuts. Isn't that wrong?
>
>Under CLISP on Cugwin PROBE-FILE returns the full path of the file which
>the shortcut is pointing to, so I was expecting that the other
>implementations would do the same.
>
Really? That would make it possible to use ASDF on Windows as it was intended,
by creating shortcuts to .asd files in ASDF:*central-registry*. Somebody should
research that.
--
|Don't believe this - you're not worthless ,gr---------.ru
|It's us against millions and we can't take them all... | ue il |
|But we can take them on! | @ma |
| (A Wilhelm Scream - The Rip) |______________|
Timofei Shatrov wrote:
> On Fri, 13 Oct 2006 14:11:32 -0400, vedm <··@ns.com> tried to confuse
> everyone with this message:
>
>>
>>Under SBCL, ACL and LW on MS Windows PROBE-FILE returns nil for
>>shortcuts. Isn't that wrong?
>>
>>Under CLISP on Cugwin PROBE-FILE returns the full path of the file
>>which the shortcut is pointing to, so I was expecting that the other
>>implementations would do the same.
>>
>
> Really? That would make it possible to use ASDF on Windows as it was
> intended, by creating shortcuts to .asd files in
> ASDF:*central-registry*. Somebody should research that.
>
N.B. I might be out of date, I haven't had the misfortune to use
windows in quite a while now:
Windows shortcut .lnk files are more closely analogous to
KDE/GNOME .desktop files than symlinks, they're files interpreted (or
not) by a shell rather than interpreted by the VFS.
Cygiwn, however, uses special augmented shortcut .lnk files to represent
emulated unix symlinks that you create from within cygwin. - I imagine
clisp is likely just using that support, and "alien to cygwin" (i.e.
native windows) unaugmented .lnk files created outside cygwin wouldn't
work or wouldn't work as well.
The "native windows" lisps that aren't sitting on top of a unix
emulation layer that treats certain .lnk files specially (i.e. cygwin)
have no particular reason to support identical interpretation of them,
in fact it might complicate windows-native programming if they did
(since the main use for .lnk shortcuts in windows land is indeed for
the functionality .desktop files are for on KDE/GNOME - icons on the
desktop and in menus, and application programmers probably _don't_ want
them treated like symlinks. Symlinks do actually have a more direct
VFS-level analogue in Windows NT land, but IIRC (and I probably don't!)
they are limited to pointing to directories for some reason)
On Fri, 13 Oct 2006 22:18:15 +0100, David Golden <············@oceanfree.net> wrote:
>
> Timofei Shatrov wrote:
>
> > On Fri, 13 Oct 2006 14:11:32 -0400, vedm <··@ns.com> tried to confuse
> > everyone with this message:
> >
> >>
> >>Under SBCL, ACL and LW on MS Windows PROBE-FILE returns nil for
> >>shortcuts. Isn't that wrong?
Responding to the OP: it's certainly inconsistent. But hey, this
is Common Lisp, where the spec leaves lots of room for interpretation :-)
> >>Under CLISP on Cugwin PROBE-FILE returns the full path of the file
> >>which the shortcut is pointing to, so I was expecting that the other
> >>implementations would do the same.
> >
> > Really? That would make it possible to use ASDF on Windows as it was
> > intended, by creating shortcuts to .asd files in
> > ASDF:*central-registry*. Somebody should research that.
> >
>
> N.B. I might be out of date, I haven't had the misfortune to use
> windows in quite a while now:
>
> Windows shortcut .lnk files are more closely analogous to
> KDE/GNOME .desktop files than symlinks, they're files interpreted (or
> not) by a shell rather than interpreted by the VFS.
Yep. The baseline API consists of the IShellLink and IPersistFile
COM interfaces. I have no idea whether it's practical (or robust)
to try to process the .lnk files directly rather than go through
the COM interfaces, so let's assume COM for the sake of this discussion,
because at least that way is documented and supported. Then the issue
becomes writing COM client code, the difficulty of which depends on
how well a CL implementation integrates with C (and note that stdcall
support is a requirement).
> Cygiwn, however, uses special augmented shortcut .lnk files to represent
> emulated unix symlinks that you create from within cygwin. - I imagine
> clisp is likely just using that support, and "alien to cygwin" (i.e.
> native windows) unaugmented .lnk files created outside cygwin wouldn't
> work or wouldn't work as well.
CLISP has code (in w32shell.c) that uses IShellLink and IPersistFile to
deal with .lnk files, but I haven't stepped through with a debugger to
verify that that code is actually executed. At the very least, other
implementors can get an idea (if not actual code) from CLISP.
> The "native windows" lisps that aren't sitting on top of a unix
> emulation layer that treats certain .lnk files specially (i.e. cygwin)
> have no particular reason to support identical interpretation of them,
> in fact it might complicate windows-native programming if they did
> (since the main use for .lnk shortcuts in windows land is indeed for
> the functionality .desktop files are for on KDE/GNOME - icons on the
> desktop and in menus, and application programmers probably _don't_ want
> them treated like symlinks.
I mostly agree, although I'm not sure to what degree programmers
feel that way. The OP apparently falls into the other camp.
> Symlinks do actually have a more direct VFS-level analogue in
> Windows NT land, but IIRC (and I probably don't!) they are limited
> to pointing to directories for some reason)
Prior to Vista, NTFS supported hard links to files via CreateHardLink, or
you could set up a file-based reparse point. CreateHardLink is not supported
for directories. Directories are linked via reparse points (also known as
junctions), and my understanding is that you can't make a relative link as
is possible in Unix.
Vista apparently has some enhancements in this area that I haven't read
much about.
--
Jack Unrue