develooper Front page | perl.perl5.porters | Postings from April 2003

Re: windows, shortcuts and 'use lib'

Thread Previous | Thread Next
From:
Benjamin Goldberg
Date:
April 28, 2003 08:16
Subject:
Re: windows, shortcuts and 'use lib'
Message ID:
3EAD498D.E3354FA9@earthlink.net


Horsley Tom wrote:
> 
> > Short point - symbolic links not working on NT is a major pain in the
> > #$#$#%.
> 
> True.
> 
> > Perl making them work (and work transparently) would be a big plus.
> 
> False. Windows doesn't have symlinks. If perl pretends windows has
> symlinks, it is lying to you.

Windows95 doesn't have fork.  If perl pretends to have fork, it is lying
to you.  Is that a bad thing?

> What the devil do you do if you *want* to open and read the .lnk file
> (which I have often done when I wanted to gather info about the
> shortcuts on my system)? The readlink interface is utterly inadequate
> to real all the different kinds of things that make up all the
> different kinds of .lnk files out there.

If the last component of a path is a shortcut, perl has two choices --
one is to open it and examine it's contents, and redirect you to the
actual file, OR, it can simply let you open the shortcut and read it's
contents yourself.

However, if a shortcut is a middle component of a path, perl's choices
are: 1/ barf, saying that it's an invalid path (which in a real sense,
is correct), or 2/ pretend that it's a symlink, by opening the shortcut
and reading out the path.

For a shortcut in the middle of a filepath, pretending it's a symlink,
and making things "work" is, IMHO, the right thing to do.

For the case of the shortcut as the last filepath component... well, I'm
not sure what's best.  AFAIK, actually inspecting the contents of
shortcut files isn't a frequently performed operation.  Thus, I would
suggest that under normal operation, perl open the shortcut, read it,
then open for you the file it's pointing at.  If you want to directly
inspect all the contents of a shortcut, perl could provide some other
subroutine to do that for you -- perhaps Win32::ReadShortcut, which
would return a hash representing an IShellLink object.

> > Anyone know why microsoft doesn't just bite the bullet and
> > put them in? Is it a limit in NTFS?
> 
> I have often heard the claim that NTFS can support them, but I've
> never seen anyone actually try to do it (and FAT and FAT32 definitely
> cannot support them, which is probably an argument for not supporting
> them in NTFS).

There are any number of things which are supported in some versions of
windows, but not in earlier versions of windows.  I don't see how the
fact that FAT/FAT32 can't support a feature could possibly be an
argument for not supplying it for NTFS.

-- 
$a=24;split//,240513;s/\B/ => /for@@=qw(ac ab bc ba cb ca
);{push(@b,$a),($a-=6)^=1 for 2..$a/6x--$|;print "$@[$a%6
]\n";((6<=($a-=6))?$a+=$_[$a%6]-$a%6:($a=pop @b))&&redo;}

Thread Previous | Thread Next


nntp.perl.org: Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at ask@perl.org | Group listing | About