UNC path in single quotes, you run into a slight problem. The Perl interpreter reads the double backslash at the beginning of the UNC path as an escaped single backslash. The only workaround is to escape the first backslash in the pair with another backslash. Therefore, a UNC path in single quotes might look like
@Statistics = stat( '\\\server\temp\foo.pl' );
You handle double-quoted UNC paths similarly to single-quoted UNC paths. The only difference is that you need to escape every backslash:
@Statistics = stat( "\\\\server\\temp\\foo.pl" );
Although the Perl language lets you use Win32 or UNIX paths, many Perl extensions aren't as flexible, so using a path with forward slashes instead of backslashes would likely result in an error. Thus, when you write Perl code for Win32 OSs, a good rule of thumb is to follow Win32 conventions.
Character case. Unlike UNIX paths, Win32 paths are typically case insensitive. One exception might occur if you use an alternative (non-FAT16, non-FAT32, or non-NTFS) Installable File System (IFS) driver. You can develop an IFS driver that imposes case restrictions. For example, if your company has an NFS file-system driver, you might decide to impose case sensitivity. However, the default Win32 file systems (i.e., FAT16, FAT32, and NTFS) are case insensitive, so the code that Listing 1 shows is completely legal to use with those file systems.
In Listing 1, the first line lowercases the first parameter passed into the script, then assigns that parameter to the $Path variable. The call to the open() function works regardless of the case of the $Path variable's value.
DOS vs. Win32 Paths
In a legacy DOS platform, the file and directory names must be uppercase, exclude spaces, and follow the 8.3 format (i.e., the name can be up to eight characters long and the extension can be up to three characters long). In the Win32 platform, file and directory names can be mixed case, include spaces, and be much longer. Thus, a path such as C:\Program Files\My test file.txt is valid in Win32 but not DOS.
Sometimes, however, Win32 paths can create problems. For example, if you run an early Windows or DOS program, it won't understand a long pathname or one that contains spaces or mixed cases. Under these circumstances, the Win32 OS converts the path into a DOS-compatible version. When necessary, the Win32 OS
- shortens each component in the path (i.e., each directory name or filename) so that the component doesn't exceed the 8.3 format
- removes all spaces in the path
- uppercases all letters in the path
For example, a Win32 OS might convert C:\Program Files\My test file.txt to C:\PROGRA~1\MYTEST~1.TXT.
When the Win32 OS converts a filename or directory name, it renames the file or directory in relation to the files or directories that already exist. For example, suppose an application first creates the file C:\Program Files\My test file is cool.txt, then creates the file C:\Program Files\My test file is long.txt. When the Win32 OS converts the two filenames, it changes My test file is cool.txt to MYTEST~1.TXT and changes My test file is long.txt to MYTEST~2.TXT. If the application had created the files in reverse order, the Win32 OS would have changed My test file is long.txt to MYTEST~1.TXT and changed My test file is cool.txt to MYTEST~2.TXT. As this example shows, you can't determine a file's or directory's 8.3-compliant name (hereafter referred to as simply the short name) from its long name. Thus, you can run into problems if a backup program restores files in a different order than the original order of creation. In this situation, you shouldn't depend on the OS to determine the short names; rather, you should create 8.3-compliant filenames.
To determine the short name for a file or directory, you can use the Win32::GetShortPathName() function. This function returns the short pathname for a given long pathname. As Listing 2 shows, you simply pass in the long pathname as the function's sole parameter. Conversely, to obtain a long pathname, you can use the Win32::GetLongPathName() function. In this case, yo