in reply to Re: grep confusion
in thread grep confusion

I did finally get the grep to work as expected thanos1983, again, like I mentioned above, I'm begining to think my environment for perl is causing gremlins, I may fire up an old windows xp machine by itself to do my testing on, I'm begining to think the virtual machine's limitations are being exceeded... previously correct/good/executable lines in my code that worked before I kept adding more script are starting to throw errors... thanx again everyone for your guidance, maybe someday I can actually help someone else *heh*
-Gary

I tried re-inventing the wheel again, but everytime I push it, it still falls flat on it's side...

Replies are listed 'Best First'.
Re^3: grep confusion
by PriNet (Monk) on Sep 03, 2017 at 07:41 UTC
    I believe I found out what's causing my 'arbitrary' errors (they only happen sometimes). So here's an update and I welcome any resolutions anyone may have:
    I use pdf2text to convert some (work) files to an xls worksheet
    everything was going fine until I wrote in an 'opportunity' to edit the XLS file before continuing on with my script.
    I use Spreadsheet::WriteExcel; to create the initial XLS (works fine)
    I then use
    system('C:/Progra~1/OpenOf~1/Program/Scalc "'.$CurrentDirectory.'/Resources/'.$Filename.'"');
    (which also works fine) to start OpenOffice for the 'editing' option
    then directly after that I (using)
    use Spreadsheet::ParseExcel::SaveParser;
    start reading the file with the line:
    $XlsWorkbook = Spreadsheet::ParseExcel::SaveParser->new()->Parse($CurrentDirectory.'/Resources/'.$Filename);
    to 'reload' the file to update my 'optional' changes...
    I am under the impression (because it only happens 'sometimes') that when I close the file in OpenOffice, my script does not 'wait' long enough for the file to completely close in OpenOffice... thus I end up trying to read cells that haven't been defined yet because OpenOffice hasn't finished closing the file.
    I am (of course) going to play with 'sleep' to see if I can slow things down in my script, but, I read in several places that 'sleep' is kinda dangerous in scripts.
    Here's the question: is there a way to tell when OpenOffice has actually completed the close operation before trying to read the file again ?
    I have looked around and found that the 'system' command I use can be modified for different actions and found this:
    system(`nmon -F file.out -s3 -c1`);
    I'm not fluent with the 'system' command and I can't seem to find much information on 'system' command options on the net, should i attempt to play around with this suggestion to see if I can make it work ? -or- is there a module somewhere that I can use to 'watch' OpenOffice' and ensure the XLS file has completely finished/closed/saved before trying to read in the 'changes'?
    I REALLY hope I explained things well enough here. I'll be holding a tin can out for anyone's two-bits...

    I tried re-inventing the wheel again, but everytime I push it, it still falls flat on it's side...
[reply]
[d/l]
[select]

      PriNet:

      You could use stat to get the file modification time, and then sit in a loop waiting for the file modification time to change:

      $ cat pm_1198604.pl
use strict;
use warnings;

system("touch FName.dat");
my $ctime = (stat 'FName.dat')[10];

# Proxy for your spreadsheet update...
system("(sleep 10; date; touch FName.dat) &");

my $timeout = time + 60;    # Don't wait forever!

while (1) {

    # File changed yet?
    my $new_ctime = (stat 'FName.dat')[10];
    last if $new_ctime > $ctime;

    die "TIMEOUT!" if time > $timeout;

    print "still unchanged, waiting a little while\n";
    sleep 2;
}

print ".. continuing to next chunk of work\n";

$ perl pm_1198604.pl
still unchanged, waiting a little while
still unchanged, waiting a little while
still unchanged, waiting a little while
still unchanged, waiting a little while
still unchanged, waiting a little while
still unchanged, waiting a little while
Sun, Sep  3, 2017 11:35:11 AM
.. continuing to next chunk of work

      [download]

      ...roboticus

      When your only tool is a hammer, all problems look like your thumb.

[reply]
[d/l]
        'Apparently', Spreadsheet::ParseExcel::SaveParser has issues 'editing' existing XLS files:

        "An Excel file is a binary file within a binary file. It contains several interlinked checksums and changing even one byte can cause it to become corrupted"
        -https://groups.google.com/forum/#!topic/spreadsheet-writeexcel/FeEx0vXQErQ

        I believe I am going to have to 'rewrite' the 'optional changes after creation' section of my program to read in the existing XLS with Spreadsheet::ParseExcel then 'recreate' a new copy of the XLS with Spreadsheet::WriteExcel and then overwrite the previous XLS with this new 'modified' copy. I'll post my results when I get this rewritten...(I did notice that 'irronius' errors appear more-so when I tried modifying a cell)

        Has anyone seen this sliced bread thing? I's better than... sliced... well... never mind...
[reply]
[d/l]
[select]
        excellent idea, let me try implementing that concept and see if 'timing' is really the issue... yuppers, that's a good idea...

        I tried re-inventing the wheel again, but everytime I push it, it still falls flat on it's side...
[reply]

In Section Seekers of Perl Wisdom