in reply to Re^7: How best to strip text from a file?
in thread How best to strip text from a file?
Wow... that's awesome! Thank you VERY much!
Worked great on my Windows test box using ActivePerl... but I get compile errors on the 'Nix server that I need to run it on (am only a tenant, not an admin etc. so no option of upgrading)... so I strongly suspect I'm coming across Perl versioning issues. Version on the server is "This is perl, v5.8.8 built for sun4-solaris" - which I suspect isn't compatible with something you've used in this script?
Bareword found where operator expected at real_test.pl line 44, near " +/= do { /Order" (Missing operator before Order?) Use of /c modifier is meaningless without /g at real_test.pl line 45. Bareword found where operator expected at real_test.pl line 45, near " +/= do { /cycle" (Missing operator before ycle?) Bareword found where operator expected at real_test.pl line 46, near " +/= do { /Vendor" (Missing operator before Vendor?) syntax error at real_test.pl line 44, near "/= do { /Order ID" syntax error at real_test.pl line 45, near "/= do { /cycle" syntax error at real_test.pl line 46, near "/= do { /Vendor ID" Unmatched right curly bracket at real_test.pl line 46, at end of line syntax error at real_test.pl line 46, near "$1 }" real_test.pl had compilation errors.
Note - this compiles and runs without issue on ActivePERL on my PC, as I'm sure it did on yours///
Any suggestions on reading I should do to work out how best to fit this into the version of Perl on the server?
Sorry to be a pain... you're being extremely helpful, and I'm being nothing but more problems lol
|
---|
Replies are listed 'Best First'. | |
---|---|
Re^9: How best to strip text from a file?
by Kenosis (Priest) on Nov 09, 2012 at 06:02 UTC | |
You're very welcome--and not a pain nor more problems! It was actually quite fun to work on and am glad it's working for you. I think you're correct about the reason why the defined-or-equals (//=) throws an error on your *nix box. I believe that the operator was introduced in v5.10. You can recode each of the //= lines as follows: This:
Can be written as:
Again, let me know if you have any more questions about this script... | [reply] [d/l] [select] |
by bobdabuilda (Beadle) on Nov 13, 2012 at 00:06 UTC | |
That certainly did the trick!! Nice one. So now, I've been playing around with the logic behind skipping duplicated orders within the file... and of course, having issues with it... Using the same script and data, and keeping in mind that orders, if duplicated, will always (I'm pretty certain) be duplicated in order - ie. an order will be replicated 3 or 4 or more times, and then the report moves on to a different order. Sorry for the long bit of code here, but figured it easiest to show you what I'm trying :
Now, when I run this, somehow $previousOrder is getting a value in it at the "if" logic check, even though the logic check is the first time the variable is seen after it's initialised as ""... as you can see from the output of the first print command. The other thing I don't understand from this outcome, is that the resultant XLS file has only 2 fields (as well as the headers) written to it - the fiscal year and PO number. I would have thought that, if it made it to the section that writes the PO stuff at all, it would write it all - I don't understand how it can only write part of it? There's also an issue with the XLS file itself for some reason - giving an error when opening it... but I'm off to research that one myself now while I wait for suggestions on what I've stuffed up with my logic for the duplication check :) | [reply] [d/l] |
by Kenosis (Priest) on Nov 13, 2012 at 02:35 UTC | |
Hi, bobdabuilda! Am glad this is shaping up for you, and I think you've done well building on to this... Here are a few items for you to consider... Use another hash to keep track of previously-seen Orders. Without re-posting the entire code, here's what you can add to make this functional: Add a %seen hash:
Add a RECORD: label at the start of the line, in front of the for that iterates through each record (Order):
Finally, use an if() statement to process the Order ID (instead of a single line like with the other fields):
I suspect you can see what this does, but if an Order ID: match is found, it first checks to see if the ID's already been 'seen.' If so, it gets the next record for processing, else it tags the Order as seen and sets the hash. Write to your Excel file from within your subroutine. 1) You've got a complete record by the time the subroutine is called in the script (see its current position). You can send your subroutine the row number:
Then, in the subroutine:
2) By writing to the Excel spread sheet from within the subroutine, you're somewhat modularizing your program by keeping its functionality separate. Let me know how your spread sheet writing is going or if you encounter any other issues... | [reply] [d/l] [select] |
by bobdabuilda (Beadle) on Nov 13, 2012 at 03:54 UTC | |
by Kenosis (Priest) on Nov 13, 2012 at 04:30 UTC | |
| |
by bobdabuilda (Beadle) on Nov 13, 2012 at 00:26 UTC | |
Just wanting to add that I found the issue with the XLS file is related to cells being written to twice in the code (according to the WriteExcel author id:710537 - check the link later on in the thread by him pointing to the Google Groups thread). So I went hunting, added an extra $row+=1 in early on in the piece in order to see what's going on... and it appears that my duplicate logic is working, to a point - with the additional line increasing my row number, I now get still just the Year and PO number - but I am getting one each for each of the PO's in the DATA. I put an extra few duplicates of the same data in to check - and still only got one copy of each of the Year and PO's... so I guess that's kinda a good thing. Now just need to work out why it's skipping the rest, so now I'm off to go about pulling it apart again to try and work this out... Scarily, I think I'm starting to enjoy this... lol | [reply] |
by bobdabuilda (Beadle) on Nov 13, 2012 at 01:51 UTC | |
Alright! Getting somewhere. Worked out part of the issue was based around the location of the WriteExcel block set up to write the Order details - placed it inside the "if (/Distribution--/) {" loop, and it sorted that issue out nicely. Makes sense now that I look back on it, as AFTER that distribution matches, it's finished processing all of the Order header fields - whereas prior to that, the first few times it hit the WriteExcel stuff, it was only partially processed. So, now it's trimming the Order list down nicely. TOO nicely. On looking back over the data, I noticed that each order had potential of having more than one title - so I was skipping data that should be kept. So, added in another check on the title, and that's not behaving as expected... of course... With this latest version, and the example data provided, the output I am expecting is 2 order entries for PC-9999, and 1 for PC-1111. 2 entries for the first, because there are 3 entries, but 2 of those 3 are duplicates (3rd one I added a "2" onto the title to make it different). However, it's only printing out one order for each... and I can't work out why... Any suggestions on how to track the issue down please?
| [reply] [d/l] |
by Kenosis (Priest) on Nov 13, 2012 at 02:46 UTC | |
...each order had potential of having more than one title... What do multiple titles look like in an Order? | [reply] |