Don't know what's happening with system(). How about showing us a script which triggers the problem?

Also, note that calling external programs will not affect %ENV. Even if the external program modifies an environment variable, it's only modifying it's own local copy.

Thanks a ton for that quick reply... Indeed, as you mentioned, exec was the culprit (I am a n00b ;-) ). The code fragment, nonetheless is here (have commented out the exec) - Thanks again for your help and reply on the dot.:

#!/usr/bin/perl

system "date";



#system 'ls -l $HOME |awk \'{ print $8 }\'';



#exec "date";



#print "$ENV{'PATH'}\n";

#$ENV{'PATH'} = "/home/athampan:$ENV{'PATH'}";

#print "$ENV{'PATH'}\n";





foreach $var (sort keys %ENV)  {

     print "$var => $ENV{$var}\n"

}
[download]

Had you used warnings, you'd have got an error message:

use strict;
use warnings;

exec 'date';
print "still alive\n";
[download]

Statement unlikely to be reached at - line 5.
    (Maybe you meant system() when you said exec()?)
Wed Jul 16 08:36:05 CEST 2008
[download]

--
David Serrano

Works (as expected) for me, linux and Windows:

Tue Jul 15 22:56:32 PDT 2008
CDPATH => .:/home/ikegami:/home/ikegami/www
EDITOR => pico -w -z
...
[download]

The current date is: 2008/07/16
Enter the new date: (yy-mm-dd)
ALLUSERSPROFILE => C:\Documents and Settings\All Users
APPDATA => C:\Documents and Settings\ikegami\Application Data
CLIENTNAME => Console
...
[download]

Unrelated to your original question, but calling out to a shell to get a listing of files is very Rube-Goldberg-ian. See opendir and readdir (and possibly stat if you're interested in the file properties ls -l shows).

The cake is a lie.
The cake is a lie.
The cake is a lie.