Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

DOS/Win32 path problem?

Status
Not open for further replies.

fishiface

IS-IT--Management
Feb 24, 2003
687
GB
I and others have, for many years, argued that, when writing literal paths in perl, one should use forward-slashes as directory separaters whenever possible, including on the DOS and 'doze platforms.

DOS has always(?) allowed this (because of it's VMS roots?) and there are several benefits.

The backslash character sometimes functions as an escape and needs to be doubled up in interpolating quotes but not in other quoting styles. This means that you need to consider the semantics of your chosen quoting style every time you use a path. If, like me, you are sometimes a little uncertain, you might have to refer to the docs to check whether, say, backticks or s/// LHSs interpolate. If you use forward-slashes, you can do so consistantly and eliminate a possible (probable, for me) source of errors.

Secondly, and possibly applying to fewer situations, it means that it is easier to port your code from, say, 'doze to *ix;

There now seems to be a problem with this approach. Because perl's [tt]open()[/tt] uses the underlying operating system's [tt]open()[/tt], it can now open URIs on a win32 platform.

This can cause the most bizarre errors. Consider
Code:
open( FH2, "[URL unfurl="true"]http://myhost.com/antelopes.jpg"[/URL] );
open( FH1, "c:/Program Files/Satan/enemies.txt" );

The semantics are sufficiently similar for second call to look up 'c' in it's table of registered URI protocols. It will almost certainly fail, giving the strange error
Alert - c is not a registered protocol
as reported in thread219-1140731.


The strange thing is that, although I'm happy with my analysis above, I can't reproduce it on a well-patched XP box. Could someone give it a go for me and see if this is a common bug or something peculiar to the particular situation reported?

Thanks in advance.

Yours,

fish

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur
 
On an XP SP1 (perl 5.8.3), not auto updated works fine
On an XP SP2 (perl 5.8.2),auto updated works fine, not that common ...

Thanks fo rthat reminds me to update Perl on SP2 box ;-)

HTH
--Paul

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)
 
On second thoughts, this would be more relvant to the version of perl, no?

Spend an hour a week on CPAN, helps cure all known programming ailments ;-)
 
I don't think so. Does it not just pass the filename as a string to the underlying [tt]open[/tt] from the platform's c io library?

Yours,

f

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur
 
My understanding *was* that it's Perl which understands and copes with the \ vs / issues.

But if that used to be the case it's not the whole story now. If you type c:/perl/bin/perl.exe in the Run dialogue box it works fine. If you type c:/perl/bin/perl.exe then that works as well.

:-( Mike is confused.

Mike

I am not inscrutable. :)

Want great answers to your Tek-Tips questions? Have a look at faq219-2884

 
I can't reproduce that errror on any windows box, regardless of OS version or the perl version.
 
I've done a bit of googling and it seems that the DOS kernel has suppored slashing either way for as long as it has supported directories.

I've re-read thread219-1140731 and, while the open() is happening in a script on a webserver (I think it might be IIS but I don't know), the error is appearing on the browser's machine and is, furthermore, browser dependent.

I just don't know what to make of this.

At least if we see the error again, we'll know where to look.

Yours,

fish

["]As soon as we started programming, we found to our surprise that it wasn't as easy to get programs right as we had thought. Debugging had to be discovered. I can remember the exact instant when I realized that a large part of my life from then on was going to be spent in finding mistakes in my own programs.["]
--Maur
 
as far as I know, it won't use "c" as a protocol due to the fact that it is not followed by two forward slashes (as in "http://"), it is only followed by one slash ("C:/"). I think this SHOULD stop it trying to use "c" as a protocol...
In DOS (or cmd) prefixing a file name with a backslash (like \autoexec.bat) would refer to "[currently active drive]:\autoexec.bat" so if we use the forward slash method then we can refer to the route of the drive that is currently active with this: "/autoexec.bat" thus increasing the portability to *nix.
er... someone correct me if I'm wrong on this though... :p
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top