Re: Storing Output file.
Hi Frank, Really don't leave! Cyber-bullying is pathetic and the reserve of the ignorant. Just like an annoying itch, it's there and must be ignored. This community is informative and brimming with good people who are kind and willing to help. I have personally and gratefully benefitted from their vast collective knowledge. The list moderator is proactive and has the best interests of this community at heart. You would be well advised to remain and continue learning this fabulous language, hopefully with the view to gaining sufficient knowledge so as to help others in the near future. Bests, Jonathan On Tuesday, February 2, 2016, Frank Vino <vinofra...@gmail.com> wrote: > Hi Andrew, > > I felt bad the way he used the language and i am leaving from this > community...Thanks for all your help! > > -Frank > > > On Mon, Feb 1, 2016 at 8:42 PM, Andrew Solomon <and...@geekuni.com > <javascript:_e(%7B%7D,'cvml','and...@geekuni.com');>> wrote: > >> Hi Everyone >> >> As you can see from the description of this list >> http://learn.perl.org/faq/beginners.html Thomas J Hughes' response is >> inappropriate and I've raised this issue with the moderator. >> >> Please carry on with the polite and helpful discussions for which this >> list has a reputation to uphold. >> >> Andrew >> >> >> On Mon, Feb 1, 2016 at 2:33 PM, Danny Spell <ddsp...@gmail.com >> <javascript:_e(%7B%7D,'cvml','ddsp...@gmail.com');>> wrote: >> > Isn't this a beginners' list? >> > >> > Regards, >> > Danny Spell >> > DDSpell Consulting >> > 214-682-4898 >> > >> > On Mon, Feb 1, 2016 at 7:34 AM, Thomas J Hughes <thugh...@gmail.com >> <javascript:_e(%7B%7D,'cvml','thugh...@gmail.com');>> wrote: >> >> >> >> Go read a fuckin book and stop spamming people's email or I will hack >> >> yours ! If you want to learn a language you need to first learn the >> >> basis stupid and build from their people are not going to tell you have >> >> shotcut something learn to read asshole >> >> >> >> >> >> >> >> >> >> >> >> WARNING TO ALL VETERANS: >> >> >> >> >> https://www.oathkeepers.org/us-senate-passes-bill-approving-mandatory-vaccinations-for-veterans/ >> >> >> >> >> >> >> >> >> >> On Fri, Jan 29, 2016 at 9:24 PM, Frank Vino <vinofra...@gmail.com >> <javascript:_e(%7B%7D,'cvml','vinofra...@gmail.com');>> wrote: >> >>> >> >>> Thanks a lot Jonathan, i will set the env properly then i will try. >> >>> >> >>> >> >>> -Frank >> >>> >> >>> On Fri, Jan 29, 2016 at 3:36 PM, Jonathan Harris >> >>> <jtnhar...@googlemail.com >> <javascript:_e(%7B%7D,'cvml','jtnhar...@googlemail.com');>> wrote: >> >>>> >> >>>> Hi Frank, >> >>>> Please would you remember to Reply All to the list as well? >> >>>> >> >>>> It just seems that the path is not included in @INC >> >>>> You can check on the command line: >> >>>> >> >>>> perl -e "print qq(@INC)" >> >>>> >> >>>> I can't tell how you installed Perl and cpan but that's the result! >> >>>> >> >>>> Anyways, it's easily fixed. >> >>>> >> >>>> At the start of the script, use: >> >>>> >> >>>> use lib 'C:\Perl64\cpan\build'; >> >>>> use File::Slurp qw( :edit ); >> >>>> >> >>>> However, this would have to be added to every script. >> >>>> If the path is an issue for all scripts, then it would be better to >> make >> >>>> the change permanent. >> >>>> There are good instructions here to adding the Environment Variable: >> >>>> >> >>>> >> >>>> >> http://perlmaven.com/how-to-change-inc-to-find-perl-modules-in-non-standard-locations >> >>>> >> >>>> Good luck! >> >>>> Jon >> >>>> >> >>>> >> >>>> On Fri, Jan 29, 2016 at 4:08 AM, Frank Vino <vinofra...@gmail.com >> <javascript:_e(%7B%7D,'cvml','vinofra...@gmail.com');>> >> >>>> wrote: >> >>>>> >> >>>>> Hi Jonathan, >> >>>>
Re: Storing Output file.
Hi Shlomi, Thanks for that pointer. I read your linked pages and it doesn't seem that there is yet a solution as simple as the 'edit_file' method. Shame as it was so handy, but the arguments against it are quite compelling. @Frank - looks like the original scripting with printing to file handles is the immediate future. Thanks, Jonathan On Fri, Jan 29, 2016 at 10:45 AM, Shlomi Fish <shlo...@shlomifish.org> wrote: > Hi Jonathan, > > On Thu, 28 Jan 2016 17:57:19 +0000 > Jonathan Harris via beginners <beginners@perl.org> wrote: > > > Hi, > > I found that this works, assuming that the module is installed. > > > > #!/usr/bin/perl > > use warnings; > > use strict; > > use File::Slurp qw ( :edit ); > > using File::Slurp is no longer recommended: > > > http://blogs.perl.org/users/leon_timmermans/2015/08/fileslurp-is-broken-and-wrong.html > > I don't know how many of the listed alternatives have equivalents to the > edit > functions, but see my issue and branch for Path::Tiny about it: > > * https://github.com/dagolden/Path-Tiny/issues/161 > > * > https://github.com/shlomif/Path-Tiny/tree/edit-file-methods--a-la-File-Slurp > > Regards, > > Shlomi Fish > > -- > To unsubscribe, e-mail: beginners-unsubscr...@perl.org > For additional commands, e-mail: beginners-h...@perl.org > http://learn.perl.org/ > > >
Re: Storing Output file.
Hi Frank,
Please would you remember to Reply All to the list as well?
It just seems that the path is not included in @INC
You can check on the command line:
perl -e "print qq(@INC)"
I can't tell how you installed Perl and cpan but that's the result!
Anyways, it's easily fixed.
At the start of the script, use:
use lib 'C:\Perl64\cpan\build';
use File::Slurp qw( :edit );
However, this would have to be added to every script.
If the path is an issue for all scripts, then it would be better to make
the change permanent.
There are good instructions here to adding the Environment Variable:
http://perlmaven.com/how-to-change-inc-to-find-perl-modules-in-non-standard-locations
Good luck!
Jon
On Fri, Jan 29, 2016 at 4:08 AM, Frank Vino <vinofra...@gmail.com> wrote:
> Hi Jonathan,
>
> I am using Windows OS i tried but i got some error message i am attaching
> the message here
>
> *Output:*
>
> C:\Users\Franklin_Lawerence\Desktop\perl>arrarsize.pl
> Can't locate File/Slurp.pm in @INC (@INC contains: C:/Perl64/site/lib
> C:/Perl64/lib .) at C:\Users\Franklin_Lawerence\Desktop\perl\arrarsize.pl
> line 5.
> BEGIN failed--compilation aborted at
> C:\Users\Franklin_Lawerence\Desktop\perl\arrarsize.pl line 5.
>
> C:\Users\Franklin_Lawerence\Desktop\perl>
>
>
> *File-Slurp installed in below Program files folder:*
>
> C:\Perl64\cpan\build\File-Slurp-.19-_tH9hN
>
> On Thu, Jan 28, 2016 at 11:27 PM, Jonathan Harris via beginners <
> beginners@perl.org> wrote:
>
>> Hi,
>> I found that this works, assuming that the module is installed.
>>
>> #!/usr/bin/perl
>> use warnings;
>> use strict;
>> use File::Slurp qw ( :edit );
>> #
>> my $file_to_edit = 'path-to-file.txt';
>> #
>> my $word_to_edit = "Debug";
>> my $new_word = "Error";
>> #
>> edit_file { s/$word_to_edit/$new_word/g } ( $file_to_edit );
>> #
>>
>> This will work if you have the word Debug, Debug_ etc etc
>> You can just use s/Debug/Error/g but I like the variables as it allows
>> flexibility if the script was to expand to further uses
>>
>> Hope that helps,
>> Jon
>>
>>
>> On Thu, Jan 28, 2016 at 3:41 PM, Jim Gibson <j...@gibson.org> wrote:
>>
>>>
>>> > On Jan 28, 2016, at 1:37 AM, Frank Larry <frankylarry2...@gmail.com>
>>> wrote:
>>> >
>>> > Hi Team,
>>> >
>>> > could you please let me? i have a file which contains "Debug", i
>>> would like to replace debug to "Error", when i ran the below program the
>>> out showing Error message but how to save the output with new changes.
>>> Could you please tell me how to fix it?
>>>
>>> The way to do this within a larger Perl program is to open a new output
>>> file, copy all of the possibly-modified lines to this file. Then you can
>>> rename the new file to the same name as the old file, and perhaps rename
>>> the old file as well and keep it around as a backup.
>>>
>>> >
>>> > open(FILE, "<filter.txt") or die "Can’t open $!\n”;
>>>
>>> The three-argument version of open is preferred here, and let’s put the
>>> file name in a variable and use a lexical variable for the file handle
>>> (untested):
>>>
>>> my $filename = ‘filter.txt’;
>>> open( my $in, ‘<‘, $filename ) or die(“Can’t open $filename for reading:
>>> $!”);
>>>
>>> # create a new file
>>> my $newfile = $filename . ‘.new’;
>>> open( my $out, ‘>’, $newfile ) or die(“Can’t create $newfile: $!”);
>>>
>>> >
>>> > while($line = ){
>>>
>>> while( $line = <$in> ) {
>>>
>>> >
>>> >print "Before substituting: ", $line ,"\n";
>>> > $line =~ s/Debug/Error/g;
>>> > print "After substituting : ", $line , "\n”;
>>>
>>> print $out $line;
>>> >
>>> > }
>>> >
>>> > close(FILE);
>>>
>>> close($in);
>>> close($out) or die(“Error writing to output file $newfile: $!”);
>>>
>>> # rename the old file
>>> my $savefile = $filename . ‘.sav’;
>>> rename $filename, $savefile;
>>>
>>> # rename the new file
>>> rename $newfile, $filename;
>>>
>>> Jim Gibson
>>> j...@gibson.org
>>>
>>>
>>>
>>>
>>> --
>>> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
>>> For additional commands, e-mail: beginners-h...@perl.org
>>> http://learn.perl.org/
>>>
>>>
>>>
>>
>
Re: Storing Output file.
Hi,
I found that this works, assuming that the module is installed.
#!/usr/bin/perl
use warnings;
use strict;
use File::Slurp qw ( :edit );
#
my $file_to_edit = 'path-to-file.txt';
#
my $word_to_edit = "Debug";
my $new_word = "Error";
#
edit_file { s/$word_to_edit/$new_word/g } ( $file_to_edit );
#
This will work if you have the word Debug, Debug_ etc etc
You can just use s/Debug/Error/g but I like the variables as it allows
flexibility if the script was to expand to further uses
Hope that helps,
Jon
On Thu, Jan 28, 2016 at 3:41 PM, Jim Gibson wrote:
>
> > On Jan 28, 2016, at 1:37 AM, Frank Larry
> wrote:
> >
> > Hi Team,
> >
> > could you please let me? i have a file which contains "Debug", i would
> like to replace debug to "Error", when i ran the below program the out
> showing Error message but how to save the output with new changes. Could
> you please tell me how to fix it?
>
> The way to do this within a larger Perl program is to open a new output
> file, copy all of the possibly-modified lines to this file. Then you can
> rename the new file to the same name as the old file, and perhaps rename
> the old file as well and keep it around as a backup.
>
> >
> > open(FILE, "
> The three-argument version of open is preferred here, and let’s put the
> file name in a variable and use a lexical variable for the file handle
> (untested):
>
> my $filename = ‘filter.txt’;
> open( my $in, ‘<‘, $filename ) or die(“Can’t open $filename for reading:
> $!”);
>
> # create a new file
> my $newfile = $filename . ‘.new’;
> open( my $out, ‘>’, $newfile ) or die(“Can’t create $newfile: $!”);
>
> >
> > while($line = ){
>
> while( $line = <$in> ) {
>
> >
> >print "Before substituting: ", $line ,"\n";
> > $line =~ s/Debug/Error/g;
> > print "After substituting : ", $line , "\n”;
>
> print $out $line;
> >
> > }
> >
> > close(FILE);
>
> close($in);
> close($out) or die(“Error writing to output file $newfile: $!”);
>
> # rename the old file
> my $savefile = $filename . ‘.sav’;
> rename $filename, $savefile;
>
> # rename the new file
> rename $newfile, $filename;
>
> Jim Gibson
> j...@gibson.org
>
>
>
>
> --
> To unsubscribe, e-mail: beginners-unsubscr...@perl.org
> For additional commands, e-mail: beginners-h...@perl.org
> http://learn.perl.org/
>
>
>
Re: Which Is Good?
I use Strawberry Perl to manage troublesome processes on Windows 2008 Server. Have never had an issue! It's stable and simple to install. I was advised to only install the 32bit version, even though it's a 64bit OS. That advise came from a live forum of regular advanced Strawberry Users, so I took the advice seriously. Hope this helps. Bests, Jonathan On Thursday, March 12, 2015, Frank Vino vinofra...@gmail.com wrote: Activeperl or Strawberry Perl. = Which is good to use? -Frank
Re: Win32 - Killing Processes
On Tue, Apr 9, 2013 at 11:15 PM, Mike Flannigan mikef...@att.net wrote: On 4/9/2013 6:10 AM, Jonathan Harris wrote: Hi All I am using Strawberry Perl (latest release) on a Windows 2003 SP2 server I am trying to use a script to look at running processes, look for a specific process, and kill that process if it is alive for more than 4 minutes as this would mean that the process has hung When testing killing Notepad or Firefox, it works fine In practice when trying to kill ovntag or oprop processes, it doesn't It uses the following to kill the process: Win32::Process::KillProcess ($pid, \$exitcode); So here's the question. Is there a difference between killing a process that is alive and one that has hung? In theory a process is a process, right?! But the hanging process does not die! Is there a better way to kill a process so that a hanging process will actually die? Thanks in advance Jon It's highly unlikely this will fix your problem, but I will throw it out for consideration: $ProcessObj-Kill( $exitcode ) Kill the associated process, have it terminate with exit code $ExitCode Mike -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/ Hi Mike Many thanks for your response I updated this post yesterday with a revised subject (Win32 - Killing Processes - Update Possible Solution ) - probably should have kept it all on the same thread! I did try what you suggested, but with not much luck Instead as an option I am testing a fix, using a system call to Windows to force quit the process system 'taskkill /f /PID ' . ($new_pid); As anyone who has used windows has probably experienced before, when trying to use task manager to quit a hung process, the 'end process' button doesn't always do the job first time around and can often require multiple clicks! I have the feeling that this process gets itself into that state, so a single call from the Win32 module is probably insufficient However, using taskkill on the cli with the 'force' argument has a far higher success rate - hence the system call Hopefully this will solve the issue! If you can think of anything else at all, I'm all ears and grateful for any input! Thanks again Jon
Re: Win32 - Killing Processes - update possible solution
On Wed, Apr 10, 2013 at 12:02 PM, Jenda Krynicky je...@krynicky.cz wrote: From: Jonathan Harris jtnhar...@googlemail.com As it seems that Win32::Process::KillProcess is having difficulties killing a hanging process, I thought that it would probably make sense to ask the system to do it directly So, in the sub 'kill_it', I have replaced the line Win32::Process::KillProcess ($new_pid, \$exitcode); with system 'Taskkill /PID ' . ($new_pid); I am using 'system' rather than 'exec' as it returns a success status; 'exec' is silent in this respect The fairly confusingly named fuction exec() never returns! It's supposed to be used if you are done executing your program and want to switch to executing a different one ... usually after you fork()ed ... that is cloned the process. The way processed are started in unix is a little ... awkward. Instead of telling the system you want to execute some program with some parameters, you are supposed to split in two and in one of the clones, after you are finished setting things up, morph into another program. Kinda hacky. Jenda = je...@krynicky.cz === http://Jenda.Krynicky.cz = When it comes to wine, women and song, wizards are allowed to get drunk and croon as much as they like. -- Terry Pratchett in Sourcery -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/ Hi Jenda Thanks for the clarification on exec() and 'system' Processes in Unix have so far seemed easier to handle - if you want them destroyed, a 'kill -9' signal really does the job! In Windows, the steps have not appeared as straight forwards as there are a few different ways to end a process - taskkill, process -k etc etc Hopefully, the taskkill will do the job! Thanks for your input Jon
Re: Win32 - Killing Processes - update possible solution
On Mon, Apr 8, 2013 at 4:41 PM, Jonathan Harris jtnhar...@googlemail.comwrote:
Hi All
I am using Strawberry Perl (latest release) on a Windows 2003 SP2 server
I am trying to use a script to look at running processes, look for a
specific process, and kill that process if it is alive for more than 4
minutes as this would mean that the process has hung
When testing killing Notepad or Firefox, it works fine
In practice when trying to kill ovntag or oprop processes, it doesn't
It uses the following to kill the process:
Win32::Process::KillProcess ($pid, \$exitcode);
So here's the question.
Is there a difference between killing a process that is alive and one that
has hung?
In theory a process is a process, right?!
But the hanging process does not die!
Is there a better way to kill a process so that a hanging process will
actually die?
Thanks in advance
Jon
ps - the script also records a log if the process is killed - this
required a cleanup sub as for some reason I haven't worked out yet, I
cannot created the entire log file name in one go! This is not of concern -
will look into it soon enough
pps - Disclaimer! I am a total perl noob and have no code training, so
sorry if the code is ugly and wasteful
#!C:\strawberry\perl\bin\perl.exe
#process3.pl
use warnings;
use strict;
use Win32::Process;
use Win32::Process::List;
use DateTime;
my %list;
my ( $process, $process_name, $pid, $new_pid, $it_lives, $it_lives_name,
$dt, $log_file );
$log_file = C:/process_logs/log_ || shift;
$dt = DateTime-now(time_zone = 'Europe/London');
first_check();
if ($it_lives) {
kill_it();
}
cleanup();
sub first_check {
$process = Win32::Process::List-new();
%list = $process-GetProcesses();
foreach $pid ( sort {$a = $b} keys %list ) {
$process_name = $list{$pid};
print $pid\t$process_name\n;
## next line for testing only ##
if ($process_name =~/^notepad/ || $process_name =~/^fire/) {
##if ($process_name =~/^ovntag/ || $process_name =~/^oprop/) {
$it_lives = $pid;
$it_lives_name = $process_name;
sleep 240;
return $it_lives, $it_lives_name;
}
}
undef %list;
}
sub kill_it {
$process = Win32::Process::List-new();
%list = $process-GetProcesses();
foreach $new_pid ( sort {$a = $b} keys %list ) {
$process_name = $list{$new_pid};
print $new_pid\t$process_name\n;
if ($it_lives == $new_pid) {
my $exitcode;
Win32::Process::KillProcess ($new_pid, \$exitcode);
open (my $fh, , $log_file) || die $!;
print $fh $dt, \n\n$new_pid\t$process_name\n;
print $fh \n, $it_lives, \t$it_lives_name Was Killed, \n\n;
close $fh;
}
}
undef %list;
}
sub cleanup {
my $oldname = C:/process_logs/log_;
my $newname = $oldname . $dt-ymd('-') . 'T' . $dt-hms('-') . \.txt;
rename $oldname, $newname;
}
Hi All
I may have found a possible solution and wanted to share it
As it seems that Win32::Process::KillProcess is having difficulties killing
a hanging process, I thought that it would probably make sense to ask the
system to do it directly
So, in the sub 'kill_it', I have replaced the line
Win32::Process::KillProcess ($new_pid, \$exitcode);
with
system 'Taskkill /PID ' . ($new_pid);
I am using 'system' rather than 'exec' as it returns a success status;
'exec' is silent in this respect
Will put this live and see if it really resolves the issue (it does work in
testing on active processes)
Hope this is helpful to someone!
Jon
Re: Win32 - Killing Processes - update possible solution
On Tue, Apr 9, 2013 at 5:42 PM, Jonathan Harris jtnhar...@googlemail.comwrote:
On Mon, Apr 8, 2013 at 4:41 PM, Jonathan Harris
jtnhar...@googlemail.comwrote:
Hi All
I am using Strawberry Perl (latest release) on a Windows 2003 SP2 server
I am trying to use a script to look at running processes, look for a
specific process, and kill that process if it is alive for more than 4
minutes as this would mean that the process has hung
When testing killing Notepad or Firefox, it works fine
In practice when trying to kill ovntag or oprop processes, it doesn't
It uses the following to kill the process:
Win32::Process::KillProcess ($pid, \$exitcode);
So here's the question.
Is there a difference between killing a process that is alive and one
that has hung?
In theory a process is a process, right?!
But the hanging process does not die!
Is there a better way to kill a process so that a hanging process will
actually die?
Thanks in advance
Jon
ps - the script also records a log if the process is killed - this
required a cleanup sub as for some reason I haven't worked out yet, I
cannot created the entire log file name in one go! This is not of concern -
will look into it soon enough
pps - Disclaimer! I am a total perl noob and have no code training, so
sorry if the code is ugly and wasteful
#!C:\strawberry\perl\bin\perl.exe
#process3.pl
use warnings;
use strict;
use Win32::Process;
use Win32::Process::List;
use DateTime;
my %list;
my ( $process, $process_name, $pid, $new_pid, $it_lives, $it_lives_name,
$dt, $log_file );
$log_file = C:/process_logs/log_ || shift;
$dt = DateTime-now(time_zone = 'Europe/London');
first_check();
if ($it_lives) {
kill_it();
}
cleanup();
sub first_check {
$process = Win32::Process::List-new();
%list = $process-GetProcesses();
foreach $pid ( sort {$a = $b} keys %list ) {
$process_name = $list{$pid};
print $pid\t$process_name\n;
## next line for testing only ##
if ($process_name =~/^notepad/ || $process_name =~/^fire/) {
##if ($process_name =~/^ovntag/ || $process_name =~/^oprop/) {
$it_lives = $pid;
$it_lives_name = $process_name;
sleep 240;
return $it_lives, $it_lives_name;
}
}
undef %list;
}
sub kill_it {
$process = Win32::Process::List-new();
%list = $process-GetProcesses();
foreach $new_pid ( sort {$a = $b} keys %list ) {
$process_name = $list{$new_pid};
print $new_pid\t$process_name\n;
if ($it_lives == $new_pid) {
my $exitcode;
Win32::Process::KillProcess ($new_pid, \$exitcode);
open (my $fh, , $log_file) || die $!;
print $fh $dt, \n\n$new_pid\t$process_name\n;
print $fh \n, $it_lives, \t$it_lives_name Was Killed, \n\n;
close $fh;
}
}
undef %list;
}
sub cleanup {
my $oldname = C:/process_logs/log_;
my $newname = $oldname . $dt-ymd('-') . 'T' . $dt-hms('-') . \.txt;
rename $oldname, $newname;
}
Hi All
I may have found a possible solution and wanted to share it
As it seems that Win32::Process::KillProcess is having difficulties
killing a hanging process, I thought that it would probably make sense to
ask the system to do it directly
So, in the sub 'kill_it', I have replaced the line
Win32::Process::KillProcess ($new_pid, \$exitcode);
with
system 'Taskkill /PID ' . ($new_pid);
I am using 'system' rather than 'exec' as it returns a success status;
'exec' is silent in this respect
Will put this live and see if it really resolves the issue (it does work
in testing on active processes)
Hope this is helpful to someone!
Jon
Last Update!
Make that
system 'taskkill /f /PID ' . ($new_pid);
To make sure that the hanging process is forcefully killed
re: Win32 - Killing Processes
Hi All
I am using Strawberry Perl (latest release) on a Windows 2003 SP2 server
I am trying to use a script to look at running processes, look for a
specific process, and kill that process if it is alive for more than 4
minutes as this would mean that the process has hung
When testing killing Notepad or Firefox, it works fine
In practice when trying to kill ovntag or oprop processes, it doesn't
It uses the following to kill the process:
Win32::Process::KillProcess ($pid, \$exitcode);
So here's the question.
Is there a difference between killing a process that is alive and one that
has hung?
In theory a process is a process, right?!
But the hanging process does not die!
Is there a better way to kill a process so that a hanging process will
actually die?
Thanks in advance
Jon
ps - the script also records a log if the process is killed - this required
a cleanup sub as for some reason I haven't worked out yet, I cannot created
the entire log file name in one go! This is not of concern - will look into
it soon enough
pps - Disclaimer! I am a total perl noob and have no code training, so
sorry if the code is ugly and wasteful
#!C:\strawberry\perl\bin\perl.exe
#process3.pl
use warnings;
use strict;
use Win32::Process;
use Win32::Process::List;
use DateTime;
my %list;
my ( $process, $process_name, $pid, $new_pid, $it_lives, $it_lives_name,
$dt, $log_file );
$log_file = C:/process_logs/log_ || shift;
$dt = DateTime-now(time_zone = 'Europe/London');
first_check();
if ($it_lives) {
kill_it();
}
cleanup();
sub first_check {
$process = Win32::Process::List-new();
%list = $process-GetProcesses();
foreach $pid ( sort {$a = $b} keys %list ) {
$process_name = $list{$pid};
print $pid\t$process_name\n;
## next line for testing only ##
if ($process_name =~/^notepad/ || $process_name =~/^fire/) {
##if ($process_name =~/^ovntag/ || $process_name =~/^oprop/) {
$it_lives = $pid;
$it_lives_name = $process_name;
sleep 240;
return $it_lives, $it_lives_name;
}
}
undef %list;
}
sub kill_it {
$process = Win32::Process::List-new();
%list = $process-GetProcesses();
foreach $new_pid ( sort {$a = $b} keys %list ) {
$process_name = $list{$new_pid};
print $new_pid\t$process_name\n;
if ($it_lives == $new_pid) {
my $exitcode;
Win32::Process::KillProcess ($new_pid, \$exitcode);
open (my $fh, , $log_file) || die $!;
print $fh $dt, \n\n$new_pid\t$process_name\n;
print $fh \n, $it_lives, \t$it_lives_name Was Killed, \n\n;
close $fh;
}
}
undef %list;
}
sub cleanup {
my $oldname = C:/process_logs/log_;
my $newname = $oldname . $dt-ymd('-') . 'T' . $dt-hms('-') . \.txt;
rename $oldname, $newname;
}
Re: File Size Script Help - Working Version
On Sat, Dec 31, 2011 at 4:29 AM, John W. Krahn jwkr...@shaw.ca wrote:
Igor Dovgiy wrote:
Great work, Jonathan!
Notice how simple your script has become - and that's a good sign as well
in Perl. :) We can make it even simpler, however.
As you probably know, Perl has two fundamental types of collections:
arrays
(where data is stored as a sequence of elements, data chunks) and hashes
(where data chunks are unordered, but stored with some unique key used to
retrieve it). Sometimes hashes are used just to sort out (non-)unique
data,
but that's another story.
Now look at this line:
push @{$files{$filesize}}, $File::Find::name;
Don't you see something... weird? You're using hash where filesizes are
the
keys - and because, yes, they may well be non-unique, you have to store
arrays of filenames in your hash instead...
But much more natural (at least, for me) is to organize your hash (let's
call it %filedata) so that filenames (which are unique by their nature)
become the keys. And some info about these files - sizes and md5-hashes -
become the values.
Yes, file names in a given directory _have_ to be unique, however...
For example, our `wanted` (btw, its name is misleading a bit, no? may be
'process' will sound better?) sub may look as follows:
find(\wanted, $path);
my %filedata;
sub wanted {
return if substr($_, 0, 1) eq '.' || -d $_;
my $filesize = -s _;
open my $fh, '', $_ or die $!, $/;
my $filemd5 = Digest::MD5-new-addfile($fh)**-hexdigest;
close $fh;
$filedata{$_} = [$filesize, $filemd5];
You are traversing a directory tree, so using $_ as the key may cause
collisions across different directories. Better to use $File::Find::name
which contains the full absolute path name.
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Hi to all on the list still following this thread - and Happy New Year!
Igor...Thanks!! : )
It does feel like there has been some really good Perl learning progress
being made here - and yep, I cannot believe how trimmed down the script has
now become.
Looking back on the original script makes me laugh!
I wonder if that will become a consistent theme when writing?!
Looking back to the hash - I agree that it makes far more sense to have the
filenames as the keys
Quoting yourself and John:
filenames (which are unique by their nature)
Yes, file names in a given directory _have_ to be unique.
I think that we can all be in agreement then that these entries should be
guaranteed to have unique keys and can have non-unique data such as file
size attributed to them- therefore:
push @{$files{$filename}}, $File::Find::name;
When sorting the hash, there seems to well established code for this
eg:
sorting by file size:
foreach (sort {$filedata{$b} = $filedata{$a}} keys %filedata { ##
should sort so that the highest value file size is first
...
}
As far as I'm aware, = and cmp are the same thing
Is there a question of precedence over them?
I assume that = has a higher precedence
Interestingly, this is now the second time in this thread that we have been
warned against using $_
From John:
$_ as the key may cause collisions across different directories
From Shlomi:
The $_ variable can be easily devastated. You should use a lexical one.
I believe that I understand the use of $_ as the default variable; indeed,
the documentation on CPAN about File::Find states the usage of $_ in the
module
However, it seems that it is a variable that it so easily destroyed and
many have warned against using it
If this is the case, why would we choose (or be required) to use it in the
first place?
I have read the 'Elements to Avoid' page, as recommended by Shlomi
http://perl-begin.org/tutorials/bad-elements/
which is very useful
Would it be correct to say that $_ should be re-assigned asap whenever
using Perl?
I couldn't find any exceptions that state that it is ok to use it
#
Sincere thanks again to you all for your contributions
I hope that others reading this list are learning as much as I am!
All the best
Jonathan
Re: File Size Script Help - Working Version
On Fri, Dec 30, 2011 at 11:58 AM, Igor Dovgiy ivd.pri...@gmail.com wrote: Hi John, yes, good point! Totally forgot this. ) Adding new files to a directory as you browse it is just not right, of course. Possible, but not right. ) I'd solve this by using hash with filenames as keys and collected 'result' strings (with md5 and filesizes) as values, filled by File::Find target routine. After the whole directory is processed, this hash should be 'written out' into the target directory. Another way to do it is to collect all the filenames instead into a list (with glob operator, for example), and process this list after. BTW (to Jonathan), I wonder do you really need to store this kind of data in different files? No offence... but I can hardly imagine how this data will be used later unless gathered into some array or hash. ) -- iD 2011/12/30 John W. Krahn jwkr...@shaw.ca Jonathan Harris wrote: Hi John Thanks for your 2 cents I hadn't considered that the module wouldn't be portable That is not what I was implying. I was saying that when you add new files to a directory that you are traversing you _may_ get irregular results. It depends on how your operating system updates directory entries. Hi All John - Thanks for the clarification In this instance the script has been run on OSX - it seems that adding the files into the directory that is being traversed works ok this time However for best practice, I would certainly look into writing to a separate directory, and then moving the files back, as I appreciate that this fortune may not necessarily be repeated in a different environment! Igor - Firstly - File::Spec Thanks for your insight and well explained investigation - I have been learning a lot from this File::Spec has proven a most useful tool in joining and 'stringifying' the paths In the original post about this script, I had spoken about considering using a hash for the file data I'm still convinced that ultimately, this would be the way forwards I have found some scripts online concerning finding duplicate files They use md5 and/or file sizes to compare the files These are written into hashes Fully understanding some of these scripts is a little beyond my level at the moment I have attached an interesting one for you to look at (you may be aware of it already!) However, it has proved quite inspiring! (substr($line, 0, 1) eq '.') Haven't learned this yet! It looks like a good solution if it is so much more efficient - thanks for the introduction - I'll be reading up asap! BTW (to Jonathan), I wonder do you really need to store this kind of data in different files? No offence... but I can hardly imagine how this data will be used later unless gathered into some array or hash. ) There is a good reason for this! Talking to guys who work in video on demand, it seems that it is standard practice to do this for file delivery requirements As each video file must be identical upon receipt as it was upon delivery ( and that the files are all treated as unique delivery instances ) a separate accompanying file is required I thought that Perl would be a good choice for accomplishing this requirement as it is renowned for file handling # Thanks to everyone for your help and contributions - particularly Jim, Shlomi, John and Igor I have learned crazy amounts already! Happy New Year to you all! Jonathan finddupes3.plx Description: Binary data -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/
Re: File Size Script Help - Working Version
On Fri, Dec 30, 2011 at 7:11 PM, Brandon McCaig bamcc...@gmail.com wrote:
On Thu, Dec 29, 2011 at 03:43:19PM +, Jonathan Harris wrote:
Hi All
Hello Jonathan:
(Disclaimer: I stayed up all night playing Skyrim and am running
on about 4.5 hours of sleep.. ^_^)
I think most things have already been addressed, but I think Igor
might have had a bit of trouble making it clear.
opendir (my $in, $path) or die Cannot open $dir: $!\n;
find (\wanted, $path);
close $in;
opendir (my $totalin, $path) or die Cannot open $dir: $!\n;
find (\cleanup, $path);
close $totalin;
AFAICT, it's completely nonsensical to open a directory file
handle surrounding File::Find::find. I tried to /search the
perldoc (just in case there's some kind of magical optimization
or something) and saw no mention of 'opendir' or 'handle' (except
for the special _ file handle created for stat, lstat, etc..). So
it seems $in and $totalin are completely unnecessary here:
File::Find will worry about opening and processing the
directories for you.
sub wanted {
while ($dircontents = readdir($in)) {
I guess this is why you are opening directory handles above, but
it doesn't really make sense. You're basically only using
File::Find to loop at this point, and very obscurely. :)
File::Find's role in life is precisely to find you all the files
within a directory tree. You're reinventing the square wheel with
your use of opendir and readdir. :)
The wanted subroutine is typically used to either process the
file system tree outright, or store applicable files in data
structures for later processing. E.g.,
use strict;
use warnings;
use File::Find;
my @files;
sub wanted
{
# Skip dot files and directories.
return if substr($_, 0, 1) eq '.' || -d $_;
# If current file is a normal file, push into array for
# later.
push @files, $File::Find::name if -f $_;
}
my $path = '.';
find \wanted, $path;
# Now @files should be filled with a recursive list of files to
# process. E.g.,
for my $file (@files)
{
my $md5name = $file.'md5';
# Etc...
}
my $hex = Digest::MD5-new-addfile($fh)-hex digest;
I assume you meant `hexdigest' here, not 'hex digest'.
$newname =~ s/\ //;
Ideally if you're going to do something as obscure as this, you
should comment it in both places so future readers and
maintainers understand why it's done, even if they only read one
half of the program.
I think Igor else has already explained how to eliminate this
obscurity though. :)
Regards,
--
Brandon McCaig bamcc...@gmail.com bamcc...@castopulence.org
Castopulence Software https://www.castopulence.org/
Blog http://www.bamccaig.com/
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (GNU/Linux)
iQIcBAEBAgAGBQJO/gzlAAoJEN2n1gIi5ZPyMJoP/15LI4aelHowMiNQYFzLB2E1
nEAjPHvvHX7uTxLV8BOht9HtoQPpOwyQ/fJm2EIe59NGwjjvlKCdpCrfkfxz3cvV
td0wDuUKrjzQPaACl4cNrGITZLVXe6KtZUKG2o3TjA5dlyqbes5d5F40Mh3j/fB5
L0VZpWNvp0cTrJ6x5QfTkvyQPdxKx0ARaFDQYpvR3uKfgeD28ZNatNCQQuuymLkj
ABVqLzQgVVMinaj/4xXii5vedgYFI58DPWF7r0nmhUaiVvDAEFzfd1MlSvkuI8Jr
EKTQdz3EjMZufRaGxX96rdZvVMEiSTcA/IXNkhis48dOwa4ebfSYm8QpQhp1E6UF
QuJBRXzF9cHvD095Aw+MSqoSR+2LZS3SFBfdB9I5rdxJEoS7LMSJdJLY95dXftqR
KdlcU7ds4kdqaJrnxrxB05SIhgZNq1JcCk9xZyuk7NxsPwl/6ZStr/E/V2mA+bdD
bGWCuP7IKRfZ8cNd01tEYnUppYkfxRaNtYhlNmPVh6TX7rd+2Z4aZLn0anR3Q/J4
2OsPmtIOakk1jW6f41vTOqZ5cpxSv/R1H6fjZAOVACf7UlrtCgVWVLKYofcO/ryS
HMsX1T3m3h9H3heSd76FiXMsgDBaMBkti31FzwnS3pOaZEpHk6eHF/dbR2p0sAbA
gTvG4xDp2MLEtY03Ofhw
=RFiR
-END PGP SIGNATURE-
HI Brandon
Thanks for your response
I totally agree with your first point
Having now used File::Find a little more, I have seen that using opendir
was totally unneccessary and have removed them from the script
And guess what.it works fine without them!
I think that my initial confusion arose from fundamentally misunderstanding
File::Find - thinking that it required a handle, not just a path.
I have also now exchanged the while loop with a foreach loop - much better!
I assume you meant `hexdigest' here, not 'hex digest'.
You assume correctly! Gmail has started to do annoying auto text complete -
I must turn it off!!
push @files, $File::Find::name if -f $_;
This is nice and clean
Your approach is different to what we have been discussing
You seem to gather the files with File::Find and then leave that sub alone
asap
The processing is then done in the results of that gathering
My script left the processing within sub wanted
This could possible be a reason that complications arose so quickly
To get file names and sizes at the same time, I am also considering
my %files;
sub wanted {
my $filesize = (stat($_))[7];
push @{$files{$filesize}}, $File::Find::name;
}
find(\wanted, $path);
to hash files and file size results together - then process after
And yep, Igor
Re: File Size Script Help - Working Version
On Thu, Dec 29, 2011 at 5:08 PM, Igor Dovgiy ivd.pri...@gmail.com wrote:
Hi Jonathan,
Let's review your script a bit, shall we? )
It's definitely good for a starter, but still has some rough places.
#!/usr/bin/perl
# md5-test.plx
use warnings;
use strict;
use File::Find;
use Digest::MD5;
use File::Spec;
So far, so good. )
my $dir = shift || '/Users/jonharris/Documents/begperl';
Nice touch, setting up a default param. ) The name of variable might seem
too generic to some, but then again, it's the only directory we deal with,
so...
my ($dircontents, $path, @directory, $fh, $wr_fh);
Incoming!
Well, it's usually better to declare your variables right before you'll
really need them...
Your script is short, so you'll hardly have a chance to forget what $fh
and $wr_fh mean, though. )
@directory = $dir;
$path = File::Spec-catfile( @directory, $dircontents );
Ahem. At least three 'wtf' moments for me. )
First of all, File::Spec-catfile is really just a glorified join operator
with some additional operations depending on which system you're using.
So, second, it makes a little sense to convert $dir into @directory
(documentation example is just that, an example) and to pass there
undefined $dircontents as well.
But the major one is why you'd ever have to pass your $dir through
File::Spec? It's, you know, user input... )
opendir (my $in, $path) or die Cannot open $dir: $!\n;
So you're trying to open $path, but warn about failure to open $dir? )
But then again, that's a minor quarrel, considering this:
find (\wanted, $path);
See, File::Find is convenient method which _emulates_ the whole
opendir-readdir-closedir pattern for a given directory.
The 'wanted' subroutine (passed by ref) will be called for each file found
in $path.
It's described really well in perldoc (perldoc File::Find).
close $in;
Opendir, but close - and not closedir? Now I'm confused. )
opendir (my $totalin, $path) or die Cannot open $dir: $!\n;
find (\cleanup, $path);
close $totalin;
You don't have to use different variable to store temporary file handle
(which will be closed in three lines) - and that will save you a few
moments spent working out a new (but rational) name for it. :)
But then again, you don't need to open the same dir twice: you can call
cleanup (with the same 'find (\cleanup)... ' syntax) whenever you want.
And you don't really need cleanup... whoops, going too far too soon. :)
print \n\nAll Done!\n\n;
sub wanted {
while ($dircontents = readdir($in)) {
Did I say that you're using two alternative methods of doing the same
thing? )
But there's another big 'no-no' here: you're using external variable
($dircontents) when you really have perfectly zero reasons to do so.
Of course, you don't need to push dirhandle ($in) from outer scape into
this sub, when using find... ($File::Find::dir will do), but that's
explainable at least. )
if ($dircontents=~/^\./ || -d $dircontents) {
next;
}
So now the script ignores all the files which names begin with '.', and
you really wanted just to ignore '.' and '..' ... )
my $bytes = -s $dircontents;
print $dircontents, \n;
print $bytes, bytes, \tSo far so good!\n;
Yes. )
open $fh, , $dircontents or die $!;
open $wr_fh, +, $path $dircontents.md5 or die $!; ## was unable to
concatenate here, hence sub cleanup to remove the ' '
What was wrong with ...
open my $wr_fh, '', File::Spec-catfile($path, $dircontents, '.md5') or
die $!, $/
?
my $hex = Digest::MD5-new-addfile($fh)-hex digest;
print Hex Digest: , $hex, \n\n;
print $wr_fh $hex, \n, $bytes, \n\n;
All looks great for now: you're calculating md5 and size, and writing it
into file with md5 extension...
return($hex);
... but now you're abruptly jumping out of the while block, making the
whole point of cycle, well, completely pointless. Not great.
close $wr_fh;
close $fh;
}
}
# The following is mostly not original code - thanks to the author!
sub cleanup {
my @filelist = readdir($totalin);
foreach my $oldname (@filelist) {
next if -d $oldname;
my $newname = $oldname;
$newname =~ s/\ //;
So you don't have spaces in your filenames. Great for you. )
rename $oldname, $newname;
}
}
# End #
And here we finish.
Computers are not smart. They're dumb. But they're fast. And obedient. )
That's why they're really helpful in letting you do what you're trying to
do... but only if you KNOW what you're trying to do.
Imagine that you're - and not your computer - will be doing this task.
Sit in one place - and write down your program as you (and not your
computer) will be running it. Step by step. Bit by bit.
Then convert your notes into some Perl form - and you'll instantly see the
difference between now and then. )
-- iD
Hi Igor
Many thanks for your response
I have started reviewing the things you said
There are some silly mistakes in there - eg not using closedir
It's a good
re: File Size Script Help - Working Version
Hi All
Firstly, many thanks for your help previously (19/12/11) - it has led to
making a useable script
I don't think it's brilliantly written, it seems a little bodged together
to me... but works fine - not a bad result for a first script
If you are new to this problem and are interested in the previous thread, I
have attached it for you as a text file
I have done everything I can think of now to follow the previous advice
The script is portable, skips directories, creates digests of files, uses
better Perl practice (e.g., no more barewords, correct lexical file handles
etc)
I only have a couple of questions left - wondering if you can help :
- One thing that was recommended was to ensure that the File Handles are
opened outside of the loop
- I really can't figure out how to do this and keep the program working!
Doesn't it need to be inside the loop to be iterated over?
- Also, I had to open two file handles to get addfile()-hexdigest to work
so that the value could be passed - this can't be correct?!
- Writing back was messy - I was struggling with concatenating variables to
keep the script portable
- Is it possible to put values into a hash, and then print each hash entry
to a separate file?
There are clearly better ways to achieve this result - all suggestions are
gratefully received!
Thanks again
Jon
Here's the script:
#
# This program reads in files from a directory, produces a hex digest and
writes the hex, along with
# the file size into a newly created file with the same name and a '.md5'
extension, to the original directory
#!/usr/bin/perl
# md5-test.plx
use warnings;
use strict;
use File::Find;
use Digest::MD5;
use File::Spec;
my $dir = shift || '/Users/jonharris/Documents/begperl';
my ($dircontents, $path, @directory, $fh, $wr_fh);
@directory = $dir;
$path = File::Spec-catfile( @directory, $dircontents );
opendir (my $in, $path) or die Cannot open $dir: $!\n;
find (\wanted, $path);
close $in;
opendir (my $totalin, $path) or die Cannot open $dir: $!\n;
find (\cleanup, $path);
close $totalin;
print \n\nAll Done!\n\n;
sub wanted {
while ($dircontents = readdir($in)) {
if ($dircontents=~/^\./ || -d $dircontents) {
next;
}
my $bytes = -s $dircontents;
print $dircontents, \n;
print $bytes, bytes, \tSo far so good!\n;
open $fh, , $dircontents or die $!;
open $wr_fh, +, $path $dircontents.md5 or die $!; ## was unable to
concatenate here, hence sub cleanup to remove the ' '
my $hex = Digest::MD5-new-addfile($fh)-hex digest;
print Hex Digest: , $hex, \n\n;
print $wr_fh $hex, \n, $bytes, \n\n;
return($hex);
close $wr_fh;
close $fh;
}
}
# The following is mostly not original code - thanks to the author!
sub cleanup {
my @filelist = readdir($totalin);
foreach my $oldname (@filelist) {
next if -d $oldname;
my $newname = $oldname;
$newname =~ s/\ //;
rename $oldname, $newname;
}
}
# End #
Jonathan Harris
Dec 19 (10 days ago)
to beginners, me
Hi Perl Pros
This is my first call for help
I am a totally new, self teaching, Perl hopeful
If my approach to this script is simply wrong, please let me know as it will
help my learning!
The script aims to:
1) Read in a directory either from the command line, or from a default path
2) Produce a hash for future checksum
3) Write this (hex digest) to a separate file, in a sub directory of the
parent, which has the same name and a .md5 extension
4) Check the original file for its size
5) Add this data to the newly created file on a new line (in bytes)
I have a script that will do most of this, except for analysing the file size -
I think that the file size being analysed may be the md5 object result as the
same value is printed to each file
I am running out of ideas and would appreciate any help you could give!
I have tried using File::stat::OO and File::stat - but to no avail - I could
be using them incorrectly!
Many thanks in advance...
Jon.
Here are some details:
System:
Mac OSX 10.7.2
Perl version 5.12
Script:
#!/usr/bin/perl
# md5-test-3.plx
use warnings;
use strict;
use Digest::MD5;
my $filesize = 0;
my $dir = shift || '/Users/jonharris/Documents/begperl';
opendir (DH, $dir) or die Couldn't open directory: $!;
my $md5 = Digest::MD5-new;
while ($_ = readdir(DH)) {
$md5-add($_);
$filesize = (stat(DH))[7];
Is it necessary to put the following into a new loop?
foreach ($_) {
open FH, /Users/jonharris/Documents/begperl/md5/$_.md5 or
die $!;
binmode(FH);
print FH $md5-hexdigest, \n, $filesize;
}
close FH;
}
close DH;
print \n$dir\n\n;
###
Jim Gibson via perl.org
Dec 19 (10 days ago)
to beginners
On 12/19/11 Mon Dec 19, 2011 11:32 AM, Jonathan Harris
jtnhar...@googlemail.com scribbled:
Hi Perl Pros
This is my first call for help
I am a totally new, self teaching, Perl hopeful
If my approach to this script is simply wrong, please let me know as it
will help my learning
Re: File Size Script Help - Working Version
On Thu, Dec 29, 2011 at 6:39 PM, John W. Krahn jwkr...@shaw.ca wrote: Jonathan Harris wrote: Hi Igor Many thanks for your response I have started reviewing the things you said There are some silly mistakes in there - eg not using closedir It's a good lesson in script vigilance I found the part about opening the file handle particularly interesting I had no idea that open my $wr_fh, '', File::Spec-catfile($path, $dircontents, '.md5') or die $!, $/ was possible Now it's time to sit down and digest all this..and rewrite the script to make it better! Igor made a lot of good points. Here are my two cents worth. You are using the File::Find module to traverse the file system and add new files along the way. This _may_ cause problems on some file systems. It would probably be better to get a list of applicable files first and then use that list to create your new files. And you should have some way to handle the situation where a file exists that already has an '.md5' file or an '.md5' file exists with no corresponding plain file. John -- Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction. -- Albert Einstein -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/ Hi John Thanks for your 2 cents I hadn't considered that the module wouldn't be portable If that is the case, then maybe it would be best to ditch File::Find altogether? Have you had experience with the module causing issues on certain systems? It would be a shame, as I've just got it working! - Thanks to Igor, I no longer use the unnecessary dir handles! I agree that it may be worth examining the directory for existing .md5 files and skipping them I'll look in to adding that in to the code All the best and thanks for your help Jonathan
Re: File Size Script Help - Working Version
On Fri, Dec 30, 2011 at 12:33 AM, Jonathan Harris
jtnhar...@googlemail.comwrote:
On Thu, Dec 29, 2011 at 6:39 PM, John W. Krahn jwkr...@shaw.ca wrote:
Jonathan Harris wrote:
Hi Igor
Many thanks for your response
I have started reviewing the things you said
There are some silly mistakes in there - eg not using closedir
It's a good lesson in script vigilance
I found the part about opening the file handle particularly interesting
I had no idea that
open my $wr_fh, '', File::Spec-catfile($path, $dircontents, '.md5') or
die $!, $/
was possible
Now it's time to sit down and digest all this..and rewrite the script
to make it better!
Igor made a lot of good points. Here are my two cents worth. You are
using the File::Find module to traverse the file system and add new files
along the way. This _may_ cause problems on some file systems. It would
probably be better to get a list of applicable files first and then use
that list to create your new files. And you should have some way to handle
the situation where a file exists that already has an '.md5' file or an
'.md5' file exists with no corresponding plain file.
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Hi John
Thanks for your 2 cents
I hadn't considered that the module wouldn't be portable
If that is the case, then maybe it would be best to
ditch File::Find altogether?
Have you had experience with the module causing issues on certain systems?
It would be a shame, as I've just got it working! - Thanks to Igor, I no
longer use the unnecessary dir handles!
I agree that it may be worth examining the directory for existing .md5
files and skipping them
I'll look in to adding that in to the code
All the best and thanks for your help
Jonathan
Hi All
Final question for Igor
I tried to use your suggestion
open my $wr_fh, '', File::Spec-catfile($path, $dircontents, '.md5') or
die $!, $/
but it returned an error on the command line:
'Not a directory'
At which point the program dies (which is what it is supposed to do!)
I used it inside the loop - sorry to bug you for clarification
if ($dircontents=~/^\./ || -d $dircontents) {
next;
}
This is also to avoid the file .DS_Store
#
FInally, I was advised by a C programmer to declare all variables at the
start of a program to avoid memory issues
Is this not necessary in Perl?
The rest of it is going really well - hope to post new and improved code
soon!
re: File Size Script Help
Hi Perl Pros
This is my first call for help
I am a totally new, self teaching, Perl hopeful
If my approach to this script is simply wrong, please let me know as it
will help my learning!
The script aims to:
1) Read in a directory either from the command line, or from a default path
2) Produce a hash for future checksum
3) Write this (hex digest) to a separate file, in a sub directory of the
parent, which has the same name and a .md5 extension
4) Check the original file for its size
5) Add this data to the newly created file on a new line (in bytes)
I have a script that will do most of this, except for analysing the file
size - I think that the file size being analysed may be the md5 object
result as the same value is printed to each file
I am running out of ideas and would appreciate any help you could give!
I have tried using File::stat::OO and File::stat - but to no avail - I
could be using them incorrectly!
Many thanks in advance...
Jon.
Here are some details:
System:
Mac OSX 10.7.2
Perl version 5.12
Script:
#!/usr/bin/perl
# md5-test-3.plx
use warnings;
use strict;
use Digest::MD5;
my $filesize = 0;
my $dir = shift || '/Users/jonharris/Documents/begperl';
opendir (DH, $dir) or die Couldn't open directory: $!;
my $md5 = Digest::MD5-new;
while ($_ = readdir(DH)) {
$md5-add($_);
$filesize = (stat(DH))[7];
Is it necessary to put the following into a new loop?
foreach ($_) {
open FH, /Users/jonharris/Documents/begperl/md5/$_.md5 or die $!;
binmode(FH);
print FH $md5-hexdigest, \n, $filesize;
}
close FH;
}
close DH;
print \n$dir\n\n;
###
Re: File Size Script Help
On Mon, Dec 19, 2011 at 8:08 PM, Jim Gibson jimsgib...@gmail.com wrote:
On 12/19/11 Mon Dec 19, 2011 11:32 AM, Jonathan Harris
jtnhar...@googlemail.com scribbled:
Hi Perl Pros
This is my first call for help
I am a totally new, self teaching, Perl hopeful
If my approach to this script is simply wrong, please let me know as it
will help my learning!
The script aims to:
1) Read in a directory either from the command line, or from a default
path
2) Produce a hash for future checksum
A hash of what? File names (directory contents) or file contents?
3) Write this (hex digest) to a separate file, in a sub directory of the
parent, which has the same name and a .md5 extension
Same name as the file or same name as the directory?
4) Check the original file for its size
5) Add this data to the newly created file on a new line (in bytes)
Will this file contain information for one file or many files?
I have a script that will do most of this, except for analysing the file
size - I think that the file size being analysed may be the md5 object
result as the same value is printed to each file
Print out the file size returned by stat. Check if it is the same displayed
by the ls command.
I am running out of ideas and would appreciate any help you could give!
I have tried using File::stat::OO and File::stat - but to no avail - I
could be using them incorrectly!
I am afraid I do not understand exactly what you are trying to accomplish.
I
can't tell from your program whether or not you will end up with one digest
file for the entire directory, or one digest file for each file in the
directory.
Many thanks in advance...
Jon.
Here are some details:
System:
Mac OSX 10.7.2
Perl version 5.12
Script:
#!/usr/bin/perl
# md5-test-3.plx
use warnings;
use strict;
use Digest::MD5;
my $filesize = 0;
You should declare variables where they are needed and not before.
my $dir = shift || '/Users/jonharris/Documents/begperl';
opendir (DH, $dir) or die Couldn't open directory: $!;
my $md5 = Digest::MD5-new;
while ($_ = readdir(DH)) {
You are better off using a scalar variable and not the default variable,
which can get reused and overwritten:
while( my $file = readdir(DH) ) {
$md5-add($_);
You are adding file names to a string to be digested. Is that what you
want? Or do you want to calculate a digest for the contents of each file?
I have not used Digest::MD5, but if you to calculate the digest for the
contents of each file, you want to create a new digest object, open the
file, and use the addfile() method, then hexdigest() for each file.
$filesize = (stat(DH))[7];
You are applying stat to the directory read handle. You want to fetch data
for the file (untested):
my $filesize = (stat($dir/$file))[7];
Note that you must prefix the file name with its full path.
Is it necessary to put the following into a new loop?
No. It makes no sense to have a one-iteration loop.
foreach ($_) {
open FH, /Users/jonharris/Documents/begperl/md5/$_.md5 or die $!;
You are appending lines to a file with a name that is based on an existing
file. Why?
binmode(FH);
There is no need to set the mode of the output file to binary. Both
hexdigest and the file size will be written in ascii characters, not binary
data.
print FH $md5-hexdigest, \n, $filesize;
}
close FH;
}
close DH;
print \n$dir\n\n;
###
--
To unsubscribe, e-mail: beginners-unsubscr...@perl.org
For additional commands, e-mail: beginners-h...@perl.org
http://learn.perl.org/
Hi Jim
Thanks for responding
Here are some answers to your questions:
A hash of what? File names (directory contents) or file contents?
The aim is to produce a digest for each file in the folder
Same name as the file or same name as the directory?
Each file created will have the same filename as the original, but with the
extension '.md5'
Will this file contain information for one file or many files?
This file will contain information for only one file
This is so that when looking at the treated directory, the end result will
be:
some_movie.mov
some_movie.mov.md5
another_movie.mov
another_movie.mov.md5
etc...
Print out the file size returned by stat. Check if it is the same
displayed
by the ls command.
I really have! However, this is where I am coming unstuck
I am afraid I do not understand exactly what you are trying to
accomplish. I
can't tell from your program whether or not you will end up with one
digest
file for the entire directory, or one digest file for each file in the
directory.
The program creates one digest file for each file in the directory : )
my $filesize = 0;
You should declare variables where they are needed and not before.
Noted
my $md5 = Digest::MD5-new;
while ($_ = readdir(DH)) {
You are better off using a scalar variable and not the default variable
Re: File Size Script Help
On Mon, Dec 19, 2011 at 8:09 PM, Shlomi Fish shlo...@shlomifish.org wrote:
Hi Jonathan,
some comments on your code - both positive and negative.
On Mon, 19 Dec 2011 19:32:10 +
Jonathan Harris jtnhar...@googlemail.com wrote:
Hi Perl Pros
This is my first call for help
I am a totally new, self teaching, Perl hopeful
If my approach to this script is simply wrong, please let me know as it
will help my learning!
The script aims to:
1) Read in a directory either from the command line, or from a default
path
2) Produce a hash for future checksum
3) Write this (hex digest) to a separate file, in a sub directory of the
parent, which has the same name and a .md5 extension
4) Check the original file for its size
5) Add this data to the newly created file on a new line (in bytes)
I have a script that will do most of this, except for analysing the file
size - I think that the file size being analysed may be the md5 object
result as the same value is printed to each file
I am running out of ideas and would appreciate any help you could give!
I have tried using File::stat::OO and File::stat - but to no avail - I
could be using them incorrectly!
Many thanks in advance...
Jon.
Here are some details:
System:
Mac OSX 10.7.2
Perl version 5.12
Script:
#!/usr/bin/perl
# md5-test-3.plx
use warnings;
use strict;
strict and warnings are good.
use Digest::MD5;
So is using a module.
my $filesize = 0;
You shouldn't predeclare your variables.
my $dir = shift || '/Users/jonharris/Documents/begperl';
opendir (DH, $dir) or die Couldn't open directory: $!;
Don't use bareword dir handles - use lexical ones. It's good that you're
using
the or die thing, though.
my $md5 = Digest::MD5-new;
Seems like you're using the same $md5 object times and again which will
calculate cumulative MD5 sums instead of per-file ones.
while ($_ = readdir(DH)) {
1. You're not skipping . and ...
2. You're not skipping other directories.
3. The $_ variable can be easily devastated. You should use a lexical one.
$md5-add($_);
According to http://metacpan.org/module/Digest::MD5 the add() methods
adds
data, and here it will only add the filename. You need to use addfile()
with an
opened file handle instead.
$filesize = (stat(DH))[7];
You shouldn't stat the directory handle. Instead stat $dir/$filename
(you can
also use the core File::Spec module if you want to make it extra portable).
Is it necessary to put the following into a new loop?
foreach ($_) {
Why the foreach ($_) here? It does nothing. You're already iterating on the
files.
open FH, /Users/jonharris/Documents/begperl/md5/$_.md5 or die $!;
binmode(FH);
print FH $md5-hexdigest, \n, $filesize;
}
close FH;
Use lexical file handles here, use three-args open - «open my $fh, '',
'/Users'» and don't open it time and again. Keep it outside the loop.
For more information see:
http://perl-begin.org/tutorials/bad-elements/
Regards,
Shlomi Fish
}
close DH;
print \n$dir\n\n;
###
--
-
Shlomi Fish http://www.shlomifish.org/
Chuck Norris/etc. Facts - http://www.shlomifish.org/humour/bits/facts/
We don’t know his cellphone number, and even if we did, we would tell you
that
we didn’t know it.
Please reply to list if it's a mailing list post - http://shlom.in/reply .
Hi Shlomi
Thanks for your response
To answer your questions:
my $filesize = 0;
You shouldn't predeclare your variables
Noted, thanks
my $dir = shift || '/Users/jonharris/Documents/begperl';
opendir (DH, $dir) or die Couldn't open directory: $!;
Don't use bareword dir handles - use lexical ones. It's good that you're
using
the or die thing, though.
Of course - will have to re-read the section on barewords...
my $md5 = Digest::MD5-new;
Seems like you're using the same $md5 object times and again which will
calculate cumulative MD5 sums instead of per-file ones.
In which case, I think that it will have to go in the loop so that a new
instance is produced each time?
while ($_ = readdir(DH)) {
1. You're not skipping . and ...
2. You're not skipping other directories.
I'm sure I read somewhere, that the parent was automatically skipped
Must be getting confused
However, adding this will be ok:
next if $_ eq . or $_ eq ..;
3. The $_ variable can be easily devastated. You should use a lexical one.
I'll certainly use lexical in the future
$md5-add($_);
According to http://metacpan.org/module/Digest::MD5 the add() methods
adds
data, and here it will only add the filename. You need to use addfile()
with an
opened file handle instead.
That makes sense
$filesize = (stat(DH))[7];
You shouldn't stat the directory handle. Instead stat $dir/$filename
(you can
also use the core File::Spec module if you want to make
Re: practical perl guides
On Fri, May 27, 2011 at 1:00 PM, Sayth Renshaw flebber.c...@gmail.comwrote: On Fri, May 27, 2011 at 9:12 PM, Leo Lapworth l...@cuckoo.org wrote: Hi, On 27 May 2011 10:26, Shlomi Fish shlo...@iglu.org.il wrote: On Friday 27 May 2011 09:35:32 Sayth Renshaw wrote: Which Perl Should I use ActivePerl or Strawberry Perl on Windows? 5.10 or 5.12? Definitely Strawberry Perl: it is free-as-in-beer, open-source, free-as-in- speech, community-driven, http://www.youtube.com/watch?v=1RHYPM6e55o shows the steps (although 5.12.3 is out so I must updated that). and allows you to install stuff from CPAN without having to resort to a lot of proprietary and costly software from Microsoft. ActiveState claim to now includes all the build code automatically or via PPM (MiniGW / dmake) so you don't need to buy anything from Microsoft. You can use their PPM modules (already compiled) but the cpan install tool will also build from scratch. You should make use of the latest version of perl 5 available for it - namely 5.12.x , as 5.10.x was recently end-of-lifed, and there's now perl-5.14.x. At the moment I'd recommend Strawberry Perl Professional (from http://strawberryperl.com/beta/) even though it is 5.10 because it has lots of extra CPAN modules (the ones with tricky install issues) included, I've been told a Pro version for 5.12 is being worked on and should be available in a few weeks. 5.14 is being worked on for Strawberry - but my understanding is that won't have the 'Pro' version for quite a while (unless someone wants to volunteer to help). Cheers Leo -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/ Thanks for the tip especially about strawberry professional, I had been watching Padre fail too install for the past hour or so on 5.12 and its installed and working by default now. Sayth -- To unsubscribe, e-mail: beginners-unsubscr...@perl.org For additional commands, e-mail: beginners-h...@perl.org http://learn.perl.org/ Hi I recommend the book, Beginning Perl, by Simon Cozens I'm a total newbie to programming and am finding it clear and instructional It really does This is feature X - this is an impractical (or not) example of using feature X. Jon
