To open DBM files, use the dbmopen function. It accepts three arguments:
dbmopen(hash, filename, mode)
hash is the name of the hash you will use to manipulate the data in your DBM files; filename forms the basis of the filenames used on your PC (don't include a file extension: Perl will use the filename you supply and create two files from it: filename.pag and filename.dir). mode indicates the permissions for the files (this is of greatest interest on UNIX systems, for Windows, use the permissions in my sample scripts below).
Here's a simple example:
dbmopen(%pets, "C:/temp/petFile", 0644) || die "Cannot open petFile";
$pets{cat} = "Mao";
$pets{dog} = "Spot";
dbmclose(%pets);
Running this script results in two files being created in your temp directory: petFile.dir and petFile.pag - these contain the data we created in the %pets hash. Now you can have a script that reads that data:
dbmopen(%pets, "C:/temp/petFile", 0644) || die "Cannot open petFile";
while(($animal, $name) = each %pets) {
print "the name of my $animal is $name\n";
}
dbmclose(%pets);
An important note is that you cannot manipulate a DBM hash outside of your dbmopen and dbmclose function calls. For example, if you create a hash before calling dbmopen, and then try to manipulate it after calling dbmopen, you will not get the results you expect. This is because the values in the hash will be lost when you call dbmopen. Similarly, after you call dbmclose, you can no longer access the DBM hash.
If you're familiar with using DOS, you're probably used to typing commands like dir and more. You can access these commands from within Perl as well. You do this with the system function. Here's a simple one-line example:
system("dir");
This line of code will cause dir to run exactly as it would if you had typed it yourself, which means the output is returned to your screen. You can also use system to launch applications, such as Notepad:
system('notepad.exe C:\autoexec.bat');
exit;
In this case, I've included a call to the exit function. This will cause the script to stop executing when you close Notepad - otherwise the script will never know you're done, and it will hang your MS-DOS window until you manually cancel it.
Using DOS Features in Your Scripts
You can take advantage of DOS functionality to accomplish certain tasks quickly. For example, if you want to store a directory listing in a file, you can use the DOS redirection functionality. In this example the output of the dir command is redirected to a file, instead of being displayed on the screen.
system('dir c:\windows > c:\temp\windowsDirList.txt');
You can also use pipes, which connect different commands together in a chain. For example, the following one line script reads in the contents of the c:\windows directory, sorts it alphabetically, and then allows you to view the listing one screenful at a time:
system('dir c:\windows | sort | more');
These kinds of system interactions can be very useful for CGI programming. For example, you could create a web-based application that allows users to request the creation of their own web content directories. After taking their information from a web form and processing it, your Perl script could automaticaly create a directory for them on the web server, and assign them a user account and password.
Capturing Output
One limitation of the system function is that it does not allow you to capture its output in Perl variables (a call to system returns a value of 0). To use the output of DOS commands in your scripts, you need to enclose the command in backticks- like this:
@listing = `dir /b`;
foreach $file(@listing) {
print "$file";
}
Your book suggests using qx{} as an alternative notation to backticks. A good reason to do this is that it's easy to confuse backticks with single quotes. However, Perl does not interpret qx{} as robustly. If you use qx{} instead of backticks in the above example, it will not work - qx{} does not interpret /b correctly.
Code Portability
An important consideration when using system commands is whether your script will ever be used on a different operating system in the future. If you're sure that it won't be, then you can use as many OS-specific system commands as you like. But if there's a chance, for example, that a script that relies on DOS commands might someday be used on a Unix computer, then it's important to accomodate that possibility in your script. Otherwise, the script will not work when ported to the new environment.
The first step in ensuring portability is to have your script figure out what OS it's running under. This can be done by examining the $^O system variable (that's a capital O, not a zero). Its value is the name of your computer's OS. Then you can design your script to work correctly in, for example, both Windows and Unix:
if ($^O eq 'MSWin32') {
system("dir");
}
else {
system("ls");
}
See p. 189 of your book for a more detailed example that shows you how to determine how much free space remains on your hard drive - it works equally well in Unix and Windows.