[10114] in Perl-Users-Digest
Perl-Users Digest, Issue: 3707 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Mon Sep 14 02:07:17 1998
Date: Sun, 13 Sep 98 23:00:14 -0700
From: Perl-Users Digest <Perl-Users-Request@ruby.OCE.ORST.EDU>
To: Perl-Users@ruby.OCE.ORST.EDU (Perl-Users Digest)
Perl-Users Digest Sun, 13 Sep 1998 Volume: 8 Number: 3707
Today's topics:
Re: a very simple question (Ronald J Kimball)
Re: COBOL and Perl (Walt Mankowski)
Re: COBOL and Perl (Craig Berry)
Help with FTP <j.alpers@clear.net.nz>
Re: Help with FTP (Sean McAfee)
Re: Max. Length of an Array (Ronald J Kimball)
Re: multiple patern matches (Ronald J Kimball)
Re: Perl & Java - differences and uses <bjohnsto_usa_net@my-dejanews.com>
Re: Perl & Java - differences and uses <borg@imaginary.com>
Re: QUESTIONS (was: Perl Programmer Needed) (David Adler)
Re: this is a very stupid question.... (Ronald J Kimball)
Re: this is a very stupid question.... (Larry Rosler)
Re: using loadable modules... (Ronald J Kimball)
Re: using loadable modules... (Larry Rosler)
Re: using loadable modules... (Ronald J Kimball)
Using PERL for NT Login Script (Ronnie Bouchon)
Special: Digest Administrivia (Last modified: 12 Mar 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sun, 13 Sep 1998 23:43:03 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: a very simple question
Message-Id: <1dfbhm6.198ucr41yjd6xwN@bay2-150.quincy.ziplink.net>
steven t henderson <STEVENHENDERSON@prodigy.net> wrote:
> abstracted, i would like to run the following program and
> have the local.htm file displayed in the browser, however
> i can only seem to get "Location ..." printed on the first
> line of STDOUT.
>
> how can i tell the browser not to display the data, but rather
> load the page i have pointed to?
>
>
> >> #!/usr/bin/perl
> >> print "Location: /local.htm\n\n";
> >> 1;
Whatever is executing your Perl script is already outputting HTTP
headers for you. You need to figure out how to have the server execute
your script without outputting headers.
This, however, is not a Perl problem. You might try
comp.infosystems.www.servers.*
By the way, this subject header isn't much better than the subjetc
header you used on your other posting of this question.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 14 Sep 1998 04:21:51 GMT
From: waltman@netaxs.com (Walt Mankowski)
Subject: Re: COBOL and Perl
Message-Id: <6ti5kv$kl7@netaxs.com>
As someone who's written code both in Cobol and in Perl, I feel
compelled to add my 2 cents.
It's possible to write quite readable code in Perl, just as it's
possible to write nearly incomprehensible programs in Cobol.
Cobol programs do, on the whole, tend to be more readable than
Perl scripts. Cobol is a fine langauge for doing what it was
designed to do -- processing data, reading and writing records in
files, printing reports, etc. At my company we do the vast
amount of our back-end processing, including online transaction
processing, in Cobol, and on the whole it works out quite well
for us.
There are two things I really dislike about Cobol. First of all,
it's difficult to write modern, structured code in Cobol. In
particular it's hard to break code down into small subroutines as
one normally does in C or Perl. Cobol programs tend to be build
around paragraphs which are just glorified Basic gosubs. They
also tend to have dozens, if not hundreds, of global variables.
Second, in Cobol I often feel like I'm programming with one hand
tied behind my back. In Cobol all you can do is write simple,
straightforward code. You can do that in Perl as well, but you
have a lot of options at your disposal if you need them. If you
need to do something reasonably complicated it's usually far
easier to write it in Perl.
Once at work we had to convert city names from upper case to
proper case, e.g. "NEW YORK CITY" to "New York City". This would
be a difficult routine to write in Cobol, but in Perl you can do
it in a one-line regular expression:
s/(\W*\w)(\w*)(\W*)/$1\L$2\E$3/g;
Yes, I do realize how ugly this is. For the sake of future
maintainers I try to not include a lot of these, and comment like
hell when I do. But it's good to be ABLE to have tools like
regular expressions at your disposal when you need them.
Walt
------------------------------
Date: 14 Sep 1998 04:49:17 GMT
From: cberry@cinenet.net (Craig Berry)
Subject: Re: COBOL and Perl
Message-Id: <6ti78d$r6m$1@marina.cinenet.net>
Walt Mankowski (waltman@netaxs.com) wrote:
: Once at work we had to convert city names from upper case to
: proper case, e.g. "NEW YORK CITY" to "New York City". This would
: be a difficult routine to write in Cobol, but in Perl you can do
: it in a one-line regular expression:
:
: s/(\W*\w)(\w*)(\W*)/$1\L$2\E$3/g;
That's actually a lot uglier than it needs to be.
s/(\w+)/\u\L$1/g;
does the same thing more readably (at least IMO). (And actually, this
version will go from any mix of capitalization into initial-capital,
trailing-lowercase form, though of course that's an unneeded 'feature' for
your spec.)
: Yes, I do realize how ugly this is.
As a general rule, when something easily expressible like "initial-cap,
trailing-lowercase all words" ends up looking ugly as a Perl expression,
it should indicate you've not found the best way to write the Perl
expression. "Making easy things easy," as the saying goes.
: For the sake of future
: maintainers I try to not include a lot of these, and comment like
: hell when I do. But it's good to be ABLE to have tools like
: regular expressions at your disposal when you need them.
Amen to that!
---------------------------------------------------------------------
| Craig Berry - cberry@cinenet.net
--*-- Home Page: http://www.cinenet.net/users/cberry/home.html
| "Ripple in still water, when there is no pebble tossed,
nor wind to blow..."
------------------------------
Date: Mon, 14 Sep 1998 17:25:51 +1200
From: Jonathan Alpers <j.alpers@clear.net.nz>
Subject: Help with FTP
Message-Id: <35FCA8DF.A679780A@clear.net.nz>
How do I send commands to FTP with Perl? I've tried the following:
open FTP, "|ftp somewhere.com";
print FTP "username\n";
print FTP "password\n";
print FTP "get filename";
etc.
But it doesn't work - all I get is the ftp> prompt. Any ideas?
Cheers
Jonathan
------------------------------
Date: Mon, 14 Sep 1998 05:59:14 GMT
From: mcafee@waits.facilities.med.umich.edu (Sean McAfee)
Subject: Re: Help with FTP
Message-Id: <Sg2L1.2617$F7.11173327@news.itd.umich.edu>
In article <35FCA8DF.A679780A@clear.net.nz>,
Jonathan Alpers <j.alpers@clear.net.nz> wrote:
>How do I send commands to FTP with Perl? I've tried the following:
>open FTP, "|ftp somewhere.com";
>print FTP "username\n";
>print FTP "password\n";
>print FTP "get filename";
>etc.
>But it doesn't work - all I get is the ftp> prompt. Any ideas?
The ftp program is explicitly programmed to get its input from a terminal,
not the standard input stream.
To get around this, you have to use a program which pretends to be a
terminal (ie, Expect), or better yet, use the Net::FTP module, available at
a fine CPAN site near you.
--
Sean McAfee | GS d->-- s+++: a26 C++ US+++$ P+++ L++ E- W+ N++ |
| K w--- O? M V-- PS+ PE Y+ PGP?>++ t+() 5++ X+ R+ | mcafee@
| tv+ b++ DI++ D+ G e++>++++ h- r y+>++** | umich.edu
------------------------------
Date: Sun, 13 Sep 1998 23:43:06 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: Max. Length of an Array
Message-Id: <1dfbhvi.sm70sw1nn9qtcN@bay2-150.quincy.ziplink.net>
Nitin Gupta <niting@raleigh.ibm.com> wrote:
> Is there a maximum (upper limit) to the number of items an array can
> hold? Is this dependent on the systems available memory?
A search for 'limit' led to perl.pod:
While none of the built-in data types have any arbitrary size limits
(apart from memory size), there are still a few arbitrary limits: a
given variable name may not be longer than 255 characters, and no
component of your PATH may be longer than 255 if you use B<-S>. A
regular expression may not compile to more than 32767 bytes
internally.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Sun, 13 Sep 1998 23:43:10 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: multiple patern matches
Message-Id: <1dfbi0u.1g4q38m1px567sN@bay2-150.quincy.ziplink.net>
Alan Barclay <gorilla@elaine.drink.com> wrote:
> $_+0 < 255 &&
> $_+0 >= 0
Unless you're using '+0' for mnemonic reasons, it's really not
necessary, as the numeric conversion is inherent in the numeric
comparison operators.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: 14 Sep 1998 02:47:50 GMT
From: "bjohnsto_usa_net" <bjohnsto_usa_net@my-dejanews.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <01bddec0$f43a7200$3f16b3d1@lhodgkiss>
Zenin <zenin@bawdycaste.org> wrote in article
<905553026.251116@thrush.omix.com>...
> bjohnsto_usa_net@my-dejanews.com wrote:
> >snip<
> : Given the way that current databases work, an applications which
requires each
> : user to hold a database connection will not scale.
> : Since this is well known and application which is required to scale
should not
> : be architected this way.
>
> Exactly my point.
>
> : However Database vendors could enable simpler architectures to scale
better
> : by by changing the limitations of their implementations.
>
> Sure, they could provide a new TCP/IP stack for every system they
> run on and write there server code in assembly so that large
numbers
> of connections would not require as much memory. :-)
HTTP servers don't require this. Neither do database servers.
>
> : Instead they have
> : created requirement to pool connections and diverted some of their
potential
> : revenue to products which provide this service.
>
> Some would call this modular programming. There is nothing
> inheritably wrong, non-scalable, or non-maintainable with
> multi-tier designs. Are you saying this should be part of the
> core server, or the server should ship with such a tool as
> standard? Maybe so, maybe not.
>
> There are a large number of middleware/application server
> systems that would actually *suffer* if forced to go through
> such a layer. Such a completely generic pool server/system
> interface would only be useful to the simplist of designs.
Don't force them to, just offer the alternative.
Local processes can use shared memory.
High Volume connections can use a persistent connection.
Low volume connections can use http/http style connections.
> : A common mistake that many involved in a specialized area of computing
> : science is to assume all other aspect of the trade are simple.
>
> Another aspect? Are we not both talking about server code?
We're
> not talking about what the server actually does (as that could
> be anything), we're talking about how the server management
> code is designed.
>
> : People with a large number of users assume that those with a lower
number of
> : users can get by with any language, like shell script.
>
> For the internal server management code, they likely can. For
> whatever work the server is actually there to do, that's another
> topic.
Fair point. I see what you mean.
>
> : > Yes. They are sponsored by the memory and CPU manufactures,
I'm
> : > sure of it. Personally, I feel people should be required to
test
> : > for a competency license before being allowed to use threads.
Of
> : > course, I feel the same way about USENET. :-)
> : I have no real problem with asking for a bit more memory or CPU at
todays
> : prices if it saves on programmer time.
>
> That's the problem, they tell people it's only a bit. And they
> are right, it is only a bit. In most application code you can
> affort to give a bit here and there as it only is multiplied by
> one. In server code, those little bits are often multiplied by
> the number of clients you're required to handle at any given
> point. In a Java server, 3000 connections requires at least
> 3000 threads just to start, simply because it can not muliplex
> IO at any level. If the server needs to do almost anything
> interesting with other IO systems, each one of those threads
> will likely need to spawn at least one other thread. 6000
threads,
> not to mention the TCP stack overhead to of 3000 connections,
> would toast all but the largest servers. We're not talking
> about a "bit" more RAM here, we're now talking in GIGs.
>
> This is why great application programmers more often then
> not create really, really bad server code. The two worlds
> are completely and totally different.
The key is to get applications programmers writing good servers.
This is part tools and architectures part education.
> : I agree on threads, however even those competent with threads will
create more
> : bugs by using them. It is important to limit the amount of code which
can
> : potentially have concurrency bugs.
>
> I'm not worried about them for the sake of bugs, at least not
> in server code. I'm worried about them for the extra system
> overhead costs.
I see what you were talking about above.
> : Oracle, and Web servers seems to run OK on NT.
>
> In lower level systems only.
This certainly does seem true.
In general I try to architect systems which don't need anything more.
There are plenty of people who do pretty good stuff on NT.
A very small NT/IIS box can deliver enough static web pages to saturate
virtually any existing internet link.
>
> : My experience with AIX servers here says they are slower than NT boxes
that
> : cost 1 tenth the price.
>
> I haven't worked with AIX myself. Solaris, FreeBSD, BSDI, Linux,
> and yes NT are my primary domain.
>
> Bang for the buck, nothing can beat FreeBSD or Linux on x86
> hardware, but it doesn't scale. It's not the system, it's the
> hardware.
>
> I've yet to see the NT box that can touch the mid to high end
> Sun boxes, and I'm nothing close to a Solaris fan.
This may change with IA64 arround 2002.
But right now sure.
However Intel servers are more powerful than Unix boxes of not very long
ago.
I believe that all sites *can* be architected to work on Intel NT Servers.
> : I suggest that working within the limitations of a tool, good solutions
can be
> : architected.
>
> It depends. If the tools lack the primitives required to build a
> good architecture, you have to make do with kluges and then hope
> no one will ask you to scale them too big. Thus is the case with
> NT and Java for server use. Great for clients, trash for
servers.
You might have to scale by spreading accross more servers and be more
creative.
>
> : > Remember, if you've got 20 httpd children, you've got 20
cached
> : > database connections.
> : I take it that the reason you have 20 children is because you don't
have
> : threads.
>
> Apache doesn't use threads under Unix, with good reason. Unlike
> Win32 systems, context switching between processes is nothing
close
> to as expensive and for long running servers memory leaks (either
> in the server or the operating system) can be minimalized.
>
> Even in a threaded system, you'd have to multiplex your database
> connections. With some databases (ala Sybase or ODBC based
> driver) you even need to serialize all your queries through a
> particular connection.
>
> Theads have there place on nearly every general use system.
> On Unix however, they are best used for reducing memory
> requirements IMHO. While you gain a few other nice features
> with threads, you lose features of processes.
Hopefully with Java leaks of resources can be controlled by the virtual
machine without using processes.
[snip]
> : This is because using relational databases is slow.
>
> True, however. Have you tried to do relational data queries
> without one? With guaranteed transaction support? Almost
> unlimited rollback support? Relational databases do far more
> then just relate data. As I mentioned before, if that's all
> one wanted from a database they'd use MiniSQL or MySQL and
> blow Oracle et al away in performance.
Yes, there are reasons they are slow. Some are about the problem itself,
others are about the relational model.
No matter what architecture you choose there will be certain speed
limitations from the database itself.
Many problems in the rest of the architecture don't really affect
performance, which is limited by the database anyway.
I have seen many systems which do the aspects of what RDMS's do,
transaction support and recovery, they did it alot faster than relational
databases. They are simpler and much less full featured. They were custom
designed to solve speed problems for a limited set of tasks.
>
> : > Databases can
> : > more then keep up with the requirements of web and similar
> : > technologies.
> : Only if you understand how slow they are and make sure you code around
the
> : performance problems that would otherwise result.
>
> However much people have tried to not fess up to it, this is the
> case for each and every single aspect of software engineering.
>
> In computer languages everyone feels they shouldn't have to
> think about how there code is actually going to be executed.
> That somehow the compiler writers are gods that will be able
> to take whaterver they write however they write it and execute
> it in the most efficient mannor to get that job done.
>
> They are all on crack.
>
> Anyone that does not understand what is happening underneath
> there code is guaranteed to write wasteful and slow code. This
> is why I feel assembly, and assembly, should be a hard
requirement
> for all CS and MIS courses of study. They don't have to be great
> assembly programmers, they just need the basic concepts of memory
> stucture and low level program execution.
>
> >snip<
> : Perl, Java are fast (C and C++ are very fast).
>
> Ya know, I've never quite seen it so well put before.
I spent 95% of my time coding Java and C++ not worrying about performance.
I worried about clean, correct design, and code.
The speed of the underlying language got around the inefficiecies in my
code.
Every operation on an RDMS seems to have an effect on performance. I have
to reduce them to an absolute minimum.
> : The perl task to mulge the data took 1 minute to code and a few seconds
to
> : run.
> : The Oracle upload took ten minutes. That is because relations
databases
> : are slow.
> >snip<
>
> Ouch! There must be a missing piece here someplace. Was the
> Oracle server or the machine it runs on under heavy load? How
> much data are we talking about here? Did it require something
> fireing off a procedure for every row you inserted? Did you
> not commet any data until the entire upload was done?
>
> I'm just wondering because I've only seen this while importing
> or exporting very large tables.
The server was not under heavy load (most likely no other users). It was a
$600,000 AIX server.
We are talking about 10,000 rows.
We are talking about:
INSERT INTO TABLE (COL, COL, ..., COL8) VALUES (VAL1, VAL2, ..., VAL8);
I had not dropped the two indexes.
There was one commit at the end.
The database was probably not particularly overworked.
It is more the overhead of each statement going to the server, the client,
(SQLPLUS) waiting for the reply, then sending the next line.
> -Zenin (zenin@archive.rhps.org) From The Blue Camel we learn:
People are moving more code to servers, to serve the increasing online
population, and to reduce support costs associated with client
configuration.
The cost of coding these systems is higher than development for clients.
I believe that improvements in computing science and tools will reduce this
gap.
Brendan Johnston
------------------------------
Date: Mon, 14 Sep 1998 04:32:54 GMT
From: George Reese <borg@imaginary.com>
Subject: Re: Perl & Java - differences and uses
Message-Id: <W%0L1.1418$E9.4990895@ptah.visi.com>
In comp.lang.java.programmer Jaime Metcher <metcher@spider.herston.uq.edu.au> wrote:
: George Reese wrote:
:>
:>snip<
:> The point was that a computer should be able to understand our natural
:> language and that somehow or another we should be forced to express
:> our desires in natural language that everyone else can make sense of.
:>
:>snip<
: George, your logic has been admirable so far, but this is a real
: clanger. Why one earth would you suppose that the majority of problem
: domains can even be described in natural language? There's nothing
: natural about most of computer science. Using natural language for many
: problems is like applying common sense to quantum physics. There's
: little that's natural or common, in the sense of human experience, about
: it.
Natural language is a superset of any computer language I certainly
have ever programmed in. That would include both perl and python. I
honestly do not know how a computer language could express something
that you could not express in English--how would you even talk about
such a thing?
--
George Reese (borg@imaginary.com) http://www.imaginary.com/~borg
PGP Key: http://www.imaginary.com/servlet/Finger?user=borg&verbose=yes
"Keep Ted Turner and his goddamned Crayolas away from my movie."
-Orson Welles
------------------------------
Date: 14 Sep 1998 05:17:30 GMT
From: dha@panix.com (David Adler)
Subject: Re: QUESTIONS (was: Perl Programmer Needed)
Message-Id: <6ti8ta$lej@news1.panix.com>
On Thu, 10 Sep 1998 05:34:03 GMT, Patrick Timmins
<ptimmins@netserv.unmc.edu> wrote:
>10. Throw in a "Norm Crosby", type of mis-speak (back of *my* hand)
Heck, I give you extra points for even remembering Norm Crosby...
--
David H. Adler - <dha@panix.com> - http://www.panix.com/~dha/
"If you want a real optimist, look up Ray Bradbury. Guy's nuts.
He actually likes people." - David Brin
------------------------------
Date: Sun, 13 Sep 1998 23:43:15 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: this is a very stupid question....
Message-Id: <1dfbibc.1vl2nqx1yu5si8N@bay2-150.quincy.ziplink.net>
Larry Rosler <lr@hpl.hp.com> wrote:
> '/local.htm' is not a URL. If you provide a URL
> ('http://my.server.com/local.htm') the program should do what you want.
Actually, it works just fine for me using a relative URL. The poster's
problem is likely something else. (See my response to his other
instance of posting this question.)
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Sun, 13 Sep 1998 22:38:35 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: this is a very stupid question....
Message-Id: <MPG.10664bb17d476e32989854@nntp.hpl.hp.com>
[Posted to comp.lang.perl.misc and copy mailed.]
In article <1dfbibc.1vl2nqx1yu5si8N@bay2-150.quincy.ziplink.net> on Sun,
13 Sep 1998 23:43:15 -0400, Ronald J Kimball <rjk@coos.dartmouth.edu>
says...
> Larry Rosler <lr@hpl.hp.com> wrote:
> > '/local.htm' is not a URL. If you provide a URL
> > ('http://my.server.com/local.htm') the program should do what you want.
>
> Actually, it works just fine for me using a relative URL. The poster's
> problem is likely something else. (See my response to his other
> instance of posting this question.)
But not for me. Probably this is a server issue.
The HTTP redirection without a server name succeeds on Micro$oft IIS 4.0,
but fails (hangs) on Netscape FastTrack 2.01. However, each of them
successfully performs an HTML redirection without the server name:
<HTML><HEAD>
<META HTTP-EQUIV="Refresh" CONTENT="0;URL=/local.htm">
</HEAD></HTML>
I don't think there's any further Perl issue in this question, in any
case.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Sun, 13 Sep 1998 23:43:19 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: using loadable modules...
Message-Id: <1dfbitr.whmdplxgum6yN@bay2-150.quincy.ziplink.net>
Larry Rosler <lr@hpl.hp.com> wrote:
> [Posted to comp.lang.perl.misc and copy mailed.]
>
> In article <6ths19$8l1$1@netnews.csie.NCTU.edu.tw> on 14 Sep 1998
> 01:37:45 GMT, GEMINI <dennis@info4.csie.nctu.edu.tw> says...
> ...
> > if ($^O=~/win32/i) {
> > use xxx;
> > :
> > :
> > }
> ...
> > So can I tell perl not to check the used modules while
> > compile time to avoid this problem?
>
> The simplest solution is to encase the entire construct in a
> BEGIN { } block. Then the decision about the operating system will
> control whether the module is included or not.
Then you'll get the same error message when the BEGIN block is compiled.
I think you've posted the solution for a different problem. :-)
Here's one way to do it:
if ($^O =~ /win32/i) {
require xxx;
import xxx;
}
If you still want a compile-time warning if the module can't be found on
a win32 system, then, as Larry suggested, you should wrap the whole
construct in a BEGIN { } block.
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Sun, 13 Sep 1998 21:19:45 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: using loadable modules...
Message-Id: <MPG.1066393e37854efb989853@nntp.hpl.hp.com>
[Posted to comp.lang.perl.misc and copy mailed.]
In article <1dfbitr.whmdplxgum6yN@bay2-150.quincy.ziplink.net> on Sun, 13
Sep 1998 23:43:19 -0400, Ronald J Kimball <rjk@coos.dartmouth.edu>
says...
:> Larry Rosler <lr@hpl.hp.com> wrote:
:> > In article <6ths19$8l1$1@netnews.csie.NCTU.edu.tw> on 14 Sep 1998
:> > 01:37:45 GMT, GEMINI <dennis@info4.csie.nctu.edu.tw> says...
:> > ...
:> > > if ($^O=~/win32/i) {
:> > > use xxx;
:> > > :
:> > > :
:> > > }
:> > ...
:> > > So can I tell perl not to check the used modules while
:> > > compile time to avoid this problem?
:> >
:> > The simplest solution is to encase the entire construct in a
:> > BEGIN { } block. Then the decision about the operating system will
:> > control whether the module is included or not.
:>
:> Then you'll get the same error message when the BEGIN block is
compiled.
:> I think you've posted the solution for a different problem. :-)
:>
:> Here's one way to do it:
:>
:> if ($^O =~ /win32/i) {
:> require xxx;
:> import xxx;
:> }
:>
:> If you still want a compile-time warning if the module can't be found
on
:> a win32 system, then, as Larry suggested, you should wrap the whole
:> construct in a BEGIN { } block.
Maybe I snipped too much from the original post, to get it past my
newsfeed. [And this didn't make it on the first two tries, either.]
:> the module xxx is only available on win32 system.
:> However, if the script are tested on other platform,
:> the perl will say that the module xxx cannot be found
:> during compile time, though it is not necessary on other systems.
Surely he wants the compile-time warning if the module can't be found on
a win32 system.
But either approach will give the same effective behavior, either at
compile time or at run time. Note that I proposed the BEGIN { }
wrapper as the 'simplest' solution, not the only solution.
--
(Just Another Larry) Rosler
Hewlett-Packard Laboratories
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
------------------------------
Date: Mon, 14 Sep 1998 00:39:10 -0400
From: rjk@coos.dartmouth.edu (Ronald J Kimball)
Subject: Re: using loadable modules...
Message-Id: <1dfblbt.tkaxp51pil8aoN@bay2-150.quincy.ziplink.net>
[posted and mailed]
Larry Rosler <lr@hpl.hp.com> wrote:
> :> > > So can I tell perl not to check the used modules while
> :> > > compile time to avoid this problem?
> :> >
> :> > The simplest solution is to encase the entire construct in a
> :> > BEGIN { } block. Then the decision about the operating system will
> :> > control whether the module is included or not.
> :>
> :> Then you'll get the same error message when the BEGIN block is
> compiled.
> :> I think you've posted the solution for a different problem. :-)
> :>
> :> Here's one way to do it:
> :>
> :> if ($^O =~ /win32/i) {
> :> require xxx;
> :> import xxx;
> :> }
> :>
> :> If you still want a compile-time warning if the module can't be found
> :> on a win32 system, then, as Larry suggested, you should wrap the
> :> whole construct in a BEGIN { } block.
>
> Maybe I snipped too much from the original post, to get it past my
> newsfeed. [And this didn't make it on the first two tries, either.]
Actually, I believe you missed my point. Your solution *will not work*.
If you put
if (blah) {
use Foo;
}
within a BEGIN { } block, you will get the same error as before,
*regardless of the truth of blah*. This is because 'use' is a compiler
directive, as you know, and thus is executed during the *compilation* of
the BEGIN block, before the 'if (blah) { }' is executed.
> :> the module xxx is only available on win32 system.
> :> However, if the script are tested on other platform,
> :> the perl will say that the module xxx cannot be found
> :> during compile time, though it is not necessary on other systems.
>
> Surely he wants the compile-time warning if the module can't be found on
> a win32 system.
Not necessarily - he might be happy with a runtime-warning, as he would
get with require outside of a BEGIN block. That's why I offered him the
choice. :-)
> But either approach will give the same effective behavior, either at
> compile time or at run time. Note that I proposed the BEGIN { }
> wrapper as the 'simplest' solution, not the only solution.
I'm afraid your solution will not effectively change his script at all.
~> cat > temp1.pl
# original script
if ($false) {
use Camel;
}
~> perl -c temp1.pl
Can't locate Camel.pm in @INC at temp1.pl line 4.
BEGIN failed--compilation aborted at temp1.pl line 4.
~> cat > temp2.pl
# Larry's solution
BEGIN {
if ($false) {
use Camel;
}
}
~> perl -c temp2.pl
Can't locate Camel.pm in @INC at temp2.pl line 5.
BEGIN failed--compilation aborted at temp2.pl line 5.
~> cat > temp3.pl
# my solution
BEGIN {
if ($false) {
require Camel;
import Camel;
}
}
~> perl -c temp3.pl
temp3.pl syntax OK
~>
--
_ / ' _ / - aka - rjk@coos.dartmouth.edu
( /)//)//)(//)/( Ronald J Kimball chipmunk@m-net.arbornet.org
/ http://www.ziplink.net/~rjk/
"It's funny 'cause it's true ... and vice versa."
------------------------------
Date: Mon, 14 Sep 1998 02:44:21 GMT
From: snorjb@unx.sas.com (Ronnie Bouchon)
Subject: Using PERL for NT Login Script
Message-Id: <35fc81bd.444115494@newshost.unx.sas.com>
Has anyone successuflly used PERL for their Windows NT Login Script?
I've got mine just about 100%coded, but am unsure how efficient an
interpreted language will be versus something compiled.
------------------------------
Date: 12 Jul 98 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Special: Digest Administrivia (Last modified: 12 Mar 98)
Message-Id: <null>
Administrivia:
Special notice: in a few days, the new group comp.lang.perl.moderated
should be formed. I would rather not support two different groups, and I
know of no other plans to create a digested moderated group. This leaves
me with two options: 1) keep on with this group 2) change to the
moderated one.
If you have opinions on this, send them to
perl-users-request@ruby.oce.orst.edu.
The Perl-Users Digest is a retransmission of the USENET newsgroup
comp.lang.perl.misc. For subscription or unsubscription requests, send
the single line:
subscribe perl-users
or:
unsubscribe perl-users
to almanac@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.misc (and this Digest), send your
article to perl-users@ruby.oce.orst.edu.
To submit articles to comp.lang.perl.announce, send your article to
clpa@perl.com.
To request back copies (available for a week or so), send your request
to almanac@ruby.oce.orst.edu with the command "send perl-users x.y",
where x is the volume number and y is the issue number.
The Meta-FAQ, an article containing information about the FAQ, is
available by requesting "send perl-users meta-faq". The real FAQ, as it
appeared last in the newsgroup, can be retrieved with the request "send
perl-users FAQ". Due to their sizes, neither the Meta-FAQ nor the FAQ
are included in the digest.
The "mini-FAQ", which is an updated version of the Meta-FAQ, is
available by requesting "send perl-users mini-faq". It appears twice
weekly in the group, but is not distributed in the digest.
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 V8 Issue 3707
**************************************
