Re: IF condition that doesnt work

[vitoco]

My problem its when i need to check the line using ReGex, i have the check if the lines named (hwUserField7) exists, and if dont, it must use the data store in hwUserField3 to look for in the has i had readed from the file, then must write the value referenced from this key in the hash as a new line. My problem its i dont able to put into the if contition of the flag to check if exists the line.

Please note that in your code, the conditions use "hwAssetUserField7" and "hwAssetUserField3".

Also, you are reading that XML file line by line and testing each for the whole pattern "<tag>data</tag>". Is it possible that the opening tag to be in one line of the file and the closing tag to be in another? Then you should slurp the entire file and then perform the IFs.

BTW, if both matching tags are always in the same line, you can use if (cond3) {...} elsif (cond7) {...}.

Instead of uncompressing->processing->recompressing files, I would open files through a pipe, to get data uncompressed on the fly, and do the same to the output:

open(LEEXML, "7z.exe e -so $tmp5|") or die;

open(ESCRIBEXML, "|7z.exe a -si -tgzip $xml_out") or die;

It will save space on disk, but I'm not sure if this performs.

[Tanktalus]

It will save space on disk, but I'm not sure if this performs.

Slightly off-topic, but it generally will perform much better, at least once you get past the threshold of launching another process (perhaps using PerlIO::gzip would eliminate that). That's because, in general, the amount of CPU time it takes to decompress something is miniscule relative to the amount of time it takes to read the uncompressed information from disk. That is, reading compressed data plus the CPU overhead of decompressing that data is a fraction of the time required to read the data if it weren't compressed, because disks are so slow.

Note that there are a few assumptions here: a) the amount of space saved by compression is significant (1% compression may not be a big deal, but 50%+ is), b) there are spare CPU cycles on the system, i.e., you're idling while waiting for the disk to catch up (a heavily used server that does a lot of CPU crunching may not qualify), c) traditional disks are used, i.e., disks with moving parts (SSD may, or may not, change this equation, though the cost of the storage space may be a different factor in favour of compression). Since all of these assumptions hold most of the time, I use the term "generally will" above instead of merely "can".

[Sombrerero_loco]

Thanks for the tip, i'll implement that in my future codes, i don't know this can be possible. Also, for this piece of code is not necessary,because i only need to do that once a month as a scheduled task on a 8cpu SCSI RAID drives server (i dont care if this takes a lot of time, this server has this time to waste :) ) Also, i fix this problem using another aproximation: If i found condition 6, it write condition 6 and 7, and when i found condition 7, i trash it, because i wrote a cycle before. Smart, isnt? :) Thanks for all indeed, now i have another weird case with quotes. Im gonna open a new post.