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

Re: windows, shortcuts and 'use lib'

Thread Previous | Thread Next
From:
Edward Peschko
Date:
April 29, 2003 00:31
Subject:
Re: windows, shortcuts and 'use lib'
Message ID:
20030428190649.B26725@mdssirds.comp.pge.com
On Sun, Apr 27, 2003 at 07:57:28PM +0100, Nicholas Clark wrote:
> On Sat, Apr 26, 2003 at 10:02:33PM -0400, Benjamin Goldberg wrote:
> > Edward Peschko wrote:
> > > 
> > > hey,
> > > 
> > > I just noticed that on Windows - at least in the activestate build -
> > > perl doesn't handle
> > > 
> > > use lib 'shortcut.lnk';
> > > 
> > > This is very unfortunate for us who want to take our unix environments
> > > and make them work seamlessly on NT (and need the capability of
> > > symbolic links and are willing to fake them via shortcuts).
> > > 
> > > Anyways, would people be interested in a patch to 'use lib'? I'd rather
> > > not write another directive, because of the ubiquitousness of 'use lib'
> > > and the fact that other modules out of my control use it extensively...
> > 
> > A better patch (imho) would be to make the "-l" operator return true for
> > filenames which end in ".lnk", and hack "readlink" on windows to grock
> > the format of shortcut files.  Then, one could write:
> > 
> >    use lib readlink('shortcut.lnk');
> > 
> > Which would thus require no alteration of lib.pm.
> > 
> > Or at least it would make the patch to lib.pm much smaller.
> >
> > Of course, if such hackery were added, users might become tempted to use
> > shortcuts as if they really *were* full fledged symbolic links, and try
> > and open paths like "C:/path/foo.lnk/bar" ... which wouldn't be work,
> > unless we did lots more hackery... thus, this might not be a good idea.
> 
> Are there enough hooks in the core routines yet to make it possible to write
> a module that tweaks all file operations to work with/round shortcuts?
> 
> If not, putting in enough hooks to make that work would seem a better still
> patch. Alternative a patch to lib.pm that allows modules to hook into to it
> to extend its capabilities would seem more general purpose - that way your
> script could load one module at the start to allow use lib in all third party
> modules to work seamlessly. Others might have other requirements.
> (As usual, the only one I can think of is loading zip files, but it strikes
> me that such a hook would be very useful to ex::lib::zip)
> 
> I would consider a patch that alters only -l much less clean than a patch that
> specifically and clearly makes lib.pm grok windows links.

How about this:

a) Right now, 5.8.0 has the following \@INC (here on sun4-solaris):

	/export/home/esp5/install/lib/perl5/5.8.0/sun4-solaris
	/export/home/esp5/install/lib/perl5/5.8.0',
	'/export/home/esp5/install/lib/perl5/site_perl/5.8.0/sun4-solaris',
	'/export/home/esp5/install/lib/perl5/site_perl/5.8.0',
	'/export/home/esp5/install/lib/perl5/site_perl',
	'.'

	lib.pm resides in 5.8.0/sun4-solaris, so and is generated via lib_pm.PL - it could be 
	changed to support reading links.

b)  the commands 'CORE::system', 'CORE::open', ...? could either be overloaded in 
    'Win32::Link' or, better yet, overloaded in a module that gets loaded into perl 
	automatically after 'perl' is typed. After a certain comfort level is reached, they
	get integrated into the core. I'm pretty sure people may disagree with the 
    'better yet' part..

c) open(FD, "/my_path/<possible_link>/file") could DWIM by:

	automatically assuming its a link if <possible_link> =~ m"\.lnk$";
	automatically assuming it means <possible_link>.lnk (and treating it as a link) if 

		1) <possible_link> !~ m"\.lnk$" 
		2) <possible_link> doesn't exist, or does exist and is a file 
		3) <possible_link>.lnk does exist.

    automatically assuming that it means an actual directory if <possible_link> exists
	and is a directory

d) open(FD, "(>*) /mypath/<possible_file_link>") could DWIM by:

	automatically assuming its a link if <possible_file_link> =~ m"\.lnk" 
	automatically assuming its a link if <possible_file_link> !~ m"\.lnk" and 

	    1) <possible_file_link> does not exist
		2) <possible_file_link>.lnk does exist
		3) the 'open' has a read component to it

	automatically assuming its a file if <possible_file_link> !~ m"\.lnk" and the 
	filehandle has a write component to it.
   
e) in the case that a user wants to force <possible_link> to be a symlink, readlink could
   be used:

	open(FD, "> " . readlink(/mypath/<possible_file_link>));



system, chdir, etc could all work the same way... (except they don't have to worry about 
the 'writable' case. 'symlink' could DWIM by creating a default symlink using the Win32::
API. 

hm, looking at the extensiveness of the change, maybe Win32::Link would be a better place
to put the changes at first - and then maybe moved into the core after some usage. 
And I hope that FileHandle, etc. are all implemented in terms of CORE:: functions, or 
this will be a lot more messy.

Ed

(
ps - where are the Win32:: functions? I'm looking at the perl distribution, and I don't
see them.. It'd be nice to have these part of the core if you were on windows. But given
that they aren't there, where would I submit patches for the above? 
)

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