[25398] in Perl-Users-Digest
Perl-Users Digest, Issue: 7643 Volume: 10
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Thu Jan 13 18:10:27 2005
Date: Thu, 13 Jan 2005 15:10:17 -0800 (PST)
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Thu, 13 Jan 2005 Volume: 10 Number: 7643
Today's topics:
Re: convention regarding lexical filehandles <spamtrap@dot-app.org>
Re: convention regarding lexical filehandles <abigail@abigail.nl>
Re: convention regarding lexical filehandles <abigail@abigail.nl>
Re: Determining which module exported a specific functi <abigail@abigail.nl>
Re: Format With Color Output <todd.ryan@lexisnexis.com>
Formmail Question <deepiceman@yahoo.com>
Re: Formmail Question <spamtrap@dot-app.org>
Re: Random Functionality <sbryce@scottbryce.com>
Re: Random Functionality <xx087@freenet.carleton.ca>
Re: Random Functionality <bart.lateur@pandora.be>
Re: Random Functionality xhoster@gmail.com
Regular expression lookahead question <gregaryh@juno.com>
Unix-format text from STDOUT under Windows (AcitvePerl <jimmonty@gmail.com>
Re: Unix-format text from STDOUT under Windows (AcitveP <mritty@gmail.com>
Re: Unix-format text from STDOUT under Windows (AcitveP <shawn.corey@sympatico.ca>
Re: Unix-format text from STDOUT under Windows (AcitveP <jimmonty@gmail.com>
Re: Unix-format text from STDOUT under Windows (AcitveP <mjcarman@mchsi.com>
Digest Administrivia (Last modified: 6 Apr 01) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Thu, 13 Jan 2005 15:58:15 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: convention regarding lexical filehandles
Message-Id: <NuGdnX-8JPJ0fXvcRVn-hw@adelphia.com>
Paul Lalli wrote:
> This one I've never really understood. I'm going to go take a look at
> perlopentut, but if you'd care to explain in what way the two-argument
> form is dangerous, I'd appreciate it.
Think about what might happen if one of your users names a file ">file.txt",
and your app uses "open HANDLE, $filename" to open $filename for reading.
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: 13 Jan 2005 22:37:00 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: convention regarding lexical filehandles
Message-Id: <slrncudu0c.ucb.abigail@alexandra.abigail.nl>
Paul Lalli (mritty@gmail.com) wrote on MMMMCLIII September MCMXCIII in
<URL:news:dPyFd.16$Dz2.4@trndny09>:
:) Prior to the invention of lexical file handles, I'd always seen the
:) convention that filehandles should be given in all capital letters:
:) open FILE, 'file.txt' or die "...";
:)
:) Now that we have lexical file handles
You're wrong here. Perl doesn't have lexical file handles.
What modern perls have, is autovivification of references to
filehandles. That's the reason that
open my $file, ...
works. References to filehandles have worked for quite some time.
my $fh = \*FILE;
open my $fh, ...
works going back to at least 5.004_04. Perhaps further back, but I don't
have older perls currently installed on my system.
:) I'm wondering if there is a
:) consensus as towards this convention. Which of the following looks more
:) 'right':
There aren't many conventions in Perl which have reached 'consensus'.
:)
:) open $file, 'file.txt' or die "...";
:) or
:) open $FILE, 'file.txt' or die "...";
:)
:) Obviously, I know that both work, but I'd like to get opinions on the
:) Best Practice way to do things.
I write 'open my $file', using a lowercase variable, because it's a
reference (scalar), and I tend to write non-magical scalar that I'm
not using as a constant in all lowercase.
Abigail
--
perl -wlpe '}$_=$.;{' file # Count the number of lines.
------------------------------
Date: 13 Jan 2005 22:42:51 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: convention regarding lexical filehandles
Message-Id: <slrncudubb.ucb.abigail@alexandra.abigail.nl>
Brian McCauley (nobull@mail.com) wrote on MMMMCLIII September MCMXCIII in
<URL:news:cs6egv$mqa$1@sun3.bham.ac.uk>:
{}
{} Conceptually open() takes three arguments (or more/less in pipe mode).
Nah. Conceptually, open() takes two arguments: a file and a mode, and
returns a filehandle. The fact open() takes a filehandle as argument
means it's non-intuitive already. The number of arguments it takes can't
solve that. ;-)
{} The legacy two argument form of open() that combines the mode and
{} filename into one argument is a wart on the language and using it is a
{} dangerous habit that will burn you one day.
Yeah, but coding Perl is a dangerous habit that will burn you one day
as well. I've been burned many times.
I find the two arg form of 'open' useful. And no, I don't create file
names that start with '|', '<' or '>', nor filenames that end with a
'|'. Nor do I include leading or trailing spaces in my filenames.
Abigail
--
# Perl 5.6.0 broke this.
%0=map{reverse+chop,$_}ABC,ACB,BAC,BCA,CAB,CBA;$_=shift().AC;1while+s/(\d+)((.)
(.))/($0=$1-1)?"$0$3$0{$2}1$2$0$0{$2}$4":"$3 => $4\n"/xeg;print#Towers of Hanoi
------------------------------
Date: 13 Jan 2005 20:52:58 GMT
From: Abigail <abigail@abigail.nl>
Subject: Re: Determining which module exported a specific function.
Message-Id: <slrncudnt9.ucb.abigail@alexandra.abigail.nl>
Sisyphus (kalinaubears@iinet.net.au) wrote on MMMMCLIII September
MCMXCIII in <URL:news:41e5fdf7$0$19452$5a62ac22@per-qv1-newsreader-01.iinet.net.au>:
)) Hi,
))
)) Let's say I'm working through a script, trying to diagnose a problem,
)) and there's a function foo() that I don't know much about. I wish to
)) consult the documentation on foo(), but I don't know which of the 20
)) loaded modules exported it. I know 'foo' is in @EXPORT_OK of one of
)) those 20 modules - but I don't know *which* module.
))
)) How can I determine quickly and easily which module's documentation I
)) need to consult ?
))
)) Or, to rephrase, how can I quickly determine an imported function's
)) fully qualified package name.
Add a print statement to Exporter.
Well, that's how I would do it.
Abigail
--
INIT {print "Perl " }
BEGIN {print "Just " }
CHECK {print "another "}
END {print "Hacker\n"}
------------------------------
Date: 13 Jan 2005 12:35:46 -0800
From: "Tlexnex" <todd.ryan@lexisnexis.com>
Subject: Re: Format With Color Output
Message-Id: <1105648546.636707.32970@f14g2000cwb.googlegroups.com>
Muller wrote:
> Hi,
> I am using FORMAT Comand to beautify the conlsole output using
"write",
> and I use Win32::Console to add colors, I want only cirtain Variables
> defined in FORMAT to get color effect,
> if I change the color value like
> $Console->Attr($Color);
> write;
> then complete FORMAT output is changed,
I'm trying to handle colors within formats as well, did you find a
resolution to this? I want to create a logging standard for my script
processes that resembles the Linux boot process - easy to follow and
read. There does not seem to be a clean way to do this in Perl..
Thanks,
Todd
------------------------------
Date: 13 Jan 2005 14:18:30 -0800
From: "Deepster" <deepiceman@yahoo.com>
Subject: Formmail Question
Message-Id: <1105654710.820168.322060@c13g2000cwb.googlegroups.com>
Hi all,
Newbie question about formmail program here... I want to use formmail
on my contact us form, which has all the normal fields, name, address
and things like that. I want to check that the names and emails fields
are properly filled out when they click submit. I have the functions
working but how can I run both the functions and process the form when
the users click on submit button?
I am thinking, can I call formmail from inside the function instead of
the action?
Thanks
Deep
------------------------------
Date: Thu, 13 Jan 2005 17:25:40 -0500
From: Sherm Pendley <spamtrap@dot-app.org>
Subject: Re: Formmail Question
Message-Id: <oIWdnQ4XDZL5aHvcRVn-3w@adelphia.com>
Deepster wrote:
> are properly filled out when they click submit. I have the functions
> working but how can I run both the functions and process the form when
> the users click on submit button?
That's a JavaScript question, not a Perl question. The answer would be the
same, regardless of what CGI is on the other end, or what language that CGI
happened to be written in.
Additionally, if you're using Matt Wright's formmail - don't. It has too
many bugs and security vulnerabilities to mention. Use the free nms (Not
Matt's Scripts) replacement instead:
<http://nms-cgi.sourceforge.net>
sherm--
--
Cocoa programming in Perl: http://camelbones.sourceforge.net
Hire me! My resume: http://www.dot-app.org
------------------------------
Date: Thu, 13 Jan 2005 13:20:49 -0700
From: Scott Bryce <sbryce@scottbryce.com>
Subject: Re: Random Functionality
Message-Id: <_oydnQN5qOuJRXvcRVn-pA@comcast.com>
Brian McCauley wrote:
> Sometimes symbolic CODErefs are the right tool.
I would not have thought of that.
> However rather than using a prefix string it's probably
> better to use a separate symbol table (package) and simply find _all_
> the subrouines in that symbol table.
OK, I'm with you.
I wrote:
>> My original approach involved eval'ing the contents of external files.
>> I found this approach difficult to maintain.
>
Brian McCauley responded:
> Can you explain the nature of the difficulty.
It was probably more a problem with my implementation. I had code in the
external files that was dependent on code in the script. That got messy.
Also, the whole project would eventually have hundreds of these external
files in use by close to 100 scripts. I would prefer not to have to
manage all of them.
> Usually I'd do something like:
>
> {
> # This package is used only for the handlers defined in handlers.pl
> package MyModule::Handlers;
> # handlers.pl does not countain a package directive
> do 'handlers.pl';
> }
>
> my @sub_list =
> map { \&$_ }
> grep { exists(&$_) }
> map {"MyModule::Handlers::$_"}
> sort keys %MyModule::Handlers::;
>
> Note \&$_ and exists(&$_) are exempt from strict refs precisely so that
> you can do stuff like this.
Unfortunately, that is a little over my head. I'll spend some time
looking at the docs and see if I can figure out what that code is doing.
It occurs to me that the package containing the subroutines in question
could be in the script itself rather than in an external file.
This gives me something to work with. Would this be better than pushing
references to anonymous subroutines on to a list (as in the example code
I posted in the OP), or is this just another way to do it? To answer
that question, I would probably have to define "better."
Thanks!
------------------------------
Date: 13 Jan 2005 21:16:59 GMT
From: Glenn Jackman <xx087@freenet.carleton.ca>
Subject: Re: Random Functionality
Message-Id: <slrncudpac.29v.xx087@smeagol.ncf.ca>
At 2005-01-13 12:21PM, Scott Bryce <sbryce@scottbryce.com> wrote:
> What I want to avoid is having to include a chunk of code like:
>
> my $i = int(rand(3)); # This line has the number hard coded
>
> Sub_1() if $i == 0; # These lines have sub names hard coded.
> Sub_2() if $i == 1;
> Sub_3() if $i == 2;
>
> If I add a Sub_4, the code above would have to be changed to reflect
> that. I want to avoid having to make that kind of change to the code. I
> have found from working in other environments that this approach is
> prone to errors when the code is maintained.
One approach is to maintain a list of subroutine references:
my @subrefs = ( \&sub_1, \&sub_2, \&sub_3, ...);
and invoke a random one like:
$subrefs[rand @subrefs]->();
If that's too much maintainance, have the script read itself to find
subroutines:
use strict;
use warnings;
# find subroutines in this script
my @subrefs;
open my $self, $0 or die "can't open $0: $!\n";
while (<$self>) {
# ignore lines up to the delimiter
next if 1 .. /^### read these subs ###/;
next unless /^sub (\S+)/;
push @subrefs, \&$1;
}
close $self;
# call a random subroutine
$subrefs[rand @subrefs]->();
sub not_a_random_subroutine {}
### read these subs ###
sub Sub_1 {print "1\n";}
sub secondsub {print "2\n";}
sub the3rd {print "3\n";}
#...
When you add new subroutines, just add them below the delimiting comment.
--
Glenn Jackman
NCF Sysadmin
glennj@ncf.ca
------------------------------
Date: Thu, 13 Jan 2005 21:34:06 GMT
From: Bart Lateur <bart.lateur@pandora.be>
Subject: Re: Random Functionality
Message-Id: <o7qdu05e04c8nvtpb8rhu3tidrdfstst7m@4ax.com>
Scott Bryce wrote:
>What I want to avoid is having to include a chunk of code like:
>
>my $i = int(rand(3)); # This line has the number hard coded
>
>Sub_1() if $i == 0; # These lines have sub names hard coded.
>Sub_2() if $i == 1;
>Sub_3() if $i == 2;
$subs[int rand @subs]->();
where
@subs = (\&Sub_1, \&Sub_2, \&Sub_3);
--
Bart.
------------------------------
Date: 13 Jan 2005 22:18:33 GMT
From: xhoster@gmail.com
Subject: Re: Random Functionality
Message-Id: <20050113171833.329$2o@newsreader.com>
Scott Bryce <sbryce@scottbryce.com> wrote:
> xhoster@gmail.com wrote:
>
> > But it is at odds with your description above. Which should we trust?
>
> The fault lies in the description of the problem. I am finding it
> difficult to describe exactly what I want to do. I attempted to clarify
> the problem description in my reply to Anno. If the problem description
> is still unclear, I guess I'm on my own.
I posted my reply before your response to Anno reached me. It is clearer
what you want now.
> The code does what I want it to do. I want to know if there is a better
> way to do it than what I wrote.
Well, I still think populating the array all at once is better than the
sequence of pushes you have, but other than that I think your way is fine.
But it is not possible to say what is better or best for you. While some
methods are clearly inferior to others, once you remove all the dreck you
are left with several good methods, and which of those is the best is
extremely sensitive on the minutiae of your environment and usage patterns.
Are you having some kind of difficulty with the method you are currently
using? If not, you don't need something better. If so, what is/are the
problem(s) you are having?
Xho
--
-------------------- http://NewsReader.Com/ --------------------
Usenet Newsgroup Service $9.95/Month 30GB
------------------------------
Date: 13 Jan 2005 14:57:22 -0800
From: "zeebster" <gregaryh@juno.com>
Subject: Regular expression lookahead question
Message-Id: <1105657042.759998.176370@z14g2000cwz.googlegroups.com>
I am trying to parse an xml file for unprotected ampersands (&)
I do not want to match ampersand characters that preceed a protected
entity such as in the case of < or >
After hours of copious searches I found something that looked like it
would work using lookaheads:
&(?!quot|lt|gt|amp)
However this does not seem to work. Can anyone give me a clue what I am
doing wrong?
------------------------------
Date: 13 Jan 2005 12:31:09 -0800
From: "Jim Monty" <jimmonty@gmail.com>
Subject: Unix-format text from STDOUT under Windows (AcitvePerl 5.8.x)?
Message-Id: <1105648268.967471.13360@f14g2000cwb.googlegroups.com>
Using ActivePerl 5.8.x for Windows, how do I make STDOUT output
Unix-format text instead of DOS-format text? In other words, I want to
force the output text to have LF-terminated lines, not CRLF-terminated
lines. The input text is DOS-format.
Jim Monty
------------------------------
Date: Thu, 13 Jan 2005 20:43:53 GMT
From: "Paul Lalli" <mritty@gmail.com>
Subject: Re: Unix-format text from STDOUT under Windows (AcitvePerl 5.8.x)?
Message-Id: <d4BFd.25$Dz2.10@trndny09>
"Jim Monty" <jimmonty@gmail.com> wrote in message
news:1105648268.967471.13360@f14g2000cwb.googlegroups.com...
> Using ActivePerl 5.8.x for Windows, how do I make STDOUT output
> Unix-format text instead of DOS-format text? In other words, I want to
> force the output text to have LF-terminated lines, not CRLF-terminated
> lines. The input text is DOS-format.
Perhaps this is naive, but why not just output what you want to output:
print "This is a line ending in LF\012";
In fact, I *think* that's what the documentation (perldoc perlop - Quote
and Quote-like operators) suggests as well.
Paul Lalli
------------------------------
Date: Thu, 13 Jan 2005 15:35:35 -0500
From: Shawn Corey <shawn.corey@sympatico.ca>
Subject: Re: Unix-format text from STDOUT under Windows (AcitvePerl 5.8.x)?
Message-Id: <FWAFd.32373$b64.966677@news20.bellglobal.com>
Jim Monty wrote:
> Using ActivePerl 5.8.x for Windows, how do I make STDOUT output
> Unix-format text instead of DOS-format text? In other words, I want to
> force the output text to have LF-terminated lines, not CRLF-terminated
> lines. The input text is DOS-format.
>
> Jim Monty
>
You could try 'binmode'. I'm not running MS so I can't test it.
perldoc -f binmode
--- Shawn
------------------------------
Date: 13 Jan 2005 13:25:01 -0800
From: "Jim Monty" <jimmonty@gmail.com>
Subject: Re: Unix-format text from STDOUT under Windows (AcitvePerl 5.8.x)?
Message-Id: <1105651501.947788.240260@f14g2000cwb.googlegroups.com>
Shawn Corey wrote:
> Jim Monty wrote:
> > Using ActivePerl 5.8.x for Windows, how do I make STDOUT output
> > Unix-format text instead of DOS-format text? In other words, I want
to
> > force the output text to have LF-terminated lines, not
CRLF-terminated
> > lines. The input text is DOS-format.
> >
> > Jim Monty
> >
>
> You could try 'binmode'. I'm not running MS so I can't test it.
>
> perldoc -f binmode
Thanks. binmode() works. It's unclear from perldoc -f binmode and
perldoc PerlIO exactly which of these is most appropriate, but they all
seem to work:
binmode STDOUT;
binmode STDOUT, ":raw";
binmode STDOUT, ":unix";
Alas, I asked the wrong question in the first place: the right answer
still doesn't solve my real problem. I want to change the behavior of
XML::Writer, but it seems there's no way to do it. It mucks with STDOUT
using IO::Handle in a way that a user of the class cannot alter.
Oh well!
Jim Monty
------------------------------
Date: 13 Jan 2005 14:09:32 -0800
From: "Michael Carman" <mjcarman@mchsi.com>
Subject: Re: Unix-format text from STDOUT under Windows (AcitvePerl 5.8.x)?
Message-Id: <1105654172.052111.284170@c13g2000cwb.googlegroups.com>
Jim Monty wrote:
> Using ActivePerl 5.8.x for Windows, how do I make STDOUT output
> Unix-format text instead of DOS-format text?
I too once looked into ways to have Perl generate text files in
something other than the native platform format. IIRC, binmode() worked
for some situations but wasn't flexible enough for the general case. I
finally decided that it was better to either
a) post-process the files, or
b) use an FTP client to transfer them in ASCII mode
-mjc
------------------------------
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 7643
***************************************
