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

Re: windows, shortcuts and 'use lib'

Thread Previous
Edward Peschko
May 1, 2003 08:04
Re: windows, shortcuts and 'use lib'
Message ID:

On Wed, Apr 30, 2003 at 11:12:02AM -0700, Robert Spier wrote:
> > The point is that windows doesn't have symlinks - apparently without
> > the resource kit, and even then, only directory hard links. For
> > purposes of portablity across platforms it *should* have symlinks.
> > And hence, I think perl should emulate them as it does fork().
> Perl is not about making all operating systems alike.  Every operating
> system that perl runs on has different limitations.  

and that is called a 'straw man argument'. I never said I wanted to make windows and 
unix alike. I want it to be easier to develop cross platform programs, between unix and 

> > 
> > 	a) opening up word, hitting the 'open menu'
> > 	b) clicking on the icons following file.doc down to its source.
> > 	c) clicking on the file.doc menu.
> > 
> > How is this any different from accessing it via 'C:\some.lnk\file.doc' (except by making 
> > it a bigger pain for the user)?
> Well, first of all, the code inside MS Word never sees the link.
> That's all handled by the "library" (generic term) that implements the
> Explorer type interface.  By the time the source code inside MS Word
> sees it, it's C:\Blah\Blah\Blah\Blah\file.doc

But, like dos, perl has no GUI front-end. Its 'front end' is through
the calls 'use lib', system(), open(), etc.

> At no point _ever_ is C:\some.lnk\file.doc ever directly translated to
> C:\Blah\Blah\Blah\Blah\file.doc.
> Implementing fork()-like semantics is very different than creating
> something that doesn't currently exist anywhere.

Microsoft uses shortcuts as symlinks. That's why they don't put real symlinks in, and 
don't make dos support them - they want users to stick with, and be dependent on, 
their GUI.

> If you expect C:\some.lnk\file.doc to work, you should talk to
> Microsoft, maybe they'll put it in Windows 2005.

yeah right. when pigs fly.

> If you want to write an add-on module that does this expensive and
> error-prone operation, go ahead.  Or convince ActiveState that they
> need it.  But it doesn't make any sense (IMHO) for this overspecialized
> feature to be part of the core.

If its error prone for perl, its error prone for windows since they are using shortcuts
as symlinks all the time.  

As for expensive, I don't see it being too bad. For the regular case, it's not even an 
extra stat call:

if (CORE::open(FH, "/real/path/without/sublink"))
	return(1); # we're done
	# do symlink magic to get FH

	if (symlink_magic_fails())
		return(1);  # we've got a FH.

And finally, I think I can make it intuitive and backwards compatible. If you want to 
access a symlink *itself* (ie: not use the above magic) simply add the '.lnk' onto 
the end, ie:

open(FD, "/path/to/symlink.lnk");

would open the actual file, not traverse it as a symlink. If you want to view the 
symlink as the file that it points to, use:

open(FD, "/path/to/symlink");

If you have two files - symlink and symlink.lnk - tough. it will open up <symlink> as a 
regular file for backwards compatibility, Caveat emptor.

As far as I see, this makes the proposed syntax backwards compatible, usable, and 
computationally cheap. You're welcome to debate this... ;-)

But I do think you're argument that it makes sense as a module first holds water... I'd
be willing to write it and stress-test it, and make it intuitive (since that's what I'm 
going to need to do anyways). However, I had a couple of questions:

	1) how do you override 'open' in the core, so that CORE::GLOBAL::open returns a real
	   filehandle? For some reason:

			BEGIN { *CORE::GLOBAL::open = sub { CORE::open(@_); }; }

	   never opens up a filehandle..

	2) if I overload open, does this translate to operations with FileHandle (ie: is
	   filehandle built in terms of open, close, etc.
	3) how do you override `<command>` (backticks)? I didn't see anything about how to 
	   do that inside of CORE::global();

    4) Is there a central point at which all 'path munging' stuff occurs (like / to \ on 
	   win32 systems)? If so it makes the most sense to change it there, since then 
	   everything (from internal functions to ``) would automatically do the right thing.
	   Although it would impose the overhead of an extra stat call...


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