As a side note, you could shorten your timestamp code from

($sec,$min,$hour,$mday,$mon,$year) = localtime(time);
$mon = (1,2,3,4,5,6,7,8,9,10,11,12)[$mon];

if($mon  < 10){$mon  = "0" . $mon;}           # add a leading zero to 
+one-digit months
if($mday < 10){$mday = "0" . $mday;}    # add a leading zero to one-di
+git days
if($hour < 10){$hour = "0" . $hour;}    # add a leading zero to one-di
+git hours
if($min  < 10){$min  = "0" . $min;}           # add a leading zero to 
+one-digit minutes
if($sec  < 10){$sec  = "0" . $sec;}            # add a leading zero to
+ one-digit seconds

$dirname  = substr($year,1,3) . $mon . $mday . $hour . $min . $sec;
[download]

my @time = localtime();
$time[4]++; # convert from 0 based index to 1 based index
$time[5]-=100; # 2digits=subtract 100 or 4digits=add 1900
$time[$_] = $time[$_]<10? "0".$time[$_]:$time[$_] for (0..5);

$dirname = $time[5].$time[4].$time[3].$time[2].$time[1].$time[0];
[download]

--
hiseldl
"Act better than you feel"

 $time[5]-=100; is scary for people who had Y2K problems.

++ anyway.

if you can use POSIX; which I just tried on my win2k box and worked, you could use something like this instead:

use POSIX;
# %Y = 4 digit year and %y = 2 digit year
$dirname = strftime("%Y%m%d%H%M%S", localtime);
[download]

Also, you may want to add the PID on the end just in case it runs more than once for the same second. :)

--
hiseldl
"Act better than you feel"

use File::Spec;
use File::Copy;
# Here's where some of your code is that sets some variables, gets the
+ timestamp in array context...
$year += 1900;  # Y2K-compliant
my $dir_prefix = sprintf("%04d%02d%02d%02d%02d%02d", $year, $mon, $mda
+y, $hour, $min, $sec);
my $create_dir = File::Spec->catfile($filedir, $dir_prefix);
if (!-e $create_dir)
{
  if (!mkdir($create_dir))
  {
    # Do something.
  }
  else
  {
    if (!move($IWlogs, $create_dir))
    {
      # Do something.
    }
  }
}
[download]

I tried it and this is what I get. Scalar found where operator expected at testWL2.pl line 10, near "y, $hour, $min , $sec" syntax error at testWL2.pl line 10, near "$mda y, $hour, $min," Execution of testWL2.pl aborted due to compilation errors.

Change $mda y to $mday.

Hmmm... Maybe this will buy me some downvotes, but:

In response to the time fellow monks spend to help you, you could at least try to understand the snipplets. This is so trivial it hurts (and it was merely a cut & paste error on your behalf). We're not here to do your work (even if we sometimes do).

Urm.. Now I feel bad, having written this, I really don't mean to be arrogant. From your style I assume you're a beginner, but you would have found this on your own. All of us here like to help, but we also like to make people trust in their own problem solving abilities.

So long,
Flexx

Just a note on error handling:

Maybe it's because I've been writing way too much Java lately, but I've gotten used to making my error messages verbose, at least in the development and testing phases. The first thing I thought when I read

error creating \\NTSERVER\TempLogs\020910145659! at testWL.pl line 28.
[download]

system(@args) == 0 or die "error creating $createDir :\n$!";
[download]

True, true.

$! is much more important than even the filename itself. For testing and debugging purposes I usually just do a 'or die $!', that gives me the linenumber and the problem, what, most times, is all I need..
Allthough, sometimes it may be helpfull to write out the filname too, i.e. if you're not sure whether it is correct (calculated).

lg,
daniel

Quite right. I remember when I first started writing largeish projects, and was using some OOness that got pretty convoluted at times. Often, when Perl died it spat out a filename and line number that was completely useless. It would be the file that was calling a function in another file that called a function in another file where there was a bug. I quickly learned to output readable and informative debug messages.

Actually, AFAIR (and my memory is patchy at best) if there's a bug inside an eval statement, don't the dying words say that the problem was on line 0 or something... or just not complain at all...

Anyway, now I have fun with error messages. Looking at debug output of my code you may see stuff like the following:

The Command Dispatcher hates you beause: java.lang.NullPointerExceptio
+n
The GUI farted the following: ArrayOutOfBoundsException: 3 >= 1
[download]

or whatever. Like I said, way too much Java lately :o)

LAI
:eof

Hmmm. I would say both $! and the filename are very important to include in the error message, if only because malforming the filename in some way is an extremely common problem and can occur in many ways.

What is especially insiduous and hard to track, is when a file exists with the malformed name. Now that is a real pain in the butt.

Here are some common ways of malforming filenames:

1 - path missing. This often occurs when using the result directly from readdir or File::Find::find without adding the path.

2 - linebreak in filename. This typically occurs when newbies capture the output of `ls` or `dir` instead of using readdir as they should and forget to chomp.

3 - Wrong case. Perl, like Unix, is case sensitive, but users raised on Windows and Mac systems tend to forget this.

4 - Concatenating a file name in the wrong way, for example:


my $path = '/usr/home/jones'; 
my $file = 'foo.txt';
my $filename = $path . $file.
[download]

This will result in the nonexistent filename /usr/home/jonesfoo.txt, but is hard to catch.

5 - Using unescaped backslashes on Windows (extremely common). Filenames like "C:\terry\new.html" are a common source of Windows/Perl nightmares (Perl reads it as "C: TAB erry NEWLINE ew.html"). Use ordinary slashes under Windows and save yourself endless hassle as well as making your code more portable as a side effect.

I hope this helps someone.

Regards,
Helgi Briem