Wiggins d'Anconia wrote:
> Tommy Nordgren wrote:
>>
>> Oct 26, 2005 kl. 7:56 PM skrev Wiggins d'Anconia:
>>
>>> Tommy Nordgren wrote:
>>>
>>>>
>>>> Oct 25, 2005 kl. 6:21 AM skrev Pant, Hridyesh:
>>>>
>>>>
>>>>> Hi All,
>>>>> How to extract zip file using perl program...
>>>>>
Use the Perl Modules:
Use Archive::Zip::Tree and
Archive::Zip qw( :ERROR_CODES, :CONSTANTS )
I have a two scripts which I run every couple of weeks to move data
from one folder to another depending on whehter it is a daily, weekly or
monthly process. After the first script completes, I run my second one which
generates arhives for the data using the date for a particular files as the
arhive. After I have archive everything, I then make a second pass verifying
that the count in the arhive and what I thought I was archiving are the same.
As I am doing this then I delete the source files. I have anywhere from 150 to
250 meg of data arhived from my processing.
I never shell out and it has been running a number of years with no
problems. Under the current Windows XP, you can enter the arhive like it was
folder and then pull if necessary any files you need.
Wags ;)
>>>>> Thanks
>>>>> Hridyesh
>>>>>
>>>>> -- To unsubscribe, e-mail: [EMAIL PROTECTED]
>>>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>>>> <http://learn.perl.org/> <http://learn.perl.org/first-response>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>> system '/usr/bin/unzip',@OPTIONS,$zipfile;
>>>>
>>>>
>>>
>>> Time for me to rant about how the above is unacceptable for anything
>>> other than a one off script. Shelling out using 'system' or
>>> backticks is a last resort and should be used with care and the
>>> proper precautions
>>>
>>
>> Calling system with multiple paramaters don't 'shell out' as you
>> call it.' It launches the tool in question directly, bypassing the
>> shell entirely. The main security concern of calling accientally a
>> trojan horse earlier in the users path, don't apply when using the
>> array form of system, with an absolute search path
>>
>
> Ok, fork/exec'ing, technically you are correct, the shell doesn't get
> a chance to re-interpret the command line. You are also correct that
> you avoid a trojan horse when someone places something earlier in the
> path, of course there is nothing to say that /usr/bin/unzip isn't a
> trojan horse itself, assuming it exists at all. Regardless the above
> code still doesn't catch a missing executable, no permissions to run
> said executable, or errors thrown by that executable, or on the flip
> side that it was actually successful. Though I haven't benchmarked
> it, for common practices shelling out is generally also slower than
> its native Perl bretheren, and of course portability falls all to
> pieces.
>
> So for proper applications something like Archive::Zip would be
> significantly better from interface, security, portability, and
> efficiency standpoints.
>
> http://danconia.org
>
>>
>>> taken. The above lacks proper error handling, security safe guards,
>>> and is inefficient and non-portable.
>>>
>>> So the ML archives for further discussion of how to properly shell
>>> out...
>>>
>>> http://danconia.org
>>>
>>> --
>>> To unsubscribe, e-mail: [EMAIL PROTECTED]
>>> For additional commands, e-mail: [EMAIL PROTECTED]
>>> <http://learn.perl.org/> <http://learn.perl.org/first-response>
>>>
>>>
>>>
>>
>> -------------------------------------
>> This sig is dedicated to the advancement of Nuclear Power
>> Tommy Nordgren
>> [EMAIL PROTECTED]
*******************************************************
This message contains information that is confidential
and proprietary to FedEx Freight or its affiliates.
It is intended only for the recipient named and for
the express purpose(s) described therein.
Any other use is prohibited.
*******************************************************
--
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
<http://learn.perl.org/> <http://learn.perl.org/first-response>
