[28207] in Perl-Users-Digest
Perl-Users Digest, Issue: 9571 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Aug 7 18:06:05 2006
Date: Mon, 7 Aug 2006 15:05:11 -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, 7 Aug 2006 Volume: 10 Number: 9571
Today's topics:
B::Lint does not detect undefined subs <Alexander.Frink@Uni-Mainz.DE>
Re: B::Lint does not detect undefined subs <uri@stemsystems.com>
Re: B::Lint does not detect undefined subs <Alexander.Frink@Uni-Mainz.DE>
Re: B::Lint does not detect undefined subs <Alexander.Frink@Uni-Mainz.DE>
does it matter whether References headers are folded? <nobody@dizum.com>
Re: does it matter whether References headers are folde <rvtol+news@isolution.nl>
Re: does it matter whether References headers are folde <nobody@dizum.com>
Re: does it matter whether References headers are folde <rvtol+news@isolution.nl>
Re: does it matter whether References headers are folde <nobody@dizum.com>
Re: does it matter whether References headers are folde <nobody@bikikii.ath.cx.invalid>
Re: does it matter whether References headers are folde (Curt Welch)
Re: does it matter whether References headers are folde <rvtol+news@isolution.nl>
Re: does it matter whether References headers are folde <rvtol+news@isolution.nl>
Re: FAQ 3.14 How can I use X or Tk with Perl? <jgibson@mail.arc.nasa.gov>
Re: foreach aliasing, my variables, and visibility in s <benmorrow@tiscali.co.uk>
Re: Further to: Printing Hash Marks During File Downloa <hlarons@yahoo.com>
Re: how to "anonymize" Perl script before publishing it <nobody@dizum.com>
Re: How to "convert" a string into a variable name? <uri@stemsystems.com>
Re: how to automate a forced device uninstall <ToddMargoChester@invalid.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Mon, 7 Aug 2006 18:17:22 +0200
From: Alexander Frink <Alexander.Frink@Uni-Mainz.DE>
Subject: B::Lint does not detect undefined subs
Message-Id: <Pine.LNX.4.33.0608071803510.16227-100000@higgs.physik.uni-mainz.de>
Hi!
I tried to use lint to detect undefined subroutines in a Perl script, but
recent 5.8 versions seem to fail.
With Perl 5.6.1 on Linux, everything still works as expected:
$ perl -MO=Lint,all -e 'foo();'
Undefined subroutine foo called at -e line 1
-e syntax OK
But with 5.8.8 for Win32, 5.8.5 for Linux and 5.8.2 for AIX, the undefined
sub is not detected:
$ perl -MO=Lint,all -e 'foo();'
-e syntax OK
One difference is that the 5.6.1 version is single-threaded, whereas all
other versions to which I have access are multi-threaded. The B::Lint man
page says "This module doesn't work correctly on thread-enabled perls."
Is there a way to force Perl to single-threaded mode without recompiling?
Or is this simply a bug?
Regards,
Alex
--
Alexander Frink E-Mail: Alexander.Frink@Uni-Mainz.DE
Institut fuer Physik Phone: +49-6131-3923391
Johannes-Gutenberg-Universitaet
D-55099 Mainz, Germany
------------------------------
Date: Mon, 07 Aug 2006 13:31:16 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: B::Lint does not detect undefined subs
Message-Id: <x71wrsjvvf.fsf@mail.sysarch.com>
>>>>> "AF" == Alexander Frink <Alexander.Frink@Uni-Mainz.DE> writes:
AF> I tried to use lint to detect undefined subroutines in a Perl script, but
AF> recent 5.8 versions seem to fail.
AF> With Perl 5.6.1 on Linux, everything still works as expected:
AF> $ perl -MO=Lint,all -e 'foo();'
AF> Undefined subroutine foo called at -e line 1
AF> -e syntax OK
that is a runtime error and not likely found by Lint (i don't know that
module).
AF> But with 5.8.8 for Win32, 5.8.5 for Linux and 5.8.2 for AIX, the undefined
AF> sub is not detected:
AF> $ perl -MO=Lint,all -e 'foo();'
AF> -e syntax OK
that never RAN the code so no runtime error happens.
AF> One difference is that the 5.6.1 version is single-threaded, whereas all
AF> other versions to which I have access are multi-threaded. The B::Lint man
AF> page says "This module doesn't work correctly on thread-enabled perls."
AF> Is there a way to force Perl to single-threaded mode without recompiling?
AF> Or is this simply a bug?
i doubt it is something to do with threading. lint can't detect (all)
undefined subs since subs can be loaded and created at runtime. lint
type programs do surface analysis on the code and runtime issues like
missing subs are not part of their scope. so my guess is that lint fixed
a 'bug' in the newer version by not allowing the code to be actually
run. lint is like perl's -c option in that they don't intend to run the
code itself, just compile and check it for syntax or errors that lint
can find in the source code.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Mon, 7 Aug 2006 20:22:46 +0200
From: Alexander Frink <Alexander.Frink@Uni-Mainz.DE>
Subject: Re: B::Lint does not detect undefined subs
Message-Id: <Pine.LNX.4.33.0608072001080.20757-100000@higgs.physik.uni-mainz.de>
On Mon, 7 Aug 2006, Uri Guttman wrote:
> AF> $ perl -MO=Lint,all -e 'foo();'
> AF> Undefined subroutine foo called at -e line 1
> AF> -e syntax OK
>
> that is a runtime error and not likely found by Lint (i don't know that
> module).
B::Lint is part of Perl's standard library. As you can see, Perl 5.6.1
found that runtime error. But 5.8.x fail.
> that never RAN the code so no runtime error happens.
That's the purpose of Lint: find possible runtime errors without actually
running the program, even more than with -c, -w or -W. False alarms are
expected. The following program
eval '$a=5;';
print $a;
when run with -c or -w, gives a warning
Name "main::a" used only once: possible typo at xxx.pl line n.
although everything is fine at run time.
> i doubt it is something to do with threading. lint can't detect (all)
> undefined subs since subs can be loaded and created at runtime. lint
I know that it is possible to define functions at run time, e.g. with
eval, and there may be good reasons to do so, but the programs I want to
check should explicitly avoid such things. A function which cannot be
resolved at compile time is considered an error (e.g. due to a typo).
And according to the documentation, B::Lint is supposed to find exactly
this with the option 'undefined-subs' (and I am fine with the
restrictions):
This option warns whenever an undefined subroutine
is invoked. This option will only catch explic
itly invoked subroutines such as "foo()" and not
indirect invocations such as "&$subref()" or
"$obj->meth()". Note that some programs or modules
delay definition of subs until runtime by means of
the AUTOLOAD mechanism.
Regards,
Alex
--
Alexander Frink E-Mail: Alexander.Frink@Uni-Mainz.DE
Institut fuer Physik Phone: +49-6131-3923391
Johannes-Gutenberg-Universitaet
D-55099 Mainz, Germany
------------------------------
Date: Tue, 8 Aug 2006 00:01:40 +0200
From: Alexander Frink <Alexander.Frink@Uni-Mainz.DE>
Subject: Re: B::Lint does not detect undefined subs
Message-Id: <Pine.LNX.4.33.0608072356450.28311-100000@higgs.physik.uni-mainz.de>
On Mon, 7 Aug 2006, Alexander Frink wrote:
> One difference is that the 5.6.1 version is single-threaded, whereas all
> other versions to which I have access are multi-threaded. The B::Lint man
> page says "This module doesn't work correctly on thread-enabled perls."
Meanwhile I have compiled Perl 5.9.3 with and without thread support. The
version without thread support detects the undefined sub, the one with
threads does not.
Can anyone shed some light on the reasons behind?
And still the question: can I force Perl in unthreaded mode (because I
have to use the packaged, precompiled Perl on the target platform)?
Regards,
Alex
--
Alexander Frink E-Mail: Alexander.Frink@Uni-Mainz.DE
Institut fuer Physik Phone: +49-6131-3923391
Johannes-Gutenberg-Universitaet
D-55099 Mainz, Germany
------------------------------
Date: Mon, 7 Aug 2006 17:50:09 +0200 (CEST)
From: Nomen Nescio <nobody@dizum.com>
Subject: does it matter whether References headers are folded?
Message-Id: <2c0c58bebd78da6b816987b210060211@dizum.com>
RFC 1036 says the message-IDs in the References header should be
separated by a space, but it's quite common to see them folded
(separated by a newline and some spaces or a newline and a tab).
Does it matter?
Is either folded or unfolded better or worse than the other?
------------------------------
Date: Mon, 7 Aug 2006 18:23:19 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <eb80iq.ig.1@news.isolution.nl>
Nomen Nescio schreef:
> RFC 1036 says the message-IDs in the References header should be
> separated by a space
s/space/blank/
<quote>
2. Message Format
[...]
A standard USENET message consists of several header lines, followed
by a blank line, followed by the body of the message. Each header
line consist of a keyword, a colon, a blank, and some additional
information. [...] The Internet convention of
continuation header lines (beginning with a blank or tab) is
allowed.
</quote>
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Mon, 7 Aug 2006 19:50:03 +0200 (CEST)
From: Nomen Nescio <nobody@dizum.com>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <820f634292c5ad0af2c41d907080d130@dizum.com>
"Dr.Ruud" <rvtol+news@isolution.nl> wrote:
> Nomen Nescio schreef:
>
> > RFC 1036 says the message-IDs in the References header should be
> > separated by a space
>
> s/space/blank/
>
> <quote>
> 2. Message Format
> [...]
> A standard USENET message consists of several header lines, followed
> by a blank line, followed by the body of the message. Each header
> line consist of a keyword, a colon, a blank, and some additional
> information. [...] The Internet convention of
> continuation header lines (beginning with a blank or tab) is
> allowed.
> </quote>
Right, but are the two formats absolutely equal or is one
considerd a little better than the other?
------------------------------
Date: Mon, 7 Aug 2006 20:06:08 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <eb86kg.13c.1@news.isolution.nl>
Nomen Nescio schreef:
> Dr.Ruud:
>> Nomen Nescio:
>>> RFC 1036 says the message-IDs in the References header should be
>>> separated by a space
>>
>> s/space/blank/
>>
>> <quote>
>> 2. Message Format
>> [...]
>> A standard USENET message consists of several header lines,
>> followed by a blank line, followed by the body of the message.
>> Each header line consist of a keyword, a colon, a blank, and
>> some additional information. [...] The Internet convention of
>> continuation header lines (beginning with a blank or tab) is
>> allowed.
>> </quote>
>
> Right, but are the two formats absolutely equal or is one
> considerd a little better than the other?
Equal. Just don't put a fold directly after the "Keyword:". It is OK to
put each Message-ID on it's own line, but the first (the oldest) must be
on the same line as the "References: ".
You are even allowed to remove Message-IDs from the References header
field (to limit the total (unfolded) length), but certainly don't remove
the one-or-two oldest and newest ones (they are used for the "threaded
view" by many clients).
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Mon, 7 Aug 2006 21:30:05 +0200 (CEST)
From: Nomen Nescio <nobody@dizum.com>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <19c11783152d3abe977215b041560b24@dizum.com>
Nomen Nescio wrote:
> RFC 1036 says the message-IDs in the References header should be
> separated by a space, but it's quite common to see them folded
> (separated by a newline and some spaces or a newline and a tab).
Technically speaking, after a header reaches a certain length it *must*
be folded to prevent risk of breaking some clients/transports. And
either the space or tab method is acceptable.
=46rom an RFC point of view it doesn't matter.
=46rom an anonymity POV it might (you cross posted to APAS).
------------------------------
Date: 7 Aug 2006 20:21:48 -0000
From: Anonymous <nobody@bikikii.ath.cx.invalid>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <1K0ORU6738936.6401388889@anonymous.poster>
In article <2c0c58bebd78da6b816987b210060211@dizum.com>
Nomen Nescio <nobody@dizum.com> wrote:
>
> RFC 1036 says the message-IDs in the References header should be
> separated by a space, but it's quite common to see them folded
> (separated by a newline and some spaces or a newline and a tab).
>
> Does it matter?
>
> Is either folded or unfolded better or worse than the other?
It shouldn't matter, but there are times when it matters to some home-grown
applications. For example I've found that the BigApple mail2news software,
currently run by Bikikii I think, barfs on folded headers by only including
the first line. Other times we've seen non-folded headers truncated by a
limit on line length.
What to do.
------------------------------
Date: 07 Aug 2006 20:37:53 GMT
From: curt@kcwc.com (Curt Welch)
Subject: Re: does it matter whether References headers are folded?
Message-Id: <20060807164654.426$fg@newsreader.com>
Anonymous <nobody@bikikii.ath.cx.invalid> wrote:
> In article <2c0c58bebd78da6b816987b210060211@dizum.com>
> Nomen Nescio <nobody@dizum.com> wrote:
> >
> > RFC 1036 says the message-IDs in the References header should be
> > separated by a space, but it's quite common to see them folded
> > (separated by a newline and some spaces or a newline and a tab).
> >
> > Does it matter?
> >
> > Is either folded or unfolded better or worse than the other?
>
> It shouldn't matter, but there are times when it matters to some
> home-grown applications. For example I've found that the BigApple
> mail2news software, currently run by Bikikii I think, barfs on folded
> headers by only including the first line. Other times we've seen
> non-folded headers truncated by a limit on line length.
>
> What to do.
References: tend not to be folded and are intelligently truncated to 998
bytes by removing Message-IDs starting with the second on the line
(always leaving the first and as many of the last ones as possible).
Technically, you should be able to fold them but there was a time in the
past that it was felt it would break too many things if you folded the
References: line. I tend to suspect that's not an big issue anymore. The
998 limit was because some news software (INN at the time?) didn't allow
you to post lines longer than that. That was a limit after the folding
was removed so you couldn't "fix" the line length problem with folding.
I have no idea what INN and all the other news servers currently allow for
line lengths and whether the 998 limit is important anymore.
However, References: are one of the fields that are part of XOVER and
keeping References: lines more than 1000 bytes in length I think is just
wasteful at best since all the Message-IDs except the first and last are
generally redundant and of minor importance. So I think it is probably
wise to continue to use a truncation algorithm.
And, if I was writing a new reader, I wouldn't fold References: lines -
just because there's no advantage to doing it that I know of and a slight
risk it would cause an issue.
Here's some more thoughts about References: lines from the GNKSA:
http://www.xs4all.nl/~js/gnksa/gnksa.txt
7) Make sure followups contain valid References
When creating a followup, the software MUST create a "References: "
header line that contains, as its last element, the Message-ID of the
original article. An individual Message-ID MUST never be truncated.
The software MUST include at least three additional Message-IDs from
the original article's References header as well, if they are available.
Try to stay as close as possible to the spirit of "son-of-1036", which
states:
<<Followup agents SHOULD not shorten References headers. If
it is absolutely necessary to shorten the header, as a des-
perate last resort, a followup agent MAY do this by deleting
some of the message IDs. However, it MUST not delete the
first message ID, the last three message IDs (including that
of the immediate precursor), or any message ID mentioned in
the body of the followup.>>
However, it also says:
<<If it is absolutely necessary for an implementation to
impose a limit on the length of header lines, body lines, or
header logical lines, that limit shall be at least 1000
octets, including EOL representations.>>
So, bear in mind that news transports are not guaranteed to be able to
handle arbitrary long lines. Furthermore, keep in mind that some news
transports choke on continued (multi-line) "References: " headers.
Therefore, keep as many Message-IDs as will fit on a line starting with
"References: " with a maximum length of 998 characters. (An octet is a
byte of 8 bits, EOL representation takes two bytes.)
Exception: Damaged (truncated) Message-IDs SHOULD NOT be included.
Neither should `bogus' Message-IDs -- IDs that somehow got inserted (by
a misguided user, maybe) but don't belong to the thread.
Rationale: Threaded news-readers depend on References to do their magic.
This too is basic RFC compliance. Be as complete as the line length
limit allows, but do not propagate errors.
--
Curt Welch http://CurtWelch.Com/
curt@kcwc.com http://NewsReader.Com/
------------------------------
Date: Mon, 7 Aug 2006 23:26:06 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <eb8i89.ks.1@news.isolution.nl>
Curt Welch schreef:
> Anonymous <nobody@bikikii.ath.cx.invalid> wrote:
>> In article <2c0c58bebd78da6b816987b210060211@dizum.com>
>> Nomen Nescio <nobody@dizum.com> wrote:
>>>
>>> RFC 1036 says the message-IDs in the References header should be
>>> separated by a space, but it's quite common to see them folded
>>> (separated by a newline and some spaces or a newline and a tab).
>>>
>>> Does it matter?
>>>
>>> Is either folded or unfolded better or worse than the other?
>>
>> It shouldn't matter, but there are times when it matters to some
>> home-grown applications. For example I've found that the BigApple
>> mail2news software, currently run by Bikikii I think, barfs on folded
>> headers by only including the first line. Other times we've seen
>> non-folded headers truncated by a limit on line length.
>>
>> What to do.
>
> References: tend not to be folded and are intelligently truncated to
> 998 bytes by removing Message-IDs starting with the second on the
> line (always leaving the first and as many of the last ones as
> possible). Technically, you should be able to fold them but there
> was a time in the past that it was felt it would break too many
> things if you folded the References: line. I tend to suspect that's
> not an big issue anymore. The 998 limit was because some news
> software (INN at the time?) didn't allow you to post lines longer
> than that. That was a limit after the folding was removed so you
> couldn't "fix" the line length problem with folding.
>
> I have no idea what INN and all the other news servers currently
> allow for line lengths and whether the 998 limit is important anymore.
>
> However, References: are one of the fields that are part of XOVER and
> keeping References: lines more than 1000 bytes in length I think is
> just wasteful at best since all the Message-IDs except the first and
> last are generally redundant and of minor importance. So I think it
> is probably wise to continue to use a truncation algorithm.
>
> And, if I was writing a new reader, I wouldn't fold References: lines
> - just because there's no advantage to doing it that I know of and a
> slight risk it would cause an issue.
>
> Here's some more thoughts about References: lines from the GNKSA:
>
> http://www.xs4all.nl/~js/gnksa/gnksa.txt
>
> 7) Make sure followups contain valid References
>
> When creating a followup, the software MUST create a "References: "
> header line that contains, as its last element, the Message-ID of the
> original article. An individual Message-ID MUST never be truncated.
>
> The software MUST include at least three additional Message-IDs from
> the original article's References header as well, if they are
> available. Try to stay as close as possible to the spirit of
> "son-of-1036", which states:
>
> <<Followup agents SHOULD not shorten References headers. If
> it is absolutely necessary to shorten the header, as a des-
> perate last resort, a followup agent MAY do this by deleting
> some of the message IDs. However, it MUST not delete the
> first message ID, the last three message IDs (including that
> of the immediate precursor), or any message ID mentioned in
> the body of the followup.>>
>
> However, it also says:
>
> <<If it is absolutely necessary for an implementation to
> impose a limit on the length of header lines, body lines, or
> header logical lines, that limit shall be at least 1000
> octets, including EOL representations.>>
>
> So, bear in mind that news transports are not guaranteed to be able to
> handle arbitrary long lines. Furthermore, keep in mind that some news
> transports choke on continued (multi-line) "References: " headers.
>
> Therefore, keep as many Message-IDs as will fit on a line starting
> with "References: " with a maximum length of 998 characters. (An
> octet is a byte of 8 bits, EOL representation takes two bytes.)
>
> Exception: Damaged (truncated) Message-IDs SHOULD NOT be included.
> Neither should `bogus' Message-IDs -- IDs that somehow got inserted
> (by
> a misguided user, maybe) but don't belong to the thread.
>
> Rationale: Threaded news-readers depend on References to do their
> magic. This too is basic RFC compliance. Be as complete as the line
> length
> limit allows, but do not propagate errors.
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Mon, 7 Aug 2006 23:32:07 +0200
From: "Dr.Ruud" <rvtol+news@isolution.nl>
Subject: Re: does it matter whether References headers are folded?
Message-Id: <eb8ir3.1hk.1@news.isolution.nl>
Curt Welch schreef:
> [son-of-1036]
> <<Followup agents SHOULD not shorten References headers. If
> it is absolutely necessary to shorten the header, as a des-
> perate last resort, a followup agent MAY do this by deleting
> some of the message IDs. However, it MUST not delete the
> first message ID, the last three message IDs (including that
> of the immediate precursor), or any message ID mentioned in
> the body of the followup.>>
There is one (very theoretical) catch in there: a <message-id> can be
that long that a References: header field with four of them wouldn't fit
in 998 characters. But then you would just drop one more (the oldest of
the tail).
--
Affijn, Ruud
"Gewoon is een tijger."
------------------------------
Date: Mon, 07 Aug 2006 12:38:18 -0700
From: Jim Gibson <jgibson@mail.arc.nasa.gov>
Subject: Re: FAQ 3.14 How can I use X or Tk with Perl?
Message-Id: <070820061238188799%jgibson@mail.arc.nasa.gov>
In article <6t5hq3-i35.ln1@blue.stonehenge.com>, PerlFAQ Server
<brian@stonehenge.com> wrote:
> This is an excerpt from the latest version perlfaq3.pod, which
> comes with the standard Perl distribution. These postings aim to
> reduce the number of repeated questions as well as allow the community
> to review and update the answers. The latest version of the complete
> perlfaq is at http://faq.perl.org .
>
> --------------------------------------------------------------------
>
> 3.14: How can I use X or Tk with Perl?
>
> Tk is a completely Perl-based, object-oriented interface to the Tk
> toolkit that doesn't force you to use Tcl just to get at Tk. Sx is an
> interface to the Athena Widget set. Both are available from CPAN. See
> the directory
> http://www.cpan.org/modules/by-category/08_User_Interfaces/
Wouldn't this be less confusing as:
"The Perl module Tk.pm is a completely ... "
(unless there is possibly some previous context that clarifies that the
first 'Tk' in the sentence refers to a Perl module and the second
refers to the Tk toolkit.)
Posted Via Usenet.com Premium Usenet Newsgroup Services
----------------------------------------------------------
** SPEED ** RETENTION ** COMPLETION ** ANONYMITY **
----------------------------------------------------------
http://www.usenet.com
------------------------------
Date: Mon, 7 Aug 2006 17:25:04 +0100
From: Ben Morrow <benmorrow@tiscali.co.uk>
Subject: Re: foreach aliasing, my variables, and visibility in sub
Message-Id: <046kq3-p56.ln1@osiris.mauzo.dyndns.org>
Quoth anno4000@radom.zrz.tu-berlin.de:
> Stephan Titard <sgt19DELCAPS@tidNOSPAM.es> wrote in comp.lang.perl.misc:
> > Ben Morrow escribió:
> > > Quoth sgt19DELCAPS@tidNOSPAM.es:
>
> [...]
>
> > compare
> >
> > my $sub = sub {...};
> > my *glob = \&$sub;
>
> "*glob" can't be a lexical, "my" has got to go.
>
> Otherwise, "*glob = \&$sub" is exactly the same as "*glob = $sub", you're
> just de-referencing and taking a new reference.
>
> Okay, $sub could be overloading "&{}", in which case it would make a
> difference.
Just for pedantry's sake :)
$sub could also be a glob or a glob ref, in which case C<*glob = $sub>
would overwrite all of *glob whereas C<*glob = \&$sub> would just
overwrite *glob{CODE}.
Ben
--
Although few may originate a policy, we are all able to judge it.
Pericles of Athens, c.430 B.C.
benmorrow@tiscali.co.uk
------------------------------
Date: Mon, 07 Aug 2006 17:32:19 -0000
From: HaroldWho <hlarons@yahoo.com>
Subject: Re: Further to: Printing Hash Marks During File Download
Message-Id: <slrnedeu93.hu.hlarons@Beagle.mylocal.net>
On 06 Aug 2006 02:01:28 GMT, xhoster@gmail.com wrote in comp.lang.perl.misc:
> HaroldWho <hlarons@yahoo.com> wrote:
>> xhoster@gmail.com wrote on Aug 1 14:36:20 2006:
>> >>HaroldWho <hlarons@yahoo.com> wrote:
...
>> I tried a version of this using Time::HiRes, floating times, and
>> 'eval', thus:
...
>> Alas, the 'print #' operation seems to get buffered or something, and
>> does not appear until the 'long op' has finished.
>
> OK, so you need to unbuffer your output.
> See $| in perlvar or autoflush in IO::Handle
>
> However, I like the others' recommendations of using getfh and then
> interspersing reads with your own printing. (Which will still require you
> to unbuffer.) That way, the trickling arrival of marks means you are
> actually making progress, rather than having hung nonproductively. I
> didn't originally recommend that because it said the handle was tied, and
> for all I knew it read the entire message up front and just emulated a file
> handle on it; further investigation showed that that was not the case.
Once again, sincere thanks to you and DavidFilmer for sticking with me on
this. I had read about the $| var, but wasn't sure how it applied to my
case, before the bufered output thing arose.
Now I've got 2 more approaches to look into.
HW
--
Powered by Slackware 10.2 Linux -- Kernel 2.6.13
News Reader slrn 0.9.8.1
------------------------------
Date: Mon, 7 Aug 2006 15:20:07 +0200 (CEST)
From: Nomen Nescio <nobody@dizum.com>
Subject: Re: how to "anonymize" Perl script before publishing it?
Message-Id: <649908e98886f752839e688ad26535ea@dizum.com>
"Paul Lalli" <mritty@gmail.com> wrote:
> Well, for starters, take out any comments that identify you personally.
> After that, I would recommend reading
> perldoc perlstyle
> to see examples of generally considered *good* style.
>
> Then you can download the Perl::Tidy module and the perltidy utility
> (search CPAN) to reformat your code to a more standardized style...
Good ideas, thanks!
------------------------------
Date: Mon, 07 Aug 2006 13:04:11 -0400
From: Uri Guttman <uri@stemsystems.com>
Subject: Re: How to "convert" a string into a variable name?
Message-Id: <x7ac6gjx4k.fsf@mail.sysarch.com>
>>>>> "PL" == Paul Lalli <mritty@gmail.com> writes:
PL> perlistpaul wrote:
>> I give suggestion, but not mean I adhesive with it.
PL> I have *no* idea what that means. Clearly, English is not your first
PL> language, and that's fine. But the above is gibberish. "Adhesive"
PL> means sticky, as in tape or glue.
>> Symbolic reference is considered dangerous
PL> Yes.
>> Alternative is soft reference
PL> Uh. No. "Soft reference" is a synonym for "symbolic reference". Two
PL> different terms for the same thing.
i told him the same thing earlier in this thread. he doesn't seem to
read or comprehend our responses.
uri
--
Uri Guttman ------ uri@stemsystems.com -------- http://www.stemsystems.com
--Perl Consulting, Stem Development, Systems Architecture, Design and Coding-
Search or Offer Perl Jobs ---------------------------- http://jobs.perl.org
------------------------------
Date: Mon, 07 Aug 2006 09:54:52 -0700
From: Todd and Margo Chester <ToddMargoChester@invalid.com>
Subject: Re: how to automate a forced device uninstall
Message-Id: <eb7r5v$h0c$1@emma.aioe.org>
Clay Calvert wrote:
> On Sun, 06 Aug 2006 19:40:50 -0700, Todd and Margo Chester
> <ToddMargoChester@invalid.com> wrote:
>
>> Question: it there a way to automate this with a
>> batch file, Perl script, etc, such that the user only
>> has to click on a desktop icon to uninstall the drive?
>> (I am afraid the user will accidentally uninstall her
>> C: drive.)
>
> Devcon.exe, a free tool at Microsoft's site, can do this. It is their
> command line Device Manager.
> Clay Calvert
> CCalvert@Zanguru.com
> Replace "Z" with "L"
Cool! Thank you!
-T
------------------------------
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 9571
***************************************
