[28051] in Perl-Users-Digest
Perl-Users Digest, Issue: 9415 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jul 1 18:05:53 2006
Date: Sat, 1 Jul 2006 15:05:06 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sat, 1 Jul 2006 Volume: 10 Number: 9415
Today's topics:
Re: "Inappropriate ioctl for device" while upload()ing <noreply@gunnar.cc>
Re: "Inappropriate ioctl for device" while upload()ing latin0511@gmail.com
Re: "Inappropriate ioctl for device" while upload()ing <1usa@llenroc.ude.invalid>
Re: "Inappropriate ioctl for device" while upload()ing <noreply@gunnar.cc>
Re: Does recursive call able to print in same page as m <ermeyers@adelphia.net>
Re: Does recursive call able to print in same page as m <ynleder@nspark.org>
Re: Does recursive call able to print in same page as m <tadmc@augustmail.com>
Re: Does recursive call able to print in same page as m <ermeyers@adelphia.net>
Re: Does recursive call able to print in same page as m <ynleder@nspark.org>
Re: Does recursive call able to print in same page as m <ynleder@nspark.org>
Re: Does recursive call able to print in same page as m <ermeyers@adelphia.net>
Re: Extract gzip Files <paul.marquess@btinternet.com>
Re: Extract gzip Files <mikeflan@earthlink.net>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 01 Jul 2006 20:21:06 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: "Inappropriate ioctl for device" while upload()ing using CGI.pm
Message-Id: <4gnssgF1np0crU1@individual.net>
latin0511@gmail.com wrote:
> I'm using the procedural upload() function from CGI.pm.
> In this line:
> my $fd_file = upload( 'file' ) or die( "upload() ( $! )" );
What makes you think that $! contains an appropriate error message if no
file is uploaded?
> I encounter the weird-looking error:
> "Inappropriate ioctl for device".
>
> I don't understand what could be the problem. I did exactly like they
> say in the manual.
> Can you please help me solve this problem?
Use the CPAN module CGI::UploadEasy.
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: 1 Jul 2006 14:14:19 -0700
From: latin0511@gmail.com
Subject: Re: "Inappropriate ioctl for device" while upload()ing using CGI.pm
Message-Id: <1151788459.077665.212490@v61g2000cwv.googlegroups.com>
Gunnar Hjalmarsson wrote:
> latin0511@gmail.com wrote:
> > I'm using the procedural upload() function from CGI.pm.
> > In this line:
> > my $fd_file = upload( 'file' ) or die( "upload() ( $! )" );
>
> What makes you think that $! contains an appropriate error message if no
> file is uploaded?
I check that param( 'file' ) exists before that line, if that's what
you mean.
I think that upload() is like open() in some aspect, thats why it
should set $!.
> > I encounter the weird-looking error:
> > "Inappropriate ioctl for device".
> >
> > I don't understand what could be the problem. I did exactly like they
> > say in the manual.
> > Can you please help me solve this problem?
>
> Use the CPAN module CGI::UploadEasy.
I can't do that. I want the program to generate a random name for every
file uploaded, and using UploadEasy it looks impossible.
In addition, UploadEasy is based on CGI.pm, and uses CGI.pm's upload()
function too, so there is no reason why it should work.
------------------------------
Date: Sat, 01 Jul 2006 21:35:56 GMT
From: "A. Sinan Unur" <1usa@llenroc.ude.invalid>
Subject: Re: "Inappropriate ioctl for device" while upload()ing using CGI.pm
Message-Id: <Xns97F3B31EEF73asu1cornelledu@127.0.0.1>
latin0511@gmail.com wrote in
news:1151788459.077665.212490@v61g2000cwv.googlegroups.com:
>
> Gunnar Hjalmarsson wrote:
>> latin0511@gmail.com wrote:
>> > I'm using the procedural upload() function from CGI.pm.
>> > In this line:
>> > my $fd_file = upload( 'file' ) or die( "upload() ( $! )" );
>>
...
>> > Can you please help me solve this problem?
>>
>> Use the CPAN module CGI::UploadEasy.
>
> I can't do that. I want the program to generate a random name for
> every file uploaded, and using UploadEasy it looks impossible.
> In addition, UploadEasy is based on CGI.pm, and uses CGI.pm's upload()
> function too, so there is no reason why it should work.
I have not used Gunnar's module, however, I looked at the source code to
learn from it. Looking at it again, I don't see why it should not work.
On the other hand, I note that we have not seen any of your code, so we
have no idea if your problem is really related to CGI.pm or your own
code.
If I were you, I would write a test script using CGI::UploadEasy, and
see if the upload succeeds in the simple case. If it does, then you will
have shown that the problem is related to your code.
Regardless of wheter CGI::UploadEasy works for you, post a short but
complete example exhibiting the problem.
Sinan
------------------------------
Date: Sat, 01 Jul 2006 23:55:15 +0200
From: Gunnar Hjalmarsson <noreply@gunnar.cc>
Subject: Re: "Inappropriate ioctl for device" while upload()ing using CGI.pm
Message-Id: <4go9e2F1n6hotU1@individual.net>
latin0511@gmail.com wrote:
> Gunnar Hjalmarsson wrote:
>>latin0511@gmail.com wrote:
>>>
>>>my $fd_file = upload( 'file' ) or die( "upload() ( $! )" );
>>
>>What makes you think that $! contains an appropriate error message if no
>>file is uploaded?
>
> I check that param( 'file' ) exists before that line, if that's what
> you mean.
I mean that I'm not aware of any docs stating that $! gets set if you
call CGI::upload() with a non-existent upload field.
>>Use the CPAN module CGI::UploadEasy.
>
> I can't do that. I want the program to generate a random name for every
> file uploaded, and using UploadEasy it looks impossible.
Even if CGI::UploadEasy isn't meant for that, you might still want to
use it and rename the uploaded files to whatever you like.
> In addition, UploadEasy is based on CGI.pm, and uses CGI.pm's upload()
> function too,
True..
> so there is no reason why it should work.
.. only that it does work for its purpuse, whether there is a reason or
not. ;-)
--
Gunnar Hjalmarsson
Email: http://www.gunnar.cc/cgi-bin/contact.pl
------------------------------
Date: Sat, 01 Jul 2006 14:10:56 -0400
From: "Eric R. Meyers" <ermeyers@adelphia.net>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <OZqdnexketkvJzvZnZ2dnUVZ_umdnZ2d@adelphia.com>
Yohan N. Leder wrote:
>
> The sub I want to fork, async or Win32::Process is quite long, but
> mainly, it does calculations against input user (collected by main
> process) and data already written in server files, then update these
> same server files with new results. However, durin,g this time, main
> process has to continue and doesn't wait for anything about this
> secondary process (because of this, I indicated DETACHED_PROCESS in
> Win32::Process, $SIG{CHLD} = 'IGNORE' when I gone through fork(), and
> detach() about threads).
>
First things first, this is a CGI program, so let's keep it simple, if we
can. The CGI program is getting the new data submitted by the user, and
that data needs to be processed (short or long), and the server files are
to be updated with the new results. Apparently, the CGI program, having
received the new data, doesn't need to wait around for that long background
processing, so you just want to queue that long background processing and
return some HTML content to the user. Right? No problem.
Do you want to ensure that your long background processing is always
completed, before receiving the next CGI submission of more new data to be
calculated against the server file data, which may or may not have finished
updating from the last session? You may need to develop a means to verify
that the current server file data that you're using in your short
"on-the-fly" calculations is completely up to date. How many user sessions
will be occurring concurrently? Maybe you will actually want to wait for
the new data to be fully processed, before returning that HTML content to
the user, or users.
> What I want is that this long calculation/file_writing sub be launched
> in an asychonous manner. Also, I don"'t want to put this sub in a second
> script because it may be call in another place of the main process, but
> with sub parameters doing it's a short computing this time ; in others
> wod, depending of the sub parameters, this sub will be long or short.
> And for the long call (one only in the entire script), I wish it be a
> non blocking one : fork and or threads was ideal for this... But...
Seems to me like you need to create a new Perl module that contains your
reusable (short and long) processing code.
One program using that new Perl module of your's is the CGI program
performing the short "on-the-fly" processing, and another new program of
your's, to be developed to run in the background, can use that same new
Perl module of your's, to watch your server file queue for the long "batch"
processing.
If the server file queue is empty and unlocked, then you can safely assume
that your server files are up to date for the short "on-the-fly" processing
to be done accurately in the CGI program. You'll need to develop a locking
mechanism to handle the concurrency issues of multiple processes and
multiple users.
I hope this helps.
Eric
------------------------------
Date: Sat, 1 Jul 2006 21:08:36 +0200
From: Yohan N. Leder <ynleder@nspark.org>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <MPG.1f10e6a123c641b29898b7@news.tiscali.fr>
In article <OZqdnexketkvJzvZnZ2dnUVZ_umdnZ2d@adelphia.com>,
ermeyers@adelphia.net says...
> Yohan N. Leder wrote:
>
> >
> > The sub I want to fork, async or Win32::Process is quite long, but
> > mainly, it does calculations against input user (collected by main
> > process) and data already written in server files, then update these
> > same server files with new results. However, durin,g this time, main
> > process has to continue and doesn't wait for anything about this
> > secondary process (because of this, I indicated DETACHED_PROCESS in
> > Win32::Process, $SIG{CHLD} = 'IGNORE' when I gone through fork(), and
> > detach() about threads).
> >
>
> First things first, this is a CGI program, so let's keep it simple, if we
> can. The CGI program is getting the new data submitted by the user, and
> that data needs to be processed (short or long), and the server files are
> to be updated with the new results. Apparently, the CGI program, having
> received the new data, doesn't need to wait around for that long background
> processing, so you just want to queue that long background processing and
> return some HTML content to the user. Right? No problem.
>
> Do you want to ensure that your long background processing is always
> completed, before receiving the next CGI submission of more new data to be
> calculated against the server file data, which may or may not have finished
> updating from the last session? You may need to develop a means to verify
> that the current server file data that you're using in your short
> "on-the-fly" calculations is completely up to date. How many user sessions
> will be occurring concurrently? Maybe you will actually want to wait for
> the new data to be fully processed, before returning that HTML content to
> the user, or users.
>
> > What I want is that this long calculation/file_writing sub be launched
> > in an asychonous manner. Also, I don"'t want to put this sub in a second
> > script because it may be call in another place of the main process, but
> > with sub parameters doing it's a short computing this time ; in others
> > wod, depending of the sub parameters, this sub will be long or short.
> > And for the long call (one only in the entire script), I wish it be a
> > non blocking one : fork and or threads was ideal for this... But...
>
> Seems to me like you need to create a new Perl module that contains your
> reusable (short and long) processing code.
>
> One program using that new Perl module of your's is the CGI program
> performing the short "on-the-fly" processing, and another new program of
> your's, to be developed to run in the background, can use that same new
> Perl module of your's, to watch your server file queue for the long "batch"
> processing.
>
> If the server file queue is empty and unlocked, then you can safely assume
> that your server files are up to date for the short "on-the-fly" processing
> to be done accurately in the CGI program. You'll need to develop a locking
> mechanism to handle the concurrency issues of multiple processes and
> multiple users.
>
> I hope this helps.
>
> Eric
>
Thanks for your long analysis, Eric... But, I've not any problem about
what to do in the long and short calculation (same sub) and how to
manage concurrent calls from several users. All of this done and works
fine under Unix plateform on which I'm going through a simple fork()...
So, now, I just want to do that this same script (working right under
*nix) work under Win32 too. So, I just drive to a branch of code or
another depending of $^O value.
So, don't enter in sub detail. I just wish to know how to replace the
following code for it to work under ActivePerl 5.8.8 for Win32.
$SIG{CHLD} = 'IGNORE';
my $pid = fork();
die "fork: $!\n" unless defined($pid);
if (!$pid){compute_it($a, $b, $c, $d); exit 0;}
How to write this code part for ActivePerl and work-around its known bug
when using fork or threads when in taint mode ? How to do it without
changing any other thing in the rest of the script's code ? Do you have
another idea than Win32::Process ? Or, how to do it using
Win32::Process ?
------------------------------
Date: Sat, 1 Jul 2006 14:26:33 -0500
From: Tad McClellan <tadmc@augustmail.com>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <slrneadj39.731.tadmc@magna.augustmail.com>
Yohan N Leder <ynleder@nspark.org> wrote:
> Sory for the first test code which was written too quickly :
That is unfortunate.
I've already spent the full allocation of volunteer time on a
problem that doesn't even exist.
Your carelessness has tricked me into spending time on something
worthless rather than in answering someone else's real Perl question.
That can annoy folks, so you should take more care when composing
a post.
There are (likely) hundreds of readers here.
Would you walk into an auditorium full of people and just start
saying stuff, or would you think about what to say a bit before
making your presentation?
Does this newsgroup deserve less courtesy than a room full
of live people?
> don't take
> care about it.
Too late.
--
Tad McClellan SGML consulting
tadmc@augustmail.com Perl programming
Fort Worth, Texas
------------------------------
Date: Sat, 01 Jul 2006 16:07:27 -0400
From: "Eric R. Meyers" <ermeyers@adelphia.net>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <UZidneqE5dliSDvZnZ2dnUVZ_tidnZ2d@adelphia.com>
Yohan N. Leder wrote:
> How to write this code part for ActivePerl and work-around its known bug
> when using fork or threads when in taint mode ? How to do it without
> changing any other thing in the rest of the script's code ? Do you have
> another idea than Win32::Process ? Or, how to do it using
> Win32::Process ?
I tried my best to come up with an alternative structure for you, not
knowing much other than what I read. Are you using CGI.pm? If so, have
you tried running this script directly from the command line, rather than
from under the http server? The reason that I'm asking you this is because
I've found a lot of Perl CGI problems caused by strict system-security
protections. I'm not on Windows, so I can't help you with an ActivePerl
problem, but I've found a lot of issues running my Perl CGI programs under
Security Enhanced Linux (SELinux) on my FC-4 linux system. If your script
is CGI.pm based, and you find that it does actually run as planned directly
from the command line, then I would look for a strict system-security
setting causing the ActivePerl fork problem under the http server.
Just another idea. Last thought. Good luck.
------------------------------
Date: Sat, 1 Jul 2006 23:36:57 +0200
From: Yohan N. Leder <ynleder@nspark.org>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <MPG.1f1109675effd34a9898b8@news.tiscali.fr>
In article <UZidneqE5dliSDvZnZ2dnUVZ_tidnZ2d@adelphia.com>,
ermeyers@adelphia.net says...
> Yohan N. Leder wrote:
>
> > How to write this code part for ActivePerl and work-around its known bug
> > when using fork or threads when in taint mode ? How to do it without
> > changing any other thing in the rest of the script's code ? Do you have
> > another idea than Win32::Process ? Or, how to do it using
> > Win32::Process ?
>
> I tried my best to come up with an alternative structure for you, not
> knowing much other than what I read. Are you using CGI.pm? If so, have
> you tried running this script directly from the command line, rather than
> from under the http server? The reason that I'm asking you this is because
> I've found a lot of Perl CGI problems caused by strict system-security
> protections. I'm not on Windows, so I can't help you with an ActivePerl
> problem, but I've found a lot of issues running my Perl CGI programs under
> Security Enhanced Linux (SELinux) on my FC-4 linux system. If your script
> is CGI.pm based, and you find that it does actually run as planned directly
> from the command line, then I would look for a strict system-security
> setting causing the ActivePerl fork problem under the http server.
>
> Just another idea. Last thought. Good luck.
>
>
Thanks again for your effort, Eric : very kindly. Unfortunately, this
script (you'll think it's a nightmare, sure;-)) CGI script has to stay a
'CGI' because a major entry pointy is several web forms, and it can't be
CGI.pm based because of some target servers in the park.
Thanks too for your 'good luck' : I'm going to regret to engage myself
to be Win32 compatible too :-(
When does a Perl for Win will be stable enough on these fork/threading
subjects : that is the question !
------------------------------
Date: Sat, 1 Jul 2006 23:40:30 +0200
From: Yohan N. Leder <ynleder@nspark.org>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <MPG.1f110a27133f3ede9898b9@news.tiscali.fr>
In article <slrneadj39.731.tadmc@magna.augustmail.com>,
tadmc@augustmail.com says...
> Yohan N Leder <ynleder@nspark.org> wrote:
>
> > Sory for the first test code which was written too quickly :
>
>
> That is unfortunate.
>
> I've already spent the full allocation of volunteer time on a
> problem that doesn't even exist.
>
> Your carelessness has tricked me into spending time on something
> worthless rather than in answering someone else's real Perl question.
>
> That can annoy folks, so you should take more care when composing
> a post.
>
> There are (likely) hundreds of readers here.
>
> Would you walk into an auditorium full of people and just start
> saying stuff, or would you think about what to say a bit before
> making your presentation?
>
> Does this newsgroup deserve less courtesy than a room full
> of live people?
>
>
> > don't take
> > care about it.
>
>
> Too late.
Didn't you done any mistake at a time or another ? Tolerance sounds
better than morality, isn't it.
------------------------------
Date: Sat, 01 Jul 2006 17:59:55 -0400
From: "Eric R. Meyers" <ermeyers@adelphia.net>
Subject: Re: Does recursive call able to print in same page as main call
Message-Id: <YIGdnew7w-bDbTvZnZ2dnUVZ_qCdnZ2d@adelphia.com>
Yohan N. Leder wrote:
> Didn't you done any mistake at a time or another ? Tolerance sounds
> better than morality, isn't it.
Not everyone is jaded by their being a volunteer, so just forget about it
Yohan, and go on with your good, and occasionally erring life, like
everyone else of us has to do.
I see no problem with what you've done. We all make honest mistakes.
Eric
------------------------------
Date: Sat, 01 Jul 2006 19:22:36 +0100
From: Paul Marquess <paul.marquess@btinternet.com>
Subject: Re: Extract gzip Files
Message-Id: <44a6bd6c$0$15871$4d4eb98e@read.news.uk.uu.net>
Eric R. Meyers wrote:
> Mike Flannigan wrote:
>
>>
>> I want to extract all the gzip files in a directory to the same
>> directory. I know how to do this with zip files with
>> Archive::Zip and File::Find, but have not been able to do
>> it with gzip files. I have searched hard, but not found a
>> good solution yet, unless the best solution is Tie::Gzip
>> along with the gzip program.
>>
>> I'd like to do this with Perl only if that is practical. I am
>> on Win2000 and don't have gzip (I don't think). I do
>> have WinZip and it will extract the files one-by-one.
>> I just downloaded Power Archiver 6.1, but would
>> prefer not to install it. My skill level is moderately
>> advanced - well maybe not, but far above newbie
>> anyway.
>>
>>
>> Mike Flannigan
>
> Take a look at IO::Zlib and Compress::Zlib.
or IO::Uncompress::Gunzip if you don't mind using beta quality code.
Paul
------------------------------
Date: Sat, 01 Jul 2006 19:07:48 GMT
From: Mike Flannigan <mikeflan@earthlink.net>
Subject: Re: Extract gzip Files
Message-Id: <44A6C8D6.8AFA1004@earthlink.net>
John Bokma wrote:
>
> See http://gnuwin32.sourceforge.net/
>
> http://gnuwin32.sourceforge.net/packages/gzip.htm
>
Thank you all for the responses.
Mike
------------------------------
Date: 6 Apr 2001 21:33:47 GMT (Last modified)
From: Perl-Users-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 6 Apr 01)
Message-Id: <null>
Administrivia:
#The Perl-Users Digest is a retransmission of the USENET newsgroup
#comp.lang.perl.misc. For subscription or unsubscription requests, send
#the single line:
#
# subscribe perl-users
#or:
# unsubscribe perl-users
#
#to almanac@ruby.oce.orst.edu.
NOTE: due to the current flood of worm email banging on ruby, the smtp
server on ruby has been shut off until further notice.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
#To request back copies (available for a week or so), send your request
#to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
#where x is the volume number and y is the issue number.
#For other requests pertaining to the digest, send mail to
#perl-users-request@ruby.oce.orst.edu. Do not waste your time or mine
#sending perl questions to the -request address, I don't have time to
#answer them even if I did know the answer.
------------------------------
End of Perl-Users Digest V10 Issue 9415
***************************************
