in reply to Re^2: System call constantly dying
in thread System call constantly dying

Looking more closely at this version of your code, I'm wondering...

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).

Replies are listed 'Best First'.
Re^4: System call constantly dying
by gokuraku (Monk) on Jul 30, 2008 at 17:07 UTC
    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!
      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 );