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
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
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
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
as reported in thread219-1140731.Alert - c is not a registered protocol
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