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

Re: windows, shortcuts, and 'use lib'

Thread Previous | Thread Next
Edward Peschko
May 14, 2003 17:39
Re: windows, shortcuts, and 'use lib'
Message ID:
On Wed, May 14, 2003 at 12:35:44PM -0700, Jan Dubois wrote:
> On Wed, 14 May 2003 11:58:10 -0700, Edward Peschko
> <> wrote:
> [...]
> >Believe me, the first thing that I tried to do was use the 'link' interface in perl. You
> >say that it works, my windows XP and windows 2000 box says that it doesn't. Or it 'works'
> >in a weird, microsoftish way that only microsoft folks find in any way useful. Try:
> >
> >link('file','file2');
> >
> >where 'file' is 5000 bytes long. Edit 'file2' - add a byte. Do 'dir file*' and you will 
> >get
> >
> >05/14/2003   11:05             5000 file
> >05/14/2003   11:05             5001 file2
> It depends on how you "edit" the file.  If you delete and recreate it,
> then the link is obviously destroyed.  Note that you cannot rely on "dir"
> to display the correct information.  It sometimes takes NTFS a little
> while to update the directory entries of linked files.  Check the content
> of the files instead.

hmm. for me, the links are fragile. the pseudo-steps I did below

gvim <file>
... link file to file2 as you say
<edit file2 w/gvim, add stuff>

gvim <file> 

on my box (Windows XP/windows 2000) show that 'file2' is changed, wheras 'file' remains 
the same. Furthermore, I look at how much disk space is on my box after the edit, and 
the space goes down by the space in 'file2' after the edit.

Of course, it could be that gvim  is somehow unlinking the file, and then re-editing it...
that would be exceedingly dumb (especially for an editor) but possible.

> I disagree about the "fragile" part, except for the annoying delayed
> update of directory entries.  You are correct in that you cannot hardlink
> directories on NTFS.

linkd seems to do directory links, so I'd hope that perl would be able to do it. 
Although the links created do have the annoying side effect of 'you delete the 
hard link, the real directory goes too'.

> >	2) perl <shortcut> would follow the shortcut and run the file behind the shortcut.
> You can easily do this with a module that will modify @ARGV for you:
>   perl -MLinks shortcut.lnk
> and then put "-MLinks" into PERL5OPT.

But this is a good candidate for something that could be done *transparently*, IMO.. 
Out of this whole thread, the one consensus was shortcuts were application driven.. either
an application accepted them or not. I would say that 'perl <shortcut>'  is perl the 
*application* choosing to accept shortcuts, and do something useful where it didn't do
something useful before.

But then on the other hand, I'd say that perl's API accepting shortcuts automatically
is in spirit with the whole 'application driven' idea behind shortcuts, so I'm a bit 


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About