Re: File Copying problem

It's probably your use of backslashes. You know, in interpolated strings (which is, all strings), you need to backwhack backwhacks. Like so:

    copy( "$original_site\\$_", "$second_site\\$_" )
         or die "Failed to copy $_: $!\n";
[download]

But perhaps you'd find it more convenient (not to mention more portable) to use forward slashes:

    copy( "$original_site/$_", "$second_site/$_" )
         or die "Failed to copy $_: $!\n";
[download]

Yes, this works even on Windows!

(Note, I improved the error message by including the name of the file for which copy failed.)

jdporter
The 6th Rule of Perl Club is -- There is no Rule #6.

Comment on Re: File Copying problem Select or Download Code

Replies are listed 'Best First'.
Re: Re: File Copying problem by halley (Prior) on May 13, 2003 at 23:45 UTC
Unless you are building up a string that must be sent to `system()` or `qx//` on Win32, please, please, please, just stick with forward slashes for directory structures. The only part of Win32 that does not treat backslashes and forward slashes identically is the command interpreter (COMMAND.COM or CMD.EXE). All the APIs handle forward slashes just fine, and it makes coding so much easier and portable. -- `[ e d @ h a l l e y . c c ]`	[reply] [d/l] [select]
Re^3: File Copying problem (meme patrol) by tye (Sage) on May 14, 2003 at 02:41 UTC
The only part of Win32 that does not treat backslashes and forward slashes identically is the command interpreter (COMMAND.COM or CMD.EXE). This type of assertion is rather common but it isn't quite accurate. I'll address several related assertions I've heard so some of my points don't apply directly to what halley said. Cmd.exe actually handles forward slashes for path separators rather well. It has a preference for backslashes but this is more subtle than some people seem to think. And there are several APIs that don't handle forward slashes at all. These include the registry and the common file dialogues (and some advanced APIs that you aren't likely to run into with Perl). And there is at least one file path construct that doesn't work with forward slashes (the \\?\ prefix only works with backslashes and only using wide characters, which means you have to use something like Win32API::File in order to use it). But, in practice, forward slashes work in file paths in Win32 Perl most of the time and the most common problem you'll run into if you use them is that many programs (most programs provided by Microsoft) won't interpret them correctly when passed to them on the command line. This isn't because the command shell doesn't like them. This is because each Win32 program is responsible for interpretting its own command line and most Microsoft programs only allow / to be used for command-line options not for file paths (and a minus sign preceeded by a space sometimes also works for command-line options). So the basic practical results are pretty much the same (which is probably why this meme survives well): You can almost always use / instead of \ for file paths in Win32 Perl. But if you use a file path in a command-line argument (such as with system or qx//), almost all programs will handle \ (some cygwin program don't handle \ quite as well as /) while many won't handle /. So if you don't know what program you are running, you should switch / to \ to be safe. - tye	[reply]
Re: Re^3: File Copying problem (meme patrol) by jdporter (Paladin) on May 14, 2003 at 12:24 UTC
...you should switch / to \ to be safe. Or, to be portable as well as safe, use File::Spec to construct all your path names. jdporter The 6th Rule of Perl Club is -- There is no Rule #6.	[reply]