[30508] in Perl-Users-Digest
Perl-Users Digest, Issue: 1751 Volume: 11
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Jul 28 21:09:43 2008
Date: Mon, 28 Jul 2008 18:09:09 -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 Mon, 28 Jul 2008 Volume: 11 Number: 1751
Today's topics:
Append newline to files p19010101@yahoo.com
Re: Callback/hooks/events handler code needed <rcaputo@pobox.com>
Can I upload Perl program in unicode? <john1949@yahoo.com>
Re: Can I upload Perl program in unicode? <benkasminbullock@gmail.com>
Re: Can I upload Perl program in unicode? xhoster@gmail.com
Re: Can I upload Perl program in unicode? <hjp-usenet2@hjp.at>
Re: Can I upload Perl program in unicode? <bill@ts1000.us>
Re: dynamic scoped variables in the debugger (Greg Bacon)
Re: FAQ 4.2 Why is int() broken? <szrRE@szromanMO.comVE>
Re: FAQ 4.2 Why is int() broken? <hjp-usenet2@hjp.at>
Re: FAQ 4.2 Why is int() broken? <jwkenne@attglobal.net>
Re: Parallel search in Perl and other languages <glex_no-spam@qwest-spam-no.invalid>
Re: Parallel search in Perl and other languages <hjp-usenet2@hjp.at>
Re: Parallel search in Perl and other languages <john@castleamber.com>
Re: Parse::RecDescent problem regarding rule matching <brian.helterline@hp.com>
Re: Perl - approach to query https website for code & p <deepalicanada@gmail.com>
Re: Running in the background (via &) <Mark.Seger@hp.com>
Re: Running in the background (via &) <hjp-usenet2@hjp.at>
Re: Which NNTP module to use? (Greg Bacon)
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 28 Jul 2008 17:41:41 -0700 (PDT)
From: p19010101@yahoo.com
Subject: Append newline to files
Message-Id: <ace459af-771b-48d8-9746-bd0987dbae99@j1g2000prb.googlegroups.com>
I need to go through few hundred text files and append newline for
files that don't end with newline. So I have the following code to
read the file:
local $/ = undef;
open(handle, $filename) || die($!);
$content = <handle>;
close(handle);
Then use the following to check:
if($content =~ m/.*\n$/)
{
# file end with newline, do nothing
}
else
{
open(handle, ">>", $filename) || die($!);
print handle "\n";
close(handle);
}
The above code is working fine but I noticed some of the files have LF
as newline (probably originated from Unix) while the others are CRLF
(Windows). The perl script will run on a Windows machine with
ActiveState Perl 5.6, and \n is always CRLF when written to file.
Is there a way to tell Perl to append LF for Unix files and CRLF for
Windows files?
Or do I have to specifically look for \x0d\x0a and then append \x0d or
\x0d\x0a accordingly?
------------------------------
Date: Mon, 28 Jul 2008 15:56:42 GMT
From: Rocco Caputo <rcaputo@pobox.com>
Subject: Re: Callback/hooks/events handler code needed
Message-Id: <slrng8rr6q.7uq.rcaputo@eyrie.homenet>
On Sun, 27 Jul 2008 23:49:45 -0700 (PDT), doar.meyutar@gmail.com wrote:
>
> What I need is to have the option for other modules to register
> events, or subroutines to be called when events happen.
There's POE, which I'm particularly fond of. Also Event, and probably
others. Have you looked at http://search.cpan.org/ ?
--
Rocco Caputo - http://poe.perl.org/
------------------------------
Date: Mon, 28 Jul 2008 21:21:33 +0100
From: "John" <john1949@yahoo.com>
Subject: Can I upload Perl program in unicode?
Message-Id: <g6l9o7$12i$1@news.albasani.net>
Hi
Imagine that I have the following statement in a Perl program.
my $word = '??';
If I save the Perl program as 'UTF8' the characters remain.
If I save it in ASCII, the line appears as my $word = '????‘?';
Now, the problem is although I can save it as UTF8 the Perl program needs to
be in ASCII to be run
How do I get around this problem?
Regards
John
------------------------------
Date: Mon, 28 Jul 2008 21:13:18 +0000 (UTC)
From: Ben Bullock <benkasminbullock@gmail.com>
Subject: Re: Can I upload Perl program in unicode?
Message-Id: <g6lcpd$k08$1@cgi-ml.accsnet.ne.jp>
On Mon, 28 Jul 2008 21:21:33 +0100, John wrote:
> Imagine that I have the following statement in a Perl program.
>
> my $word = '??';
>
> If I save the Perl program as 'UTF8' the characters remain.
>
> If I save it in ASCII, the line appears as my $word = '????‘?';
>
> Now, the problem is although I can save it as UTF8 the Perl program needs to
> be in ASCII to be run
No, it doesn't.
> How do I get around this problem?
The above actually won't cause any problems to Perl.
Do you have a working example program which illustrates some problem
you've encountered?
If you want your string to be recognized as utf8 by Perl and encoded into
Perl's internal form, where characters like ã‚ are recognized as single
characters by things like /(.)/ or "length", you can
use utf8;
at the top of the script. But Perl will run without it.
If you need to use variables with non-ASCII names, like
my $ã‚ = "bingo";
then you also need to
use utf8;
But again, this is not necessary to make Perl run with text in UTF-8
encoding.
------------------------------
Date: 28 Jul 2008 21:28:08 GMT
From: xhoster@gmail.com
Subject: Re: Can I upload Perl program in unicode?
Message-Id: <20080728172815.411$nl@newsreader.com>
"John" <john1949@yahoo.com> wrote:
> Hi
>
> Imagine that I have the following statement in a Perl program.
>
> my $word = '??';
That's just two question marks, chr 63, right? If not, then what
is it?
> If I save the Perl program as 'UTF8' the characters remain.
"Save as UTF8" sounds like something a word processor would do.
We don't know what word processor you are using.
>
> If I save it in ASCII, the line appears as my $word = '????‘?';
Is that equivalent to the below?
join "", chr(65),chr(65),chr(65),chr(65),chr(145),chr(65);
> Now, the problem is although I can save it as UTF8 the Perl program needs
> to be in ASCII to be run
What makes you think that? What errors are you getting?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
The costs of publication of this article were defrayed in part by the
payment of page charges. This article must therefore be hereby marked
advertisement in accordance with 18 U.S.C. Section 1734 solely to indicate
this fact.
------------------------------
Date: Mon, 28 Jul 2008 23:54:13 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Can I upload Perl program in unicode?
Message-Id: <slrng8sg05.td7.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-28 20:21, John <john1949@yahoo.com> wrote:
> Imagine that I have the following statement in a Perl program.
>
> my $word = '??';
These are two question marks. I suppose that should have been something
else. If you want to write non-ASCII characters in your postings, please
use a newsreader which is able to do so.
> If I save the Perl program as 'UTF8' the characters remain.
>
> If I save it in ASCII, the line appears as my $word = '????‘?';
>
> Now, the problem is although I can save it as UTF8 the Perl program needs to
> be in ASCII to be run
Why? The perl interpreter is perfectly fine with scripts in UTF-8.
> How do I get around this problem?
I could tell you, but then I'd have to kill you.
No, seriously, you seem to be lacking some basics about perl character
strings, so I'll refer you to Juerd's rather good Unicode tutorial:
http://juerd.nl/site.plp/perluniadvice
hp
------------------------------
Date: Mon, 28 Jul 2008 17:24:52 -0700 (PDT)
From: Bill H <bill@ts1000.us>
Subject: Re: Can I upload Perl program in unicode?
Message-Id: <fe7877a3-6f82-4e6d-a8b3-49ee2fa4e40e@27g2000hsf.googlegroups.com>
On Jul 28, 5:54=A0pm, "Peter J. Holzer" <hjp-usen...@hjp.at> wrote:
> On 2008-07-28 20:21, John <john1...@yahoo.com> wrote:
>
> > Imagine that I have the following statement in a Perl program.
>
> > my $word =3D '??';
>
> These are two question marks. I suppose that should have been something
> else. If you want to write non-ASCII characters in your postings, please
> use a newsreader which is able to do so.
>
> > If I save the Perl program as 'UTF8' the characters remain.
>
> > If I save it in ASCII, the line appears as my $word =3D '????=91?';
>
> > Now, the problem is although I can save it as UTF8 the Perl program nee=
ds to
> > be in ASCII to be run
>
> Why? The perl interpreter is perfectly fine with scripts in UTF-8.
>
> > How do I get around this problem?
>
> I could tell you, but then I'd have to kill you.
>
> No, seriously, you seem to be lacking some basics about perl character
> strings, so I'll refer you to Juerd's rather good Unicode tutorial:http:/=
/juerd.nl/site.plp/perluniadvice
>
> =A0 =A0 =A0 =A0 hp
I think - and I could be wrong here, John is writing his code using
something like Notepad that warns you about saving in utf or not. If
you don't save in utf the characters go away. It may be that he saves
in utf and then when uploading it is messed up by his ftp program.
Then again I could be completly wrong here.
Bill H
------------------------------
Date: Mon, 28 Jul 2008 11:36:58 -0500
From: gbacon@hiwaay.net (Greg Bacon)
Subject: Re: dynamic scoped variables in the debugger
Message-Id: <pvadncJN9ZY3aBDVnZ2dnUVZ_hqdnZ2d@posted.hiwaay2>
In article <hbajk.8629$vn7.7339@flpi147.ffdc.sbc.com>,
Nathan <user@serverrb.net> wrote:
: Thanks Xho, I vaguely suspected something along those lines, but I
: guess I underestimated how "special" the special variables are. Perl
: gives you everything you need except consistency. :)
As indicated in the perlvar documentation on $&, it's a hack
to improve performance.
Good style uses capture variables such as $&, $`, $', and $1
only after you know you have a match, e.g.,
#! /usr/bin/perl
$_ = "foo";
if (/foo/) {
print $&, "\n"
}
Greg
--
That's the difference between governments and individuals. Governments
don't care, individuals do.
-- Mark Twain
------------------------------
Date: Mon, 28 Jul 2008 10:56:39 -0700
From: "szr" <szrRE@szromanMO.comVE>
Subject: Re: FAQ 4.2 Why is int() broken?
Message-Id: <g6l22k02den@news4.newsguy.com>
Peter J. Holzer wrote:
> On 2008-07-28 06:12, Jürgen Exner <jurgenex@hotmail.com> wrote:
>> "szr" <szrRE@szromanMO.comVE> wrote:
>>> Peter J. Holzer wrote:
>>>> Please get it into your head that extra precision *does* *not*
>>>> solve this problem. To express 1/10 in binary you need an infinite
>>>> number of digits, just like you need an infinite number of digits
>>>> to express 1/3 in decimal.
>>>
>>> Maybe you meant to write something else, as 1/10 is 0.1 and does not
>>> require an infinite number of digits;
>>
>> Yes, it does.
>
> It doesn't, but I didn't write that. I wrote it takes an infinite
> number of *binary* digits.
>
> In binary, 1/10 is 0.00011001100110011...
For some reason I thought that applied to decimal expresses that
repeated infinately, like 1/3 => .3333..., not decimals with a fixed
number of dibits, which 1/0 => 0.1 is:
$ perl -e 'my $x = 1/10; print unpack("b64", pack("d", $x)), "\n"'
0101100110011001100110011001100110011001100110011001110111111100
$ perl -e 'my $x = 1/2; print unpack("b64", pack("d", $x)), "\n"'
0000000000000000000000000000000000000000000000000000011111111100
$ perl -e 'my $x = 1/4; print unpack("b64", pack("d", $x)), "\n"'
0000000000000000000000000000000000000000000000000000101111111100
$ perl -e 'my $x = 1/8; print unpack("b64", pack("d", $x)), "\n"'
0000000000000000000000000000000000000000000000000000001111111100
I guess you never know when something you've over looked or something
you thought you knew can surprise you. :-)
>>> it needs just one decimal digit
>>
>> Irrelevant because your typical computer does not use decimal numbers
>> but binary numbers, just like Peter said.
>
> Actually, I didn't write what "a typical computer" uses, just what
> happens when a binary system is used (which is what perl uses on most
> (all?) platforms - COBOL uses normally uses decimal).
Even among different types of computers floating point calculations are
not all done the same. For instance, I have a graphing calculator, which
is essentially tiny computer with a 6 MHz cpu and yet it can do many
floating point calculations more accurately than my dual core cpu
desktop. Granted, it's a calculator, but I have often wondered why it
seems to be able to handle such calculations better than a CPU that's
over 400 times faster.
>>> Secondly, for expressions like 1/3, yes, the floating point
>>> (decimal) form cannot be fully expressed in binary. However, in the
>>> form of a rational number, it can be stored in an accurate binary
>>> form,
>>
>> No, it cannot. Neither as a decimal number nor as a binary number.
>
> Actually it can, at least if you translate the mathematical definition
> of a rational number into the straightforward implementation of
> storing two integers: (1, 3) in this case.
Yes this is what I meant.
>>> as you're
>>> really storing integers - the numerator and the denominator -
>>
>> That is not a number but an expresssion. Mathematically they may be
>> the same. However for actual computations they are not as any
>> introduction to Computer Numerics will tell you.
>
> It isn't much different from a floating point number, which is also
> stored as two integers (m, e) where the value is m*2^(e-b).
Good to know.
>>> although I'm not sure if that would be faster or slower than actual
>>> floating point calculations; I've never done the numbers, and I'm
>>> sure it may vary depending on the processor, but I have seen
>>> libraries,
>>> such as in C or C++, that use rational instead of floating point
>>> numbers.
>
> There is also one in Perl and I already mentioned it: Math::BigRat
> resp. bigrat. That almost certainly is slow, because it not only uses
> rational numbers, it also uses arbitrary precision. (But I've never
> really used it so I don't know).
Ah yes, I forgot about that one.
>>> If what you're after is accurate math, than representing your
>>> numbers as rational (n/d) seems to be a rather trivial way of
>>> achieving that; the math part most people learned in basic
>>> arithmetic. I would think the hardest part would be writing an
>>> efficient reduction algorithm, to, for example, turn 10/18 into 5/9.
>>
>> Smallest common demoninator, rather simple.
I said it would have been the hardest part, not that it was actually
difficult :-)
> Yup, was probably my third or fourth BASIC program. Used as an example
> to introduce GOTO ;-).
I think we've all had t owrite such algorithums at some point :-)
--
szr
------------------------------
Date: Mon, 28 Jul 2008 23:44:06 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: FAQ 4.2 Why is int() broken?
Message-Id: <slrng8sfd6.td7.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-28 17:56, szr <szrRE@szromanMO.comVE> wrote:
> Peter J. Holzer wrote:
>> On 2008-07-28 06:12, Jürgen Exner <jurgenex@hotmail.com> wrote:
>>> "szr" <szrRE@szromanMO.comVE> wrote:
>>>> Peter J. Holzer wrote:
>>>>> Please get it into your head that extra precision *does* *not*
>>>>> solve this problem. To express 1/10 in binary you need an infinite
>>>>> number of digits, just like you need an infinite number of digits
>>>>> to express 1/3 in decimal.
>>>>
>>>> Maybe you meant to write something else, as 1/10 is 0.1 and does not
>>>> require an infinite number of digits;
>>>
>>> Yes, it does.
>>
>> It doesn't, but I didn't write that. I wrote it takes an infinite
>> number of *binary* digits.
>>
>> In binary, 1/10 is 0.00011001100110011...
>
>
> For some reason I thought that applied to decimal expresses that
> repeated infinately, like 1/3 => .3333..., not decimals with a fixed
> number of dibits, which 1/0 => 0.1 is:
>
> $ perl -e 'my $x = 1/10; print unpack("b64", pack("d", $x)), "\n"'
> 0101100110011001100110011001100110011001100110011001110111111100
<--><--><--><--><--><--><--><--><--><--><--><-->
Um, the repeating pattern is clearly visible here. The pattern is
broken on the left side because of rounding (you printed the pattern in
little endian, so the least significant digit is on the left and the,
er, binary point is just to the right of the rightmost ">" I made).
>
> $ perl -e 'my $x = 1/2; print unpack("b64", pack("d", $x)), "\n"'
> 0000000000000000000000000000000000000000000000000000011111111100
>
> $ perl -e 'my $x = 1/4; print unpack("b64", pack("d", $x)), "\n"'
> 0000000000000000000000000000000000000000000000000000101111111100
>
> $ perl -e 'my $x = 1/8; print unpack("b64", pack("d", $x)), "\n"'
> 0000000000000000000000000000000000000000000000000000001111111100
1/2, 1/4, 1/8 are all exactly representable in binary, because they are
integral multiples of powers of two. 1/10 is not, because it is not an
integral multiple of powers of two. 1/3 is not representable in decimal
because it is not an integral multiple of a power of 10. And 1/2 is not
representable in base-15 because it is not an integral multiple of a
power of 15 (but 1/3 and 1/5 are). For any given base, there are always
only a small (but infinite :-)) number of fraction which are
representable in that base.
>>>> it needs just one decimal digit
>>>
>>> Irrelevant because your typical computer does not use decimal numbers
>>> but binary numbers, just like Peter said.
>>
>> Actually, I didn't write what "a typical computer" uses, just what
>> happens when a binary system is used (which is what perl uses on most
>> (all?) platforms - COBOL uses normally uses decimal).
>
> Even among different types of computers floating point calculations are
> not all done the same. For instance, I have a graphing calculator, which
> is essentially tiny computer with a 6 MHz cpu and yet it can do many
> floating point calculations more accurately than my dual core cpu
> desktop.
I'm not up to date with calculators (the last one I bought was an HP-48
20 years ago), but frankly, I doubt that it is more accurate. It has
probably less than 15 digits of mantissa. It probably does its
computations in decimal, which makes them even less accurate, but the
errors *match* *your* *expectations*, so you don't notice then.
> Granted, it's a calculator, but I have often wondered why it
> seems to be able to handle such calculations better than a CPU that's
> over 400 times faster.
Different target. Calculators can be slow - they do only primitive
computations, and if they finish them in a short but noticable time its
still "fast enough". A modern CPU is supposed to be able to do hundreds
of millions such computations per second. Calculators are also rarely
used for computations where accuracy is much of an issue - 8 or 12
digits are enough. But they are used by people who expect 0.1 * 10 to be
1.0 but aren't overly surprised if 1/3*3 is 0.9999999.
In short it is able to "handle such calculations" because it has been
designed to do so. Floating point hardware has been designed to give the
most accurate result in a very short time. You can always implement
decimal arithmetic yourself or use a library[1] - it will still be a lot
faster than your calculator.
hp
[1] Incidentally, I know of one modern processor (the IBM Power6) which
implements full decimal floating point arithmetic in hardware.
------------------------------
Date: Mon, 28 Jul 2008 12:47:15 -0400
From: John W Kennedy <jwkenne@attglobal.net>
Subject: Re: FAQ 4.2 Why is int() broken?
Message-Id: <488e4757$1$20942$607ed4bc@cv.net>
Jürgen Exner wrote:
> Again, your typical computer does not use decimal numbers but binary
> numbers. There have been a few CPUs with build-in support for decimal
> calculations, but they weren't very successful.
I would not call the IBM 360/370/4300/390/zArchitecture series, nor the
IBM 3/3x/AS400/iSeries, nor, for that matter, the old 702/705/7080,
1401/1440/1460, 1410/7010, 650/707x, and 1620/1710 series, "not very
successful". For that matter, Intel has had support for decimal from the
beginning, though it's never been popular.
Moreover, IEEE-754r specifies decimal floating point, alongside the
binary floating point introduced by the original IEEE-754. IBM
zArchitecture, for one, already implements it.
>>> need to express rational numbers exactly, use rational numbers.
> I suppose you meant "use fractions".
"Rational numbers" is the usual term in English when speaking of
computer systems (normally software) that use arbitrary common fractions.
--
John W. Kennedy
"Only an idiot fights a war on two fronts. Only the heir to the
throne of the kingdom of idiots would fight a war on twelve fronts"
-- J. Michael Straczynski. "Babylon 5", "Ceremonies of Light and Dark"
------------------------------
Date: Mon, 28 Jul 2008 11:39:17 -0500
From: "J. Gleixner" <glex_no-spam@qwest-spam-no.invalid>
Subject: Re: Parallel search in Perl and other languages
Message-Id: <488df635$0$89389$815e3792@news.qwest.net>
Peter J. Holzer wrote:
> I seem to be completely unable to find the right keywords to feed into
> google, but I vaguely remember that it was mentioned in this group, so
> I'm asking here in the hope that somebody has better memory than me:
>
> Some guy has programmed a relatively simple task (I'm almost but not
> quite sure it was a search in a file) using multiple processes/threads
> in several languages to show that even for such tasks multiprocessing
> gives you better performance. Other people contributed equivalent
> programs in other languages, so he now has a nice collection of one or
> two dozen implementations of the same task in different languages. Last
> time I looked, the Perl implementation was the fastest.
>
> Does anyone remember this, and if so, did you bychance bookmark the
> site?
Is this what you're looking for?
Wide Finder Project
http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results
------------------------------
Date: Mon, 28 Jul 2008 19:29:31 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Parallel search in Perl and other languages
Message-Id: <slrng8s0fr.rte.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-28 16:39, J. Gleixner <glex_no-spam@qwest-spam-no.invalid> wrote:
> Peter J. Holzer wrote:
>> Some guy has programmed a relatively simple task (I'm almost but not
>> quite sure it was a search in a file) using multiple processes/threads
>> in several languages to show that even for such tasks multiprocessing
>> gives you better performance. Other people contributed equivalent
>> programs in other languages, so he now has a nice collection of one or
>> two dozen implementations of the same task in different languages. Last
>> time I looked, the Perl implementation was the fastest.
>>
>> Does anyone remember this, and if so, did you bychance bookmark the
>> site?
>
> Is this what you're looking for?
>
> Wide Finder Project
>
> http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results
Yes, that's it.
Thanks a lot,
hp
------------------------------
Date: 28 Jul 2008 22:39:52 GMT
From: John Bokma <john@castleamber.com>
Subject: Re: Parallel search in Perl and other languages
Message-Id: <Xns9AE9B3B1BCC14castleamber@130.133.1.4>
"J. Gleixner" <glex_no-spam@qwest-spam-no.invalid> wrote:
> Wide Finder Project
>
> http://www.tbray.org/ongoing/When/200x/2007/10/30/WF-Results
Thanks, and thanks Peter for reminding me of a site I /should have/
bookmarked (or better: added to my local wiki).
--
John
http://johnbokma.com/perl/
------------------------------
Date: Mon, 28 Jul 2008 14:05:57 -0700
From: Brian Helterlilne <brian.helterline@hp.com>
Subject: Re: Parse::RecDescent problem regarding rule matching
Message-Id: <g6lcbj$671$1@usenet01.boi.hp.com>
Rui Maciel wrote:
> I'm a Perl newbie and I've started to look into the Parse::RecDescent
> module. Meanwhile I've stumbled on a rule matching problem. I've defined
> a couple of rules to be able to deal with two different types of numbers:
> integers and decimal fractions with a single decimal place. The problem
> is that RecDescent returns false positives by matching the integer rule
> on decimal fraction numbers.
>
> As far as I can tell, that could only happen if somehow RecDescent
> doesn't make any use of any terminal symbol to specify if the rule really
> matches a pattern, which I believe could lead to a lot of false positives.
>
> So, am I missing something or is there no solution to this problem?
Rules match in the order give. Different productions within a rule are
matched in the order given. RecDescent does not try to match the
"longest" production, only the first match succeeds. This means you
need to order your productions appropriately.
given the following rules, integer would always match before fraction in
the 'number' rule but the 'number2' rule would work correctly - it would
try to match a fraction and if that failed, it would try to match an
integer.
integer: \d{1,2}
fraction: \d{1,2}\.\d
number: integer | fraction
number2: fraction | integer
[test coded snipped]
--
-brian
------------------------------
Date: Mon, 28 Jul 2008 14:43:40 -0700 (PDT)
From: deep <deepalicanada@gmail.com>
Subject: Re: Perl - approach to query https website for code & parsing xml response
Message-Id: <8fdc37f2-2181-4c83-bcdb-3e3ce940d378@d77g2000hsb.googlegroups.com>
For some reason my reply didn't get posted, so trying agin.
Hi Zak
That indeed worked. Thanks for your help in identifying fundamental
issue with the use of wrong module. It solved the problem.
regards,
Deep
------------------------------
Date: Mon, 28 Jul 2008 09:45:25 -0400
From: Mark Seger <Mark.Seger@hp.com>
Subject: Re: Running in the background (via &)
Message-Id: <488DCD75.80101@hp.com>
I have a solution, based on an example in the perl cookbook by calling
iloctl directly to get the terminal height and it seems to work in both
foreground and background. Can I count on the ioctls.ph file being
present in asm? Is there somewhere else I should look for it?
#!/usr/bin/perl -w
require "asm/ioctls.ph";
my $winsize="\0" x 8;
if (ioctl(STDOUT, TIOCGWINSZ(), $winsize)) {
($rows)=(unpack('S4', $winsize))[0];
}
else {
print "ERROR\n";
}
print "rows: $rows\n";
-mark
------------------------------
Date: Mon, 28 Jul 2008 16:42:19 +0200
From: "Peter J. Holzer" <hjp-usenet2@hjp.at>
Subject: Re: Running in the background (via &)
Message-Id: <slrng8rmmg.pia.hjp-usenet2@hrunkner.hjp.at>
On 2008-07-28 11:55, Mark Seger <Mark.Seger@hp.com> wrote:
> \
>> Would it help to have an indication whether you're in the foreground or
>> in the background?
>> Usually background processes aren't connected to a terminal, most
>> important, STDIN won't be connected to a terminal
This is wrong in general.
>> as then two processes (the current "foreground" process and the
>> "background" process) contend for the input from the keyboard,
That's why about 20 years ago, Unixes started to stop background
processes from reading from the terminal (see the SIGTTIN signal).
>> so you could check whether STDIN is a
>> terminal.
Won't work.
> that's what I thought and so did a -t STDIN, but it shows true whether
> in the foreground or background.
Right. STDIN doesn't change. You can flip a process between foreground
and background (in most shells with the conveniently named commands "fg"
and "bg"), but it would be rather messy if that changed an open file
descriptor. What changes is whether the process group is the foreground
process group of the controlling terminal. The place to look for
POSIX (=UNIX) specific functionality is the POSIX module:
| getpgrp This is identical to Perl’s builtin "getpgrp()" function for
| returning the process group identifier of the current process,
| see "getpgrp" in perlfunc.
[...]
| tcgetpgrp
| This is identical to the C function "tcgetpgrp()" for returning
| the process group identifier of the foreground process group of
| the controlling terminal.
If they are the same we should be in the foreground:
% perl -MPOSIX -le 'print getpgrp() == tcgetpgrp(STDIN) ? "foreground" : "background"'
foreground
% perl -MPOSIX -le 'print getpgrp() == tcgetpgrp(STDIN) ? "foreground" : "background"' & sleep 1
[1] 23462
background
[1] + done perl -MPOSIX -le
Looks good.
hp
------------------------------
Date: Mon, 28 Jul 2008 11:26:56 -0500
From: gbacon@hiwaay.net (Greg Bacon)
Subject: Re: Which NNTP module to use?
Message-Id: <9PmdnUKHj-TNbhDVnZ2dnUVZ_gqdnZ2d@posted.hiwaay2>
In article <u8udndILceijoBDVnZ2dnUVZ_uLinZ2d@comcast.com>,
nospam <no@spam.com> wrote:
: Is there a defacto standard for NNTP perl modules? Some time ago I
: used News::NNTPClient, and I've just installed News::NNTP. Is there a
: preferred NNTP module I should be using?
You didn't mention the standard Net::NNTP module. Is it missing
some feature that you need?
Greg
--
The great mass of men lead lives of quiet desperation.
-- Henry David Thoreau
------------------------------
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 V11 Issue 1751
***************************************
