[31889] in Perl-Users-Digest
Perl-Users Digest, Issue: 3152 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Wed Sep 29 00:09:41 2010
Date: Tue, 28 Sep 2010 21:09:24 -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 Tue, 28 Sep 2010 Volume: 11 Number: 3152
Today's topics:
Re: Claimed to be an "old hack" <nospam-abuse@ilyaz.org>
Re: Claimed to be an "old hack" <willem@turtle.stack.nl>
Re: Claimed to be an "old hack" <ben@morrow.me.uk>
Re: Claimed to be an "old hack" <derykus@gmail.com>
Re: Displaying 'umlaut' character <hjp-usenet2@hjp.at>
Re: Is $A = $B = n; valid? <tadmc@seesig.invalid>
Re: Is $A = $B = n; valid? <tadmc@seesig.invalid>
Re: Is $A = $B = n; valid? <jwkrahn@example.com>
Re: Is $A = $B = n; valid? <jwkrahn@example.com>
Re: Long script "just stops" sometime <xhoster@gmail.com>
Re: Long script "just stops" sometime <xhoster@gmail.com>
Re: Long script "just stops" sometime <jerry@ieee.org>
Time::Format::time with $SIG{__DIE__} problem <google@markginsburg.com>
Re: Time::Format::time with $SIG{__DIE__} problem <nospam-abuse@ilyaz.org>
Re: Time::Format::time with $SIG{__DIE__} problem <google@markginsburg.com>
Re: Time::Format::time with $SIG{__DIE__} problem <derykus@gmail.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 28 Sep 2010 22:11:44 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Claimed to be an "old hack"
Message-Id: <slrnia4q10.dqi.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-09-28, Ben Morrow <ben@morrow.me.uk> wrote:
>> >> {(!($^O=~/^[M]*$32/i)&&($0=~s!^.*/!!))||($0=~s!.*\\!!)}
>> > Making that correction, we have an expression of
>> > the form
>> >
>> > (A && B) || C
>> >
>> > which is a nasty shorthand for
>> >
>> > if (A) {
>> > B
>> > }
>> > else {
>> > C
>> > }
>>
>> No, it is not.
>
> I know it's not *equivalent*. But, in this case, that *is* how it's
> being used.
Unclear. It looks like you wanted it mean something like "B never
fails", so C cannot be executed if A succeeds (which is not true), and
you "nasty" is just for "using ||/&& for control flow" (which I also
won't agree with).
From other messages in this thread I conclude that your "nasty
equivalent" might have meant:
"Apparently, the author [wrongly] thought that this expression is an
equivalent".
> It's a very usual way of doing a compact if-then-else in
> shell, which is probably where it comes from.
Again, is s/way/wrong way/ assumed here? I do (A&&(B||true))||C sometimes...
Still puzzled,
Ilya
------------------------------
Date: Tue, 28 Sep 2010 22:24:13 +0000 (UTC)
From: Willem <willem@turtle.stack.nl>
Subject: Re: Claimed to be an "old hack"
Message-Id: <slrnia4qod.skd.willem@turtle.stack.nl>
Ben Morrow wrote:
)
) Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
)> On 2010-09-28, Ben Morrow <ben@morrow.me.uk> wrote:
)> >
)> > Quoth cpolish@nonesuch.com:
)> >> {(!($^O=~/^[M]*$32/i)&&($0=~s!^.*/!!))||($0=~s!.*\\!!)}
)>
)> > I almost certainly doesn't do what it's supposed to do :). That '*$32'
)> > ought to read '.*32$'.
)>
)> Just make sure that $32 eq '.*32$'. ;-) But `$1 means \1'-fix (if
)> whereever was one - do not remember offhand) may intervene...
)>
)> > Making that correction, we have an expression of
)> > the form
)> >
)> > (A && B) || C
)> >
)> > which is a nasty shorthand for
)> >
)> > if (A) {
)> > B
)> > }
)> > else {
)> > C
)> > }
)>
)> No, it is not.
)
) I know it's not *equivalent*. But, in this case, that *is* how it's
) being used. It's a very usual way of doing a compact if-then-else in
) shell, which is probably where it comes from.
Still, not true.
It's roughly equivalent to:
if (A) {
if (!B) {
C
}
} else {
C
}
You see, if the first substitution fails (does nothing), the second will
then still be executed.
Which is probably not what was intended, but still.
SaSW, Willem
--
Disclaimer: I am in no way responsible for any of the statements
made in the above text. For all I know I might be
drugged or something..
No I'm not paranoid. You all think I'm paranoid, don't you !
#EOT
------------------------------
Date: Tue, 28 Sep 2010 23:32:07 +0100
From: Ben Morrow <ben@morrow.me.uk>
Subject: Re: Claimed to be an "old hack"
Message-Id: <707an7-jp62.ln1@osiris.mauzo.dyndns.org>
Quoth Ilya Zakharevich <nospam-abuse@ilyaz.org>:
> On 2010-09-28, Ben Morrow <ben@morrow.me.uk> wrote:
> >> >> {(!($^O=~/^[M]*$32/i)&&($0=~s!^.*/!!))||($0=~s!.*\\!!)}
>
> >> > Making that correction, we have an expression of
> >> > the form
> >> >
> >> > (A && B) || C
> >> >
> >> > which is a nasty shorthand for
> >> >
> >> > if (A) {
> >> > B
> >> > }
> >> > else {
> >> > C
> >> > }
> >>
> >> No, it is not.
> >
> > I know it's not *equivalent*. But, in this case, that *is* how it's
> > being used.
>
> Unclear. It looks like you wanted it mean something like "B never
> fails", so C cannot be executed if A succeeds (which is not true), and
> you "nasty" is just for "using ||/&& for control flow" (which I also
> won't agree with).
I don't have a big problem with using || and && for control flow. I
think it's a little ugly, but not importantly so.
> From other messages in this thread I conclude that your "nasty
> equivalent" might have meant:
>
> "Apparently, the author [wrongly] thought that this expression is an
> equivalent".
Yes, that's exactly what I meant. It seems clear to me that an
if-then-else is what the author wanted; hence the use of &&/|| was a
shorthand, and a nasty one because it isn't really equivalent.
> > It's a very usual way of doing a compact if-then-else in
> > shell, which is probably where it comes from.
>
> Again, is s/way/wrong way/ assumed here? I do (A&&(B||true))||C sometimes...
No, no value judgements were implied either way. It is a construction I
have often seen used in shell; I have no opinion as to whether this is a
good or a bad thing. I *do* consider bringing the idiom into Perl a bad
thing; that is what I intended to convey.
Ben
------------------------------
Date: Tue, 28 Sep 2010 16:32:30 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Claimed to be an "old hack"
Message-Id: <90ff965d-8cea-45c7-966b-10f0d4cf4479@k17g2000prf.googlegroups.com>
On Sep 28, 8:35=A0am, mer...@stonehenge.com (Randal L. Schwartz) wrote:
> >>>>> "Ben" =3D=3D Ben Morrow <b...@morrow.me.uk> writes:
>
> Ben> I know it's not *equivalent*. But, in this case, that *is* how it's
> Ben> being used. It's a very usual way of doing a compact if-then-else in
> Ben> shell, which is probably where it comes from.
>
> No, it's a broken cargo-culted way of doing a compact if-then-else.
>
There appear to be more serious things afoot too.
The exploit script didn't have warnings turned on
which hides the 'uninitialized' message from $32.
There's a missing '.' after the [M] too (which Ben
added)since any OS string would match:
'$^O =3D~ /^[M]*$32/i'.
So, for clarity, Deparse refactors the corrected
regex:
{(!($^O=3D~/^[M].*32$/i)&&($0=3D~s!^.*/!!))||($0=3D~s!.*\\!!)}
into:
$0 =3D~ s/.*\\// unless not $^O =3D~ /^[M].32$/i
and $0 =3D~ s[^.*/][];
which is much easier to understand and easier
on the eyes...but still the wrong solution for
the reasons mentioned and should be replaced
with File::basename.
--
Charles DeRykus
------------------------------
Date: Tue, 28 Sep 2010 22:22:41 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Displaying 'umlaut' character
Message-Id: <slrnia4jkq.noo.hjp-usenet2@hrunkner.hjp.at>
["Followup-To:" header set to comp.infosystems.www.authoring.html]
On 2010-09-26 15:28, Frank van Bortel <fbortel@home.nl> wrote:
> On 09/22/2010 03:29 PM, Peter J. Holzer wrote:
>> On 2010-09-22 08:13, Frank van Bortel<fbortel@home.nl> wrote:
>>> Apart from what I replied earlier, the correct way to encode
>>> is of course "ö" (without the quotes...)
>>
>> That's not *the* correct way, just *a* correct way. Encoding it in the
>> charset indicated in the Content-Type header or a meta tag is equally
>> correct (and preferrable in most cicumstances, IMHO).
>
> would you please read the HTML definition?
I have. Various HTML definitions over the last 15 years, to be exact,
and they all agree with me. I haven't yet read most of HTML5, but I
don't expect it to depart from existing practice in this respect. Here
is the relevant part of HTML4:
http://www.w3.org/TR/html401/charset.html
hp
------------------------------
Date: Tue, 28 Sep 2010 15:11:09 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Is $A = $B = n; valid?
Message-Id: <slrnia4j0j.8su.tadmc@tadbox.sbcglobal.net>
Joey@still_Learning.invalid <Joey@still_Learning.invalid> wrote:
> Tad McClellan wrote:
>>Joey@still_Learning.invalid <Joey@still_Learning.invalid> wrote:
>>> David Canzi wrote:
>>>>$ perl -c -Mstrict -Mwarnings -e 'my $A = my $B = my $C = 42'
>>>>-e syntax OK
>>>
>>> Thanks. This begs the question 'what if the variables are intended to be
>>> global?'
>>
>>
>>Then declare them to be global:
>>
>> perl -c -Mstrict -Mwarnings -e 'our $A = our $B = our $C = 42'
>
> Doh! Thanks.
If you didn't know that, then you would probably benefit from reading:
"Coping with Scoping":
http://perl.plover.com/FAQs/Namespaces.html
--
Rest In Peace:
Jonah McClellan gave his life for his country in a
helicopter crash in Afghanistan on September 21,2010.
Please pray for his wife and three children.
------------------------------
Date: Tue, 28 Sep 2010 15:13:12 -0500
From: Tad McClellan <tadmc@seesig.invalid>
Subject: Re: Is $A = $B = n; valid?
Message-Id: <slrnia4j4e.8su.tadmc@tadbox.sbcglobal.net>
Peter J. Holzer <hjp-usenet2@hjp.at> wrote:
> On 2010-09-28 02:59, Tad McClellan <tadmc@seesig.invalid> wrote:
>> Joey@still_Learning.invalid <Joey@still_Learning.invalid> wrote:
>>> Ben Morrow wrote:
>>>>
>>>>Quoth "Joey@still_Learning.invalid" <Joey@still_Learning.invalid>:
>>>>> Is the syntax $A = $B = $C = number acceptable?
>>>>
>>>>What happened when you tried it?
>>
>>
>>> I was
>>> inquiring about its acceptability in practice.
>>
>>
>> You may have intended to ask that, but that is not what you in fact asked.
>
> So what?
So I got snarky.
> He clarified it.
By then, the snarkiness had already been released.
--
Rest In Peace:
Jonah McClellan gave his life for his country in a
helicopter crash in Afghanistan on September 21,2010.
Please pray for his wife and three children.
------------------------------
Date: Tue, 28 Sep 2010 18:52:18 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: Is $A = $B = n; valid?
Message-Id: <nZwoo.11754$nl4.2527@newsfe21.iad>
Dr.Ruud wrote:
> On 2010-09-28 00:11, Joey@still_Learning.invalid wrote:
>
>> Is the syntax $A = $B = $C = number acceptable?
>
> I would not use capital letters for variable names, but further it looks
> ok to me.
>
> #!/usr/bin/perl -w
> use strict;
>
> sub number { 42 }
>
> my $foo = my $bar = my $baz = number;
Why the overhead of a subroutine call? Just use a macro which gets
removed at compile time:
sub number () { 42 };
my $foo = my $bar = my $baz = number;
Or:
use constant number => 42;
my $foo = my $bar = my $baz = number;
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Tue, 28 Sep 2010 18:53:19 -0700
From: "John W. Krahn" <jwkrahn@example.com>
Subject: Re: Is $A = $B = n; valid?
Message-Id: <j_woo.11755$nl4.5963@newsfe21.iad>
Peter Makholm wrote:
> "Dr.Ruud"<rvtol+usenet@xs4all.nl> writes:
>
>> On 2010-09-28 00:11, Joey@still_Learning.invalid wrote:
>>
>>> Is the syntax $A = $B = $C = number acceptable?
>
>> my $foo = my $bar = my $baz = number;
>
> While perfectly fine, I would probably write this as
>
> my ($foo, $bar, $baz) = (number) x 3;
$_ = number for my ( $foo, $bar, $baz );
John
--
Any intelligent fool can make things bigger and
more complex... It takes a touch of genius -
and a lot of courage to move in the opposite
direction. -- Albert Einstein
------------------------------
Date: Tue, 28 Sep 2010 18:07:00 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Long script "just stops" sometime
Message-Id: <4ca2b9d8$0$29842$ed362ca5@nr5-q3a.newsreader.com>
Peter J. Holzer wrote:
> On 2010-09-26 23:06, Xho Jingleheimerschmidt <xhoster@gmail.com> wrote:
>> Peter J. Holzer wrote:
>>> In this case, if your guess is right, strace would show that the process
>>> is currently waiting for a read on fd 0 to complete, and then lsof could
>>> be used to find out which file fd 0 is (ok, so for fd 0 you may know
>>> that it's the tty, for for (say) fd 43 you want a tool to look it up).
>> Unfortunately, if you use strace "-p" option to attach to an
>> already-running process, if often doesn't show you what call the process
>> was waiting on at the time of the attachment.
>
> I don't think that ever happened to me in many years of using strace.
> Except with multithreaded processes, but for those strace doesn't work
> reliably anyway (I don't understand why).
This is what I get:
$ perl -le '<>' &
[1] 17657
$ strace -p 17657
Process 17657 attached - interrupt to quit
And then no output until a break out of strace.
Xho
------------------------------
Date: Tue, 28 Sep 2010 18:32:07 -0700
From: Xho Jingleheimerschmidt <xhoster@gmail.com>
Subject: Re: Long script "just stops" sometime
Message-Id: <4ca2b9dc$0$29845$ed362ca5@nr5-q3a.newsreader.com>
Ben Morrow wrote:
> Quoth Xho Jingleheimerschmidt <xhoster@gmail.com>:
>> Ben Morrow wrote:
>>> You can find out what call the process is currently blocking in with ps.
>> Well, maybe *you* can. I've never been able to.
>
> Really?
>
> ~% uname
> FreeBSD
> ~% perl -MPOSIX=pause -epause &
> [3] 68357
> ~% ps -lp 68357
> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
> 1001 68357 14199 0 61 0 5204 3160 pause S 3 0:00.06 perl -MPOSI
> ~%
>
> ~$ uname
> Linux
> ~$ perl -MPOSIX=pause -epause &
> [1] 10335
> ~$ ps -lp 10335
> F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
> 0 S 1051 10335 10321 0 80 0 - 5759 pause pts/1 00:00:00 perl
> ~$
>
> It only tells you *which* syscall, of course, not what arguments it was
> called with, but that's something.
On my Linux:
$ perl -MPOSIX=pause -epause &
[2] 26855
$ ps -lp 26855
Warning: /boot/System.map-2.6.21.4-eeepc not parseable as a System.map
F S UID PID PPID C PRI NI ADDR SZ WCHAN TTY TIME CMD
0 S 1000 26855 1790 0 77 0 - 943 11ff41 pts/0 00:00:00 perl
I don't have access to a more conventional Linux right now, but I don't
recall seeing anything other than '-' and '?' listed under wchan. I'll
have to try to remember to give it a try.
Thanks,
Xho
------------------------------
Date: Tue, 28 Sep 2010 21:09:08 -0700 (PDT)
From: Jerry Krinock <jerry@ieee.org>
Subject: Re: Long script "just stops" sometime
Message-Id: <69dab57d-ba26-4f74-b67c-75134c3d82fe@z30g2000prg.googlegroups.com>
I really appreciate all the thought that went into this thread. But
the first solution seems to work=85
On Sep 24, 3:56=A0pm, Ben Morrow <b...@morrow.me.uk> wrote:
> Quoth Jerry Krinock <jerrykrin...@gmail.com>:
> Add the following somewhere early on:
>
> =A0 =A0 require Carp;
> =A0 =A0 $SIG{INFO} =3D sub { Carp::cluck("SIGINFO") };
> =A0 =A0 $SIG{QUIT} =3D sub { Carp::confess("SIGQUIT") };
>
> Now you can press ^T to get a backtrace, and ^\ to get a backtrace and
> kill the program.
Actually, works better than advertised. When I hit ^T, it prints a
backtrace to the console, and then, surprise!, the script starts
running again, and eventually exits success. This happened twice in
the last few days.
The backtrace tells me that it's sticking when I invoke IPC::Run to
invoke another perl script which I have written. I haven't dug into
it yet, because, well, it's not a big issue if all I need to is type
^T to un-stuck it. It might be mis-processing one little line of text
or something.
Thanks for all the help,
Jerry
------------------------------
Date: Tue, 28 Sep 2010 14:02:56 -0700 (PDT)
From: Mark <google@markginsburg.com>
Subject: Time::Format::time with $SIG{__DIE__} problem
Message-Id: <d22d203a-49dc-418b-802d-6cfc0793d8c8@l20g2000yqm.googlegroups.com>
When I added a $SIG{__DIE__} handler to code that uses
$Time::Format::time{}, the sig die handler code is called. I believe
this is happening during the evaluation of $Time::Format::time{}.
Without a $SIG{__DIE__} handler defined the code runs to completion.
Here is some code that illustrates the issue on my Windows XP
workstation.
Is there something I am doing wrong that is causing the sig die to
occur?
use strict;
use warnings;
use Time::Format;
$| = 1;
# Comment out next line for alternate case
$SIG{'__DIE__'} = sub {print("I'm dying.... Reason:
$_[0]\n");exit(1);};
logit("debug output\n");
print "Alive and well after calling logit.\n";
exit;
sub logit {
print $Time::Format::time{'yyyymmdd:hh:mm:ss '}, $_[0];
}
__END__
Ouput for case with sig die handler specified:
I'm dying.... Reason: Can't locate I18N/Langinfo.pm in @INC (@INC
contains: D:/Perl/site/lib D:/Perl/lib .) at (eval 1) line 31, <DATA>
line 1.
Ouput for case with no sig die handler specified:
20100928:13:58:45 debug output
Alive and well after calling logit.
------------------------------
Date: Tue, 28 Sep 2010 22:14:48 +0000 (UTC)
From: Ilya Zakharevich <nospam-abuse@ilyaz.org>
Subject: Re: Time::Format::time with $SIG{__DIE__} problem
Message-Id: <slrnia4q6o.dqi.nospam-abuse@powdermilk.math.berkeley.edu>
On 2010-09-28, Mark <google@markginsburg.com> wrote:
> $SIG{'__DIE__'} = sub {print("I'm dying.... Reason:
> $_[0]\n");exit(1);};
__DIE__ handlers should check $^S. Is not it LOUDLY documented?
Hope this helps,
Ilya
------------------------------
Date: Tue, 28 Sep 2010 17:15:04 -0700 (PDT)
From: Mark <google@markginsburg.com>
Subject: Re: Time::Format::time with $SIG{__DIE__} problem
Message-Id: <b9919652-3951-4189-a297-da77f50eb5ae@e14g2000yqe.googlegroups.com>
On Sep 28, 3:14=A0pm, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
> __DIE__ handlers should check $^S. Is not it LOUDLY documented?
I could not find anything in perlipc or perlvar about using $^S. I
could only find it's possible values documented in perlipc.
Perhaps someone would be kind enough to suggest a better place to
look?
I tried adding a check for $^S in the handler. It's value is 0 when
the handler is called. If I understand the docs correctly,
this means that the he handler is not being called due to an issue
with parsing code.
I am at a loss as to how I can use $^S to properly deal with handling
the sig die calls or what is causing the call to occur.
------------------------------
Date: Tue, 28 Sep 2010 20:28:22 -0700 (PDT)
From: "C.DeRykus" <derykus@gmail.com>
Subject: Re: Time::Format::time with $SIG{__DIE__} problem
Message-Id: <e03c4a24-10d7-4757-8cb0-f0d5f7e75c30@z34g2000pro.googlegroups.com>
On Sep 28, 5:15=A0pm, Mark <goo...@markginsburg.com> wrote:
> On Sep 28, 3:14=A0pm, Ilya Zakharevich <nospam-ab...@ilyaz.org> wrote:
>
> > __DIE__ handlers should check $^S. =A0Is not it LOUDLY documented?
>
> I could not find anything in perlipc or perlvar about using $^S. I
> could only find it's possible values documented in perlipc.
>
> Perhaps someone would be kind enough to suggest a better place to
> look?
>
> I tried adding a check for $^S in the handler. =A0It's value is 0 when
> the handler is called. =A0If I understand the docs correctly,
> this means that the he handler is not being called due to an issue
> with parsing code.
>
> I am at a loss as to how I can use $^S to properly deal with handling
> the sig die calls or what is causing the call to occur.
Hm, I see $^S set to 1 in the handler which
indicates the interpreter is executing an eval.
This workaround appears to make the message
go away but I'm not sure if it's advisable:
$SIG{'__DIE__'} =3D
sub { return if $^S; # ignore if eval
print("I'm dying.... Reason: $_[0]\n");
exit(1);
};
[ calling logit('') before the handler is seen
seems to work too. ]
--
Charles DeRykus
------------------------------
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:
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
Back issues are available via anonymous ftp from
ftp://cil-www.oce.orst.edu/pub/perl/old-digests.
#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 V11 Issue 3152
***************************************
