Front page | perl.perl5.porters |
Postings from May 2003
Re: windows, shortcuts, and 'use lib'
Thread Previous
|
Thread Next
From:
Edward Peschko
Date:
May 14, 2003 17:39
Subject:
Re: windows, shortcuts, and 'use lib'
Message ID:
20030514142746.A1150@mdssirds.comp.pge.com
On Wed, May 14, 2003 at 12:35:44PM -0700, Jan Dubois wrote:
> On Wed, 14 May 2003 11:58:10 -0700, Edward Peschko
> <esp5@mdssirds.comp.pge.com> 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
biased.
Ed
Thread Previous
|
Thread Next