Looking more closely at this version of your code, I'm wondering...
- Why do you do mkdir( "directory$dir",0755 ); and then turn right around and chmod that new directory to 0777? Why not just tell mkdir to use the intended permissions in the first place? (As it turns out, 0777 is said to be the default setting for mkdir.)
- Even if you really had to do chmod on files or directories, why use a system call for that? Is there some problem with using the perl built-in chmod function? (I would expect it to work in an OS-independent manner.)
- Why do the if ($^O =~ /Win32/) branching so many times? I think the two points above would eliminate most of the OS-dependent branching, but if you really still have some points where you need to branch, group those things together a little more, to minimize the number of conditional blocks, and make the code easier to read/maintain.
- It looks like you may be lacking some OS-dependent branching that should be there (near the beginning, where your "die" messages always have backslash paths, regardless of OS).
If you were to use File::Spec (as suggested above), here's how the code would start out:
use strict;
use warnings;
use Cwd;
use Getopt::Long;
use File::Spec; # this will automatically load OS-appropriate functi
+ons
# ... [snip] ...
# Get the current working directory
my $home_dir = getcwd;
# Change to the test directory
chdir($testdir) or die "$0: chdir $testdir: $!";
# Set up test dirs if they do not exist
for my $t ( qw/test test1/ ) {
mkdir $t or die "mkdir ". File::Spec->catfile($testdir, $t) .": $!
+\n";
}
# Change to the test area
chdir("test") or die "chdir test: $!\n";
# Directory Manipulation
for my $dir ( 0 .. $num-1 ) {
my $dirname = "directory$dir";
# Make the directory
if (!-d $dirname ) {
mkdir $dirname or
die "mkdir ". File::Spec->catfile( $testdir, "test", $dirn
+ame ) .": $!\n";
}
#...
I hope that gets the general idea across. It looks like your script is simply meant to check that certain operations work as hoped for, and doesn't really accomplish anything other than testing, so I won't pursue it further.
I'll just emphasize that you should use perl built-in functions and core modules (e.g. File::Copy whenever they are available, rather than system calls to shell commands -- perl already provides a lot of OS-independence for you, and you'll have fewer problems and less code to write that way.
If you really must use system calls to run OS-dependent tools, modularize and/or group those things so that they hang together for each OS. Your code tests the OS type in five different places, and you shouldn't have to do that test more than once (or not at all, with proper use of existing modules). | [reply] [d/l] [select] |
As I mentioned this is to test a filter driver, so I need to make the OS calls with system as they are checked differently than calls made within Perl; and really that is what I need to test. Things like the chmod example you mention are part of the test, to make sure the filter captures and does not barf on things like a chmod call on a directory. So, yes, it is testing and checking that certain operations work as hoped for.
I should do better with the OS dependency and group better, honestly though this script is much cleaner than the one I inherited, and its about 33% smaller than the original one as well. More cleanup on the OS stuff is on my list, I still have no idea why the System calls are suddenly acting up, but at least I can get by with them for now.
Thanks!
| [reply] |
I don't really know what a "filter driver" is, so I still don't understand the rationale for using system calls where perl built-ins are available for the same operations. No big deal, whatever.
In any case, I wonder whether you may have missed the point of the earlier reply from almut:
... [system()] returns the exit code (return value of the wait call) of the called program, which is typically zero upon success...
What that means is that a statement like this:
system( $some_shell_command ) or die "bad news..."
will actually cause the script to die when the system() call succeeds, because a return value of zero (false) from system() means that there was no error indicated in the exit status of the command. A less confusing idiom for doing this sort of error trapping with system() goes like this:
$failed = system( $some_command );
die "bad news..." if ( $failed );
| [reply] [d/l] [select] |