[19700] in Perl-Users-Digest
Perl-Users Digest, Issue: 1895 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue Oct 9 06:11:27 2001
Date: Tue, 9 Oct 2001 03:10:10 -0700 (PDT)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Message-Id: <1002622210-v10-i1895@ruby.oce.orst.edu>
Content-Type: text
Perl-Users Digest Tue, 9 Oct 2001 Volume: 10 Number: 1895
Today's topics:
Skimming an array for non-undef <nomail@hursley.ibm.com>
Re: Skimming an array for non-undef <joe+usenet@sunstarsys.com>
Re: Skimming an array for non-undef (Logan Shaw)
Re: Stop Transversal of a Directory... the dot dot prob <goldbb2@earthlink.net>
Text::CSV with Special Chars? (Ted Smith)
Upload file with Netscape 4.6 <dapingwang@lucent.com>
Re: Useless use of numeric eq in void context (Tobias Wolff)
Re: Useless use of numeric eq in void context (Tobias Wolff)
Re: waitpid in signal handlers (Charles DeRykus)
Re: waitpid in signal handlers <leo@strike.wu-wien.ac.at>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 09 Oct 2001 08:43:55 +0100
From: Derek Fountain <nomail@hursley.ibm.com>
Subject: Skimming an array for non-undef
Message-Id: <9pu9st$1sk2$1@sp15at20.hursley.ibm.com>
I have a long array which has a number of values in the first n elements,
and from there on all the values are undef. What would be the most
efficient way of finding the index of the last element of the array which
contains a value?
I seem to have come up with any number of really clunky ways to do it.
What's the "perl solution"?
TIA,
---
Derek
------------------------------
Date: 09 Oct 2001 04:31:36 -0400
From: Joe Schaefer <joe+usenet@sunstarsys.com>
Subject: Re: Skimming an array for non-undef
Message-Id: <m3vghpfc47.fsf@mumonkan.sunstarsys.com>
Derek Fountain <nomail@hursley.ibm.com> writes:
> I have a long array which has a number of values in the first n elements,
> and from there on all the values are undef. What would be the most
> efficient way of finding the index of the last element of the array which
> contains a value?
>
> I seem to have come up with any number of really clunky ways to do it.
> What's the "perl solution"?
TMTOWTDI! A clunky way isn't necessarily a bad way, especially
when you're measuring things against a vague concept of "efficiency".
Why not post what you've tried so far?
--
Joe Schaefer "Familiarity breeds contempt -- and children."
--Mark Twain
------------------------------
Date: 9 Oct 2001 04:16:11 -0500
From: logan@cs.utexas.edu (Logan Shaw)
Subject: Re: Skimming an array for non-undef
Message-Id: <9puf8r$j98$1@charity.cs.utexas.edu>
In article <9pu9st$1sk2$1@sp15at20.hursley.ibm.com>,
Derek Fountain <nomail@hursley.ibm.com> wrote:
>I have a long array which has a number of values in the first n elements,
>and from there on all the values are undef. What would be the most
>efficient way of finding the index of the last element of the array which
>contains a value?
Assuming there is guaranteed to be at least one defined value
in the array:
my $index;
for ($index = $#array; not defined $array[$index]; $index--)
{
}
If you're not guaranteed that:
my $index;
for ($index = $#array; $index >= 0; $index--)
{
last if defined $array[$index];
}
It would be nice if regular expressions could apply to arrays too, but
since they can't, I'll have to settle for converting one to another:
$s = join ('', map { (defined) ? '1' : '0'} @array);
$s =~ /(0*)$/;
$index = $#array - length $1;
If you don't mind destroying the undefs at the end of the array, you
can do this:
while (@array and not defined $array[$#array])
{
pop @array;
}
$index = $#array;
There may be a since simple, clear one-liner, but I can't think
of what it is.
- Logan
--
"In order to be prepared to hope in what does not deceive,
we must first lose hope in everything that deceives."
Georges Bernanos
------------------------------
Date: Mon, 08 Oct 2001 22:43:54 -0400
From: Benjamin Goldberg <goldbb2@earthlink.net>
Subject: Re: Stop Transversal of a Directory... the dot dot problem
Message-Id: <3BC2646A.B54B77BC@earthlink.net>
BUCK NAKED1 wrote:
[snip of my Archive::Zip solution]
> Thanks for that example, but I'd rather use GNU *unzip* and hopefully
> have the same solution to use with *tar*.
There is an Archive::Tar, you know.
Here's some [untested] solutions for doing what you're asking for:
unzip file.zip -x "../*" -x "*/../*" -x "/*" -x "~*" -d wkdir
tar xf file.tar --exclude="../*" --exclude="*/../*" \
--exclude="/*" --exclude="~*" -C wkdir
However, I would like to point out that --exclude probably only exists
with GNU tar, and thus is not likely to be portable.
I also don't know if more than one exclude glob is allowed... the docs
don't say one way or another. Having more than one might not work, and
probably isn't portable even if it does work.
I don't have a non-gnu tar, but it's possible that the -X option
mentioned in the man page isn't a GNU specific option [this is a guess
based on the fact that it's a single letter flag]... if that's so, then
you could do:
(for glob in "../*" "*/../*" "/*" "~*"; do
echo "$glob"
done) > exclude.txt
tar xf file.tar -X exclude.txt -C wkdir
*If* -X exists with older tars, then this might be portable, but then
again, it might not be. And the exclude file might only allow real file
names, not globs... so that too might be a kind of nonportability.
If you used Archive::Tar, you would have much less to worry about with
regard to such portability problems... and it's probably easier to
convert a program which uses A::Z to one using A::T than it is to
convert a shell script which uses unzip to one using tar.
--
"Just how stupid are you Kuno?"
"Verily, Tatewaki Kuno knows no limits."
------------------------------
Date: 8 Oct 2001 20:43:37 -0700
From: bluearchtop@my-deja.com (Ted Smith)
Subject: Text::CSV with Special Chars?
Message-Id: <9d2caaf1.0110081943.2af65bd4@posting.google.com>
It seems that the $csv->combine() method will not work if your array
has any special characters. For example, my test with a field as
'Vitória' will not work.
Is there a reason why this module has to fail for special chars? What
alternatives are there?
------------------------------
Date: Tue, 09 Oct 2001 16:25:21 +0800
From: Daping Wang <dapingwang@lucent.com>
Subject: Upload file with Netscape 4.6
Message-Id: <3BC2B471.97410466@lucent.com>
Hello,
Does anyone ever ran into the trouble with uploading in Netscape?
I have a html page with lines as
<form ENCTYPE="multipart/form-data" METHOD=POST
action="./../cgi-bin/estimates.cgi">
<tr>
<td>Work Item:
<br><input TYPE=TEXT NAME="wi" SIZE=15 MAXLENGTH=20></td>
</tr>
<tr>
<td>Estimation File:
<br><input TYPE="FILE" NAME="file" SIZE=15 MAXLENGHT=10000></td>
</tr>
<tr>
<td><input TYPE=SUBMIT VALUE="Submit"><input TYPE=RESET VALUE="Reset"></td>
</tr>
</table>
</form>
It works very well with IE4.0+ but failed with my netscape on Solaris.
I am using CGI.pm to handle the filename. It happened that the return
value from $query->upload was undef with my netscape. Is there any
clue to this problem?
Thanks,
Daping Wang
Lucent Technologies.
------------------------------
Date: 8 Oct 2001 23:28:55 -0700
From: wolff@falkag.de (Tobias Wolff)
Subject: Re: Useless use of numeric eq in void context
Message-Id: <46872b23.0110082228.6c09bd6@posting.google.com>
Hello Anno,
I really did search in the wrong place. The error was deeply nested
inside of the if-statement.
Thanks,
Tobias.
anno4000@lublin.zrz.tu-berlin.de (Anno Siegel) wrote in message news:<9ps2j9$h4q$1@mamenchi.zrz.TU-Berlin.DE>...
> According to Tobias Wolff <wolff@falkag.de>:
> > Hi,
> > I can't relate the following error message to my code:
> >
> > Useless use of numeric eq in void context at ./interface.pl line
> > 3124
> >
> > Lines 3123-3124 read:
> >
> > $intResult = &myFunction();
> > if($intResult >= 0)
> > {
> > }
>
> It is very likely that the actual error is within the if-block,
> which you don't show.
>
> Anno
------------------------------
Date: 8 Oct 2001 23:29:16 -0700
From: wolff@falkag.de (Tobias Wolff)
Subject: Re: Useless use of numeric eq in void context
Message-Id: <46872b23.0110082229.6218f9a5@posting.google.com>
Hello Mark,
I really did search in the wrong place. The error was deeply nested
inside of the if-statement.
Thanks,
Tobias.
mjd@plover.com (Mark Jason Dominus) wrote in message news:<3bc1e483.9b8$a@news.op.net>...
> In article <9ps2j9$h4q$1@mamenchi.zrz.TU-Berlin.DE>,
> Anno Siegel <anno4000@lublin.zrz.tu-berlin.de> wrote:
> >It is very likely that the actual error is within the if-block,
> >which you don't show.
>
> I think it's more likely to be in one of the elsif conditions.
> Perl has that long-standing bug where if you get a warning in an
> 'elsif', perl reports it as being in the 'if' condition instead.
------------------------------
Date: Tue, 9 Oct 2001 00:59:03 GMT
From: ced@bcstec.ca.boeing.com (Charles DeRykus)
Subject: Re: waitpid in signal handlers
Message-Id: <GKwyqF.E5v@news.boeing.com>
In article <3BBF3072.3B9C9561@strike.wu-wien.ac.at>,
Alexander Bergolth <leo@strike.wu-wien.ac.at> wrote:
>Hi!
>
>I've written a small test-script (see below) that dumps core because
>of a seg-fault on many systems when the signal handler is called while
>there is memory is allocated in the main program. The signal handler
>doesn't use or modify any variable, it's only:
>
> $SIG{'CHLD'} = sub {
> while (waitpid(-1,&WNOHANG) > 0) { }
> };
>
>It looks like Perls waitpid uses malloc. :(
>
>I've tested this with perl-5.6.0 on AIX-4.2.1 and AIX-4.3.3 and
>with perl-5.005_03 on linux-2.2.19.
>
>The test-script and the stack backtrace is attached below...
>(The random- and delay-parameters are optimised for a crash on
>slower machines.)
>
>I've found a similar thread in this group on Google two years ago...
> http://groups.google.com/groups?th=73e147d4f576ae40
>... but I couldn't find a workaround for this. (Setting preinitialised
>flags and calling waitpid outside the signal-handler is not possible
>for my application.)
>
>Any hints?
>Thanks,
>--leo
>
>---------- snipp! ----------
>#!/usr/local/bin/perl
>
>use strict;
>use POSIX ":sys_wait_h";
>
>my $RAND1= 2000;
>my $RAND2= 2000;
>my $DELAY_MAIN = 0.2;
>my $DELAY_CHILD = 2;
>
>$SIG{'CHLD'} = sub {
> while (waitpid(-1,&WNOHANG) > 0) { }
>};
>
>my $CHILD_PID = 0;
>
>srand();
>$|= 1;
>
>my $i;
>for ($i = 1; $i < 200; $i++) {
> print "fork $i\n";
> # allocate some memory
> my ($i, $r1, $r2, @buf);
> $r1= rand($RAND1);
> for ($i= 1; $i <= $r1; $i++) {
> $r2= rand($RAND2);
> $buf[$i] = "x" x $r2;
> }
>
> my $pid;
> if ($pid = fork) {
> # parent
> select(undef, undef, undef, rand($DELAY_MAIN));
> print " Child $pid ready\n";
> next;
> } elsif (defined $pid) {
> # child
> $SIG{'CHLD'} = 'DEFAULT';
> print " Child $$ ready\n";
> select (undef, undef, undef, rand($DELAY_CHILD));
> print " Child $$ exit\n";
> exit(0);
> }
> else {
> print "Fork error: $!\n";
> return;
> }
>}
>
>print "Done\n";
Maybe I was just lucky but blocking SIGCHLD appeared work.
I only tried a few times on each platform but the earlier
cores and hangs disappeared consistently. Children were
successfully reaped too although Solaris reported some
of them defunct until they were reaped.
(Platforms were Solaris 2.7 and AIX 4.2 using 5.6.1).
Changed code below.
hope this helps,
--
Charles DeRykus
use strict;
use POSIX qw( :sys_wait_h :signal_h );
...
$|= 1;
#----------------------------------
#block SIGCHLD during allocation
#----------------------------------
my $sigset = POSIX::SigSet->new(SIGCHLD); # block SIGCHLD
my $old_sigset = POSIX::SigSet->new; # save old sigmask
unless ( defined sigprocmask( SIG_BLOCK, $sigset, $old_sigset ) ) {
die "couldn't block SIGCHLD";
}
my $i;
for ($i = 1; $i < 200; $i++) {
print "fork $i\n";
...
}
# restore SIGCHLD
unless ( defined sigprocmask( SIG_UNBLOCK, $old_sigset ) ) {
die "can't unblock SIGCHLD";
}
print "SIGCHLD unblocked ...\n";
$SIG{CHLD} = sub { 1 while waitpid(-1,&WNOHANG) > 0; };
print "Done\n";
__END__
------------------------------
Date: Tue, 09 Oct 2001 09:54:31 +0200
From: Alexander Bergolth <leo@strike.wu-wien.ac.at>
Subject: Re: waitpid in signal handlers
Message-Id: <3BC2AD37.31A7AD9@strike.wu-wien.ac.at>
Hi!
Charles DeRykus wrote:
> In article <3BBF3072.3B9C9561@strike.wu-wien.ac.at>,
> Alexander Bergolth <leo@strike.wu-wien.ac.at> wrote:
> >I've written a small test-script (see below) that dumps core because
> >of a seg-fault on many systems when the signal handler is called while
> >there is memory is allocated in the main program. The signal handler
> >doesn't use or modify any variable, it's only:
>
> Maybe I was just lucky but blocking SIGCHLD appeared work.
> I only tried a few times on each platform but the earlier
> cores and hangs disappeared consistently. Children were
> successfully reaped too although Solaris reported some
> of them defunct until they were reaped.
>
> (Platforms were Solaris 2.7 and AIX 4.2 using 5.6.1).
> my $sigset = POSIX::SigSet->new(SIGCHLD); # block SIGCHLD
> my $old_sigset = POSIX::SigSet->new; # save old sigmask
> unless ( defined sigprocmask( SIG_BLOCK, $sigset, $old_sigset ) ) {
> die "couldn't block SIGCHLD";
> }
> [...]
The memory allocation section in my test script was only added to
demonstrate that the signal handler conflicts with malloc. In a real
life application, memory could be allocated nearly everywhere, e.g.
when assigning a new hash element, using my-variables, etc.
Thus blocking SIGCHLD in the main program to prevent a reentering
malloc is very hard to accomplish, it would be much easier to do it
without the signal handler and call waitpid in the main loop.
Unfortunately this could lead to some zombies hanging around till that
"cleanup"-point is reached in the main loop. :(
In my opinion, blocking a signal only makes sense for some critical
sections, e.g. to avoid race conditions. (For example in combination
with sigsuspend.)
Anyway, thanks for your hint,
--leo
------------------------------
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.
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 1895
***************************************
