[8950] in Perl-Users-Digest
Perl-Users Digest, Issue: 2568 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Tue May 12 16:09:59 1998
Date: Tue, 12 May 98 13:00:47 -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 Tue, 12 May 1998 Volume: 8 Number: 2568
Today's topics:
'use' cycles in Perl <bryan.bayerdorffer@analog.com>
Re: associative array of arrays (Mike Stok)
Re: Basic MacPERL (brian d foy)
Re: Can i get help PLs? <jsd@gamespot.com>
Re: chdir-command <dennis.kowalski@daytonoh.ncr.com>
Re: Connecting to a share <angela_molnar@hp.com>
Re: Dealer locator with zipcodes (Mark-Jason Dominus)
Re: Does Perl have a IDE?I don't like command line. (Greg Bacon)
Re: Does Perl have a IDE?I don't like command line. (Greg Bacon)
Re: Does Perl have a IDE?I don't like command line. <tchrist@mox.perl.com>
Re: Does Perl have a IDE?I don't like command line. <jsd@gamespot.com>
Re: ERROR: odbc.pm, &AutoLoader::AUTOLOAD <jkry3025@comenius.ms.mff.cuni.cz>
Re: File type sniffer (brian d foy)
Re: Grieving our dying community <tchrist@mox.perl.com>
Re: How can you break out of a 'while... ' loop in a fu <angst@scrye.com>
initializing $self <prl2@lehigh.edu>
Insecure $ENV <ronandersen@hotmail.com>
Re: Installing PERL on NT (Ryan McGuigan)
Re: Learning Perl vs Programming Perl (Books) (brian d foy)
Digest Administrivia (Last modified: 8 Mar 97) (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Tue, 12 May 1998 13:23:55 -0500
From: Bryan Bayerdorffer <bryan.bayerdorffer@analog.com>
Subject: 'use' cycles in Perl
Message-Id: <199805121823.NAA11044@mano.spd.analog.com>
Is there a problem with modules using each other in Perl5? The Perl book says
that
use Foo;
is identical to
BEGIN {
require Foo;
Foo->import();
}
Which should mean that if two modules (indirectly) use each other, all get
compiled and then the import sub gets called, which just maps exported symbols
into the local namespace. However, I have code that goes like
package A;
use B;
package B;
use C;
package C;
use A;
with various symbols exported in the BEGIN block of each module. It compiles
ok, but when code in package A refs a symbol in B, Perl complains (under use
strict) that the symbol isn't defined. If I break the cycle by deleting 'use
C', everything works. Even if I do this:
package A;
use B;
use C;
package B;
package C;
use A;
all is well. The symbol names are globally unique, so it's not a collision
problem.
-----
Summary of my perl5 (5.0 patchlevel 4 subversion 3) configuration:
Platform:
osname=solaris, osvers=2.5.1, archname=sun4-solaris
--
.. ..-. ..- -.-. .- -. .-. . .- -.. - .... .. ... --. . - .- .-.. .. ..-. . !!
Bryan Bayerdorffer bryan@outer.net bryan@spd.analog.com
(Wit's End Computation Center) (Analog Devices)
+1 512-427-1063 +1 512-427-1059 (fax) Bar code: || | |||| || | || || ||||
PGP key via finger O- Rock on completely with some brand-new components
Problem: "Number three engine missing."
Solution: "Engine found on right wing after brief search."
------------------------------
Date: 12 May 1998 18:05:48 GMT
From: mike@stok.co.uk (Mike Stok)
Subject: Re: associative array of arrays
Message-Id: <6ja31s$fvd@news-central.tiac.net>
In article <355d875b.355924081@news.ultranet.com>,
dwc <dwc@davewc.mv.com> wrote:
>
>I am using this example from the PerlFAQ (5.2) and I don't understand how to
>reference an array. I would like to reference the whole array (alphabet) at
>$T{key2}->{k3}. For the sake of this example, I would like to print out all the
>elements in this array.
>
>
>%T = ( key0, { k0, v0, k1, v1 }, key1, { k2, v2, k3, v3 }, key2, { k2, v2, k3,
>['a' .. 'z'] } );
>
># Trying to pull out a copy of the array.
>@myarr = $T{key2}->{k3};
>
># I don't understand this, but the output is correct
>print "myarr[0][0] = [$myarr[0][0]]\n";
>print "myarr[0][1] = [$myarr[0][1]]\n";
>
># This is what i'd like to do, but I only get 1 item,
># the actual array: ARRAY(0x83cb10)
>foreach $itm ( @myarr )
>{
> print "itm = [$itm]\n";
>}
Have you tried using the debugger (try typing perl -de 1 at the prompt)
DB<1> %T = ( key0, { k0, v0, k1, v1 }, key1, { k2, v2, k3, v3 }, key2, { k2, v2, k3, ['a' .. 'z'] } )
DB<2> X T
%T = (
'key0' => HASH(0x80503e4)
'k0' => 'v0'
'k1' => 'v1'
'key1' => HASH(0x8163968)
'k2' => 'v2'
'k3' => 'v3'
'key2' => HASH(0x8166128)
'k2' => 'v2'
'k3' => ARRAY(0x8163998)
0 'a'
...
25 'z'
)
So you might be able to see that $T{'key2'}{'k3'} contains a reference to
an anonymous array. You might say
foreach $item (@{$T{'key2'}{'k3'}}) {
...
}
When you do the assignment to @myarr you set element 0 of @myarr to the
array reference in $T{'key2'}{'k3'}, so $myarr[0][1] takes element index 1
from the array references in $myar[0].
Have you checked out the perllol (list of lists) and perldsc man pages?
Hope this helps,
Mike
--
mike@stok.co.uk | The "`Stok' disclaimers" apply.
http://www.stok.co.uk/~mike/ | PGP fingerprint FE 56 4D 7D 42 1A 4A 9C
http://www.tiac.net/users/stok/ | 65 F3 3F 1D 27 22 B7 41
stok@colltech.com | Collective Technologies (work)
------------------------------
Date: Tue, 12 May 1998 14:00:11 -0400
From: comdog@computerdog.com (brian d foy)
Subject: Re: Basic MacPERL
Message-Id: <comdog-ya02408000R1205981400110001@news.panix.com>
Keywords: from just another new york perl hacker
In article <35578703.216B@earthlink.net>, mkgagne@earthlink.net posted:
>I'm having trouble opening a file with MacPERL. I'm trying:
>open($ACCESS_LOG, "Tigger:Documents:Access-LOG.com")
Besides the other excellent comments, you might be stumped by one of
the Mac gotchas. The "Documents" folder that shows up on the desktop
actually lives in "Desktop Folder", so you would need to specify the
path as
"Tigger:Desktop Folder:Documents:Access-LOG.com"
HTH :)
--
brian d foy <comdog@computerdog.com>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
Perl Mongers <URL:http://www.pm.org>
------------------------------
Date: Tue, 12 May 1998 12:27:28 -0700
From: Jon Drukman <jsd@gamespot.com>
Subject: Re: Can i get help PLs?
Message-Id: <3558A2A0.EC612AD4@gamespot.com>
Calle Dybedahl wrote:
>
> manish@plexustech.net writes:
>
> > Can i attach files of different types to my mail using Perl Script??
>
> Yes. You do it the same way you'd do it in C och COBOL, only you write
> the code in Perl instead (translation: that is not a Perl question).
that is a rude and unhelpful answer. in fact it is very much a perl
question, and the answer is:
use the MIME::Lite module available from CPAN.
it has excellent examples in its documentation. your solution may be as
simple as something like:
# Create a new single-part message, to send a GIF file:
$msg = new MIME::Lite
From =>'me@myhost.com',
To =>'you@yourhost.com',
Cc =>'some@other.com, some@more.com',
Subject =>'Helloooooo, nurse!',
Type =>'image/gif',
Encoding =>'base64',
Path =>'hellonurse.gif';
--
Jon Drukman jsd@gamespot.com
-----------------------------------------------------------------------
Plan: Eat right, exercise regularly, die anyway.
------------------------------
Date: Tue, 12 May 1998 14:15:51 -0400
From: Dennis Kowalski <dennis.kowalski@daytonoh.ncr.com>
Subject: Re: chdir-command
Message-Id: <355891D7.12F5@daytonoh.ncr.com>
Annette Preissner wrote:
>
> Jonathan Feinberg wrote:
>
> > wizard <root@dfki.de> writes:
> >
> > > chdir "$newsdir_alt" or die "Can't cd to $newsdir_alt: $!\n";
> >
> > First, you shouldn't be using those quotes around $newsdir_alt.
> >
> > Second, does that variable contain a *relative* path or an *absolute*
> > path? If it's a relative path, then your assumptions about the
> > working directory are probably wrong. Hope this helps.
> >
> > --
> > Jonathan Feinberg jdf@pobox.com Sunny Brooklyn, NY
> > http://pobox.com/~jdf/
>
> Hi Jonathan,
>
> I already tried leaving out the quotes, but that wasn't the problem.
> I got the same error message with or without quotes or single quotes -
>
> also, the variable contains an absolute path, not a relative one, and
> my assumptions about the working directory are not wrong (as I demon-
> strate in my reply to Eike). I am really kind of helpless now.
>
> Noemi
Just one more thing I think you should check.
Where are you getting the value for the new directory name yo want to
chdir to ??
If it is off of the command line via ARGV[##] and it was the last
argument on the command line, make sure you chomp($newdir) to remove the
new line character.
I had that problem in a script and the chomp fixed it.
------------------------------
Date: Tue, 12 May 1998 12:04:15 -0700
From: Angela Molnar <angela_molnar@hp.com>
Subject: Re: Connecting to a share
Message-Id: <35589D2F.36C2@hp.com>
Denis DORR wrote:
>
> Why not simply use ftp for that ?
>
Because we don't want to hard code a password into the script, and an
anonymous ftp isn't secure enough.
-Angela Molnar
Hewlett Packard
angela_molnar@hp.com
------------------------------
Date: 12 May 1998 15:00:29 -0400
From: mjd@op.net (Mark-Jason Dominus)
Subject: Re: Dealer locator with zipcodes
Message-Id: <6ja68d$ahl$1@monet.op.net>
Keywords: lull padlock selector stratify
In article <35587796.0@inout.beachnet.com>,
Brian Channell <channell@southbay.com> wrote:
>Has anyone created a Perl script that can parse a Zipcode to find a dealer
>in a directory (flatfile format).
I have, several times.
> Any pointers or directions would be helpful thanks.
OK.
ZIP CODE SEARCHING IS A MISTAKE
Mark-Jason Dominus
Plover Systems
mjd@plover.com
Copyright 1996 M-J. Dominus
Distribution of this document without alteration is permitted.
LONG AND SHORT OF IT
Zip code searching works badly and gives the user less useful
information than city-state searching.
This paper gives a lot of reasons why that is and explains what goes
wrong when you try to use zip codes.
The reasons are not things I made up, but things I leanred from
developing both kinds of locator application for commercial web sites.
RECOMMENDED DESIGN OF GEOGRAPHIC LOCATOR
I recommend this alternative to zip code searching:
We offer you, the user, the chance to enter your city and their state.
(For the rest of this paper, you are the user.)
--------------------------------------------------------------------------
Enter the name of your town: [................................]
Enter the name of your state: [................................]
[FIND VENDORS]
--------------------------------------------------------------------------
The application will respond to you with one of three pages:
1. A page with a list of vendors in your city.
2. A page with a list of all the cities in your state that have vendors.
3. A page with a list of all the cities in the country that have the
same name as your city.
You, the user, would like to get page #1. Our job is to get you to
page #1 quickly and simply. If there is a vendor in your town, we
show you page #1 immedaitely. Most often, that is what happens.
If there are vendors in your city, but you made a typographic error
and misspelt your city name, you get page #2 with an alphabetic list
of the cities in your state. You click on your city name. Now you
are on page #1, which is where you wanted to be. You got there
quickly and easily.
If there are no vendors in your city, you get page #2, the alphabetic
list of cities in your state. You glance over the list, find a nearby
town that is easy to get to, or you find the town where you work, or
some other convenient place, which might or might not be nearby, and
click it. Now you are on page #1, where you wanted to be. You didn't
get a vendor in your town, because there aren't any; instead you got a
vendor from a town that is convenient for you.
If you omitted or misspelt the state name, but your city name is
unique (like `Chicago') the application deduces your state and
displays page #1 immediately, as though you hadn't erred. If your
city name is not unique (there are many towns named `Springfield') you
get page #3 and click on the one you want. If your city name doesn't
appear anywhere, you get the input form back with a message that says
that the application couldn't understand your state name and to please
try again.
The Clinique counter locator at
http://www.clinique.com/app/nph-locator.cgi
demonstrates this behavior. The rationale for the recommended
behavior is below.
WHY USE ZIP CODES AT ALL?
To show why zip codes are the wrong thing to use, I have to discuss
why they might appear to be the right thing.
Usually, people who want zip code locators seem to have one of these
reasons:
1. It appears to be more modern and computer-oriented than an
old-fashioned city and state pair. It appears more `magical' than
using city and state.
My thesis in this paper is that having a zip-code based locator is
actually a disservice to the user. So we're going to discard reason
#1. Looking cool is not a good reason to saddle the user with poorer
functionality. People already have to suffer enough from computer
applications without having us stick it to them as well.
2. It's short, so it's easy to type.
This is a good reason. But it's also a very small reason, because
typing your city and state is just not a very big deal. My thesis in
this paper is that the benefit to the user of a city-state-based
search is much, much greater than the benefit of typing a zip code
instead of a city and state. I'm not going to address this point
directly, but I will present enough advantages of city-state searching
over zip code searching that I think that this argument #2 will be
refuted along the way.
3. A zip code efficiently identifies a very specific geographic region.
This is an excellent argument. Here's what a client of mine once said:
> The rationale is that ZIP code allows the user to pinpoint a location more
> effectively. ZIP code is a much finer filter than city. States contain
> cities, cities contain ZIP codes.
He's correct: Zip codes *are* more specific that city-state pairs.
The main point of this paper is that finer granularity and geographic
specificity don't yield any benefit. So mostly I'll be refuting this
argmuent #3.
This is for the following reasons:
1. Zip codes are *not* geographic.
2. The granularity is *too fine* for the application.
3. Finer granularity is not necessarily better, anyway.
4. Zip code regions are not meaningful to anyone but the post
office.
5. Geographic proximity is not really useful anyway.
6. Zip codes are parochial.
This is the part of the paper that is not obvious, that we had to learn
from experience.
ZIP CODES ARE NOT GEOGRAPHIC
You might think they are, but they're not. This is a central fact in
this paper; if you believe that zip codes are geographically arranged,
you're mistaken. They are a little bit geographic, but not as much as
most people were led to believe.
I offer the following examples of how zip codes are not geographic.
There are hundreds of similar examples everywhere.
1. In many places, such as upstate New York and southeastern
Pennsylvania, zip codes were assigned to towns all at once in the
1960's, in alphabetic order by town name. Towns with `A' names got
lower zip codes than towns with `Z' names. Towns were assigned
numerically close zip codes not when they were geographically
close, but when their names were alphabetically close.
2. Staten Island has 103xx zip codes. The Bronx has 104xx zip codes.
In between Staten Island and the Bronx is Manhattan, with 100xx zip
codes. If the locator assumes a correlation between numeric
proximity and geographic proximity, it will think that the Bronx is
closer than Manhattan to Staten Island. If there are no vendors in
Staten Island, it will tell users there to go to the Bronx instead
of to Manhattan. They would almost certainly prefer Manhattan.
3. Many places have fluke zip codes. Center City Philadelphia is
mostly 191xx zip codes, where xx is in the range 01-12. But there
is one zip code district in Center City that just happens to be
19146. Zip code locators always refer people in this district to
locations in Overbrook. There is at least one of these in every
large city I have examined.
4. Two zip code regions might be adjacent, but in different states.
In this case, the two areas are geographically adjacent, but the
zip codes will be completely different.
5. Get a zip code map of your local area. Look at it for fifteen
minutes. You will never again believe that zip codes reliably
reflect geographic proximity.
THE GRANULARITY IS TOO FINE FOR THE APPLICATION
It is precisely the finer granularity which renders zip codes
inappropriate for most applications.
Your database probably no more than 10,000 vendors. You cannot put
10,000 things into more than 10,000 boxes. Since there are 100,000
zip codes, most zip codes will contain zero vendors. This means that
most searches will fail. You put in your zip code, and we don't find
any vendors in your zip code region.
We have two choices about what to do when a search fails:
1. Automatically expand the search to include `nearby' zip codes, or
2. Present the user with a list of working zip codes to choose from.
(There are some other choices that are obviously bad.)
(1) works badly, because the computer cannot tell which zip codes are
`nearby.' Many locator applications do this: they ask you for a zip
code, and return the items from the database whose zip codes were
numerically closest to the requested zip code. This does not work
because zip codes are not geographically assigned. Users in Staten
Island (103xx) are referred to offices in the Bronx (104xx) rather
than in Manhattan (100xx), even though Manhattan is surely more
convenient.
Furthermore, this kind of expansion coarsens the granularity of the
search. And instead of dividing the world into well-understood,
well-defined granules such as towns, it divides it into
poorly-understood, unpredictable granules: groups of zip code regions
with numerically close zip codes.
(2) is no good for similar reasons. Although everyone knows their own
zip codes, nobody knows very well which zip codes are nearby. Nobody
can choose meaningfully from a list of zip codes, hoping to get
something convenient. (If you look at the zip code map for your area.
I am quite confident that you will see the problem.)
In short: Most zip codes contain no vendors, so most searches fail.
The obvious methods for expanding the search region to include an area
with a vendor all depend on the assumption that zip codes have some
relation to geography. But they have much less to do with geography
than most people think they do.
I have often wanted to try zip code search on a geographic database
with several million records to see how well it worked. I think that
zip code search would be much more suitable for such an application.
FINER GRANULARITY IS NOT NECESSARILY BETTER ANYWAY
A rationale for zip code search is that it is finer-grained than
city-state search. A little thought shows that this is not
necessarily a good thing!
I believe that if the locator can't be sure of producing exactly the
right information, it's better to produce too much information than
too little. If the locator produces too much information, you might
throw it all away in disgust, but you at least have the option of
going through it and picking out the useful items. You can make your
own decision about how much the information is worth to you.
However, if the locator produces too little information, and omits the
useful items, you have no options at all. It has disempowered you:
You don't have what you wanted, and you have no way to get it.
ZIP CODE REGIONS ARE NOT MEANINGFUL TO ANYONE BUT THE POST OFFICE.
The way the Clinique locator works is that you enter your city and
state and get a list of all the counters in your city. If the search
fails because there's no match for your city, you get a list of cities
that are in your state.
Unlike zip codes, everyone knows the names of nearby, convenient
towns, and can choose a good one quickly from a list. Also, people
are very good at quickly locating familiar names in a list of names;
they are much less good at locating familiar numbers in a list of
numbers.
Imagine you are locating a vendor, and there is none in your town.
You have just gotten a menu of other towns in your state, sorted
alphabetically; each town in the list has a vendor. This is obviously
useful, and the next step for you, the user, is obvious. What would
it be like if this were a list of zip code numbers instead?
GEOGRAPHIC PROXIMITY IS NOT REALLY USEFUL ANYWAY
A big argument in favor of zip code search is that we can produce a
`convenient' vendor for the user. What do we mean by `convenient'?
It turns out that what we meant by `convenient' is `geographically
nearby.' Although we've seen above that zip codes don't deliver on
their promise of geographic proximity, I want to argue that geographic
proximity is not the same as convenience anyway.
The idea of `convenience' is a very complex one. It combines
geographic proximity, traffic conditions, available public
transportation, whether or not the user owns a car, whether they work
near their home, etc. If there's no vendor near their home, it might
be convenient for them to visit a vendor near their place of
employment. It is unrealistic to expect the computer to deduce
`convenience' assisted only by zip code numbers. But a user can
select a convenient town from a list of towns quite easily.
`Convenience' in this application will only come from the user's
instructions. Since the computer cannot decide which vendors are more
`convenient,' it should try to produce a larger list, from which the
user can select the `convenient' vendors, rather than a small list
that is likely to omit many of the most convenient vendors. This
works as long as the large list is not too large. Obviously, a list
of 100 items would be too large.
However, your database probably has no more than 10,000 records for
the entire country, and it is unlikely to contain as many as 100 in
any single town, even New York. (Remember that big cities like New
York are really many small towns, such as New York, Brooklyn Heights,
Bayside, Jamaica, Great Neck, Yonkers, and soforth, rather than one
large town.)
ZIP CODES ARE PAROCHIAL
The Internet is an international medium. Your web site will be
available to people all over the world. Zip codes, however, only
identify locations in the United States.
Even if present plans don't include a vendor locator for vendors
outside the USA, it's conceivable that one day your company might want
to expand the function to include locating vendors in other countries.
The zip code application cannot be expanded; it has to be discarded.
The city-state application can be used without change, or it can be
easily enhanced to be a city-state-country locator.
CONCLUSION
We've tried it already, and it didn't work.
------------------------------
Date: 12 May 1998 19:28:18 GMT
From: gbacon@cs.uah.edu (Greg Bacon)
Subject: Re: Does Perl have a IDE?I don't like command line.
Message-Id: <6ja7si$65p$3@info.uah.edu>
In article <6ja1lg$5ab$1@mathserv.mps.ohio-state.edu>,
ilya@math.ohio-state.edu (Ilya Zakharevich) writes:
: Yes, when I'm on Solaris, I'm forced to use some broken way like
: pfind'ing (grep is absolutely useless unless you know how deep you
: need to search) if I need to lookup DOCs.
What do you have against man -k or apropos? I guess you've missed
tcgrep which has been posted to clpm at least twice and is also
available on the CPAN. I can also mail you a copy if you'd like. It's
written entirely in Perl and has an option for descending recursively
into directories (plus other niceties).
There's a reason we don't produce infopages by default, you know. :-)
Greg
--
open(G,"|gzip -dc");$_=<<EOF;s/[0-9a-f]+/print G pack("h*",$&)/eg
f1b88000b620f22320303fa2d2e21584ccbcf29c84d2258084
d2ac158c84c4ece4d22d1000118a8d5491000000
EOF
------------------------------
Date: 12 May 1998 19:23:11 GMT
From: gbacon@cs.uah.edu (Greg Bacon)
Subject: Re: Does Perl have a IDE?I don't like command line.
Message-Id: <6ja7iv$65p$2@info.uah.edu>
In article <6j9vhj$8v@mozo.cc.purdue.edu>,
gebis@albrecht.ecn.purdue.edu (Michael J Gebis) writes:
: gbacon@cs.uah.edu (Greg Bacon) writes:
: }By ``get'', I'm assuming you mean software is unavailable.
:
: Nope, I wouldn't have put it in quotes if I had meant that. I mean
: that that some people just don't think "I need help, thus I
: should go the the command line, or a separate program, or whatever."
What's not to understand? You request the manual page on a subject, the
program finds it, formats it, and displays it. Tuits are far too
precious to waste on trying to cater to such a low denominator.
One nice aspect of Perl and open source model software is that the end
product is usually a function of the demand. If the software doesn't
yet have some feature, it's safe to assume that the demand or the tuit
supply is low (or perhaps both).
: I can't understand why you
: fail to see value in spreading that documentation in a way that many
: newbies expect.
No one can know the expectations of every platform's users. That is why
most ports have a champion or group of champions who provide extra
niceties for their fellow XYZ OS users.
: I feel I shouyld once again state that the efforts of the perl
: documentation authors are not in question here. I just think that
: categorically denying the value of an IDE is short-sighted.
If you tell people ``hey, there's this program called perldoc that can
supply you with Perl documentation'' and they're still lost, Perl is too
large a first step.
: }Programming languages aren't and should never be everyday things.
:
: That's a very witty but content-free response.
The fact of the matter is that despite what some would have you believe,
programming is an art that requires years of training and practice to
master. Would you allow an untrained surgeon to perform an invasive
procedure on you? Scalpels aren't and should never be everyday things.
It just doesn't make any sense to refer to a programming language as an
everyday thing.
Greg
--
open(G,"|gzip -dc");$_=<<EOF;s/[0-9a-f]+/print G pack("h*",$&)/eg
f1b88000b620f22320303fa2d2e21584ccbcf29c84d2258084
d2ac158c84c4ece4d22d1000118a8d5491000000
EOF
------------------------------
Date: 12 May 1998 19:34:10 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Does Perl have a IDE?I don't like command line.
Message-Id: <6ja87i$g2k$2@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc, keithmur@mindspring.com writes:
:I'm one of those nasty Windows programmers).
As opposed to being one of the nice ones? :-)
:Seems like the
:Gecko got me started pretty well and I needed something for a little
:added insight.
PCB will be out this summer, and should do that.
:And the Camel seems to overlap a lot with the man/html
:pages, so I skipped that. Am I missing a lot?
Yes and no.
:By the way, I *love* Effective Perl Programming, though I've noticed a
:couple of errors so far...
It's a 3.5 camel book, more or less. I guess I have to
give it 4, unless I demote some of the 3's to 2.5's.
--tom
--
"When you type to Unix, a gnome deep in the system is gathering your
characters and saving them in a secret place." - Unix 6th edition manual
------------------------------
Date: Tue, 12 May 1998 12:48:48 -0700
From: Jon Drukman <jsd@gamespot.com>
Subject: Re: Does Perl have a IDE?I don't like command line.
Message-Id: <3558A7A0.B986FC43@gamespot.com>
Greg Bacon wrote:
> If you're interested in colored
> syntax, perhaps you should look into psychoactives.
nice one.
> What happens when it gives something the wrong color? That seems like
> it would confound debugging even more.
apparently you have never used a syntax-coloring editor. they are
helpful far more often than they are confusing. i have found many bugs
before i even saved the file thanks to the combination of syntax
coloring and auto-identing provided by ilya's cperl-mode for xemacs.
> : local $" = ':'; #" Quote added for BBEdit
>
> Ugh. Isn't it bad enough that we have to work around compilers (for
> other languages)? Must we now work around editors with pseudo-syntax
> coloring? Can we say ``maintenance nightmare'', class?
how are comments "maintenance nightmares"? what's the worst that
happens? you leave it out and the rest of the file turns a funny
color... that impacts the usefulness of the code in what way exactly?
> Yet you still defend it. Use vi and %-friendly regular expression
> delimiters. :-)
regular expression delimiters are there to serve the programmer, not the
editor. this is the same behavior you were just railing against. i
realize you slapped a smiley on it but i don't think that excuses or
justifies it.
--
Jon Drukman jsd@gamespot.com
-----------------------------------------------------------------------
Plan: Eat right, exercise regularly, die anyway.
------------------------------
Date: Tue, 12 May 1998 20:33:49 -0700
From: Jan Krynicky <jkry3025@comenius.ms.mff.cuni.cz>
To: David@iqtexas.com
Subject: Re: ERROR: odbc.pm, &AutoLoader::AUTOLOAD
Message-Id: <3559149D.3490@comenius.ms.mff.cuni.cz>
David@iqtexas.com wrote:
>
> RE: odbc, sql
>
> I am attempting to print the contents of an Access DB.
> The script fails @ Fetchrow. The DB appears to be setup correctly in ODBC
> manager.
>
> The output is below, then the script.
>
> The DB was created by the ODBC manager. I then went into access to create
> the table 'logon'.
>
> Thanks for any help,
> -David
>
> >>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
> OUTPUT__________________________________
>
> Content-Type: text/html
>
> <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML//EN">
> <HTML><HEAD><TITLE>Untitled Document</TITLE>
> </HEAD><BODY><HR><table>
> Goto undefined subroutine &AutoLoader::AUTOLOAD at D:\Perl\lib/Win32/ODBC.pm
> line 861.
>
> SCRIPT___________________________________
> # logon.mdb test
>
> use CGI qw(:standard);
> use Win32::ODBC;
>
> print header;
> print start_html(),hr();
>
> $dsn="NetData";
> if (!($db=new Win32::ODBC($dsn,"Internet","odbc"))){
> print "Error connecting to $DSN\n";
> print "Error: ",Win32::ODBC::Error(),"\n";
> print hr(),end_html;
> exit;
> }
>
> $db->Sql(" SELECT * FROM [logon] ");
>
> print "<table>\n";
>
> $i=0;
> while ($db->Fetchrow()) {
Should be
while ($db->FetchRow()) {
Perl is case sensitive!
HTH, Jenda
BTW, Dave couldn't you fix the sub AUTOLOAD to provide a reasonable
error message?
------------------------------
Date: Tue, 12 May 1998 14:34:52 -0400
From: comdog@computerdog.com (brian d foy)
Subject: Re: File type sniffer
Message-Id: <comdog-ya02408000R1205981434520001@news.panix.com>
Keywords: from just another new york perl hacker
In article <Pine.GSO.3.96.980512101503.21974B-100000@user2.teleport.com>, Tom Phoenix <rootbeer@teleport.com> posted:
>On Tue, 12 May 1998, John Henson wrote:
>
>> Anyone know of a utility to determine file types..i.e. image files,
>> Quark Xpress files from the headers?
>
>Yes, it's the 'file' command, available on many Unix-type systems. If you
>need help with it, people in a newsgroup about Unix systems may be able to
>help you. Good luck!
although `file` will go a long way, this sounds like it could be a
really cool Perl module. reproducing the functionality of `file`
should be pretty easy, and the module can select an appropriate
magic file for the platform.
hmmm... :)
--
brian d foy <comdog@computerdog.com>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
Perl Mongers <URL:http://www.pm.org>
looking for things to do during code freeze
------------------------------
Date: 12 May 1998 19:30:56 GMT
From: Tom Christiansen <tchrist@mox.perl.com>
Subject: Re: Grieving our dying community
Message-Id: <6ja81g$g2k$1@csnews.cs.colorado.edu>
[courtesy cc of this posting sent to cited author via email]
In comp.lang.perl.misc,
tina@tech.scandinaviaonline.se writes:
: More or less the same time Perl became synonymous with WWW. Which has
:later been told us ad nauseam.
Perl has never been, nor ever shall be, an end-user consumerible. [sic]
The end-users need to realize this and stop begging to be fed by IV.
--tom
--
"A momentary lapse of stupidity" -- Dean Roehrich
------------------------------
Date: 12 May 1998 17:57:16 GMT
From: angst <angst@scrye.com>
Subject: Re: How can you break out of a 'while... ' loop in a function?
Message-Id: <6ja2hs$c64$1@jelerak.scrye.com>
Tina Marie Holmboe <tina@scandinaviaonline.se> wrote:
: To me, though I am admittedly strange, they translate to goto... there
: *is* some good advice in not breaking out of while-loops - or any other
: loops - in more than one place.
Okay, goto where? I can see where you would get this in the case of last,
but next? Sure, it's probably functionally equivalent in something like a
while() loop, but what about a for or foreach loop? Where do you put the
goto marker for next? If you put it inside the loop, the counter (or pointer
to the array) doesn't get incremented properly. If you put it directly
before the loop, the counter (or pointer to the array) gets _re-initialized_,
which is hardly what you want to replace a next.
: Sortof makes things easier to work with, IMHO.
I don't see why replacing functions as intuitive as next and last with
a function that doesn't provide the same functionality (without a lot of extra
code) is easier to work with. By the same token, if it's necessary to
use next and last rather than goto in for and foreach loops (and I think
it is, otherwise there's no purpose in using a for or foreach loop), then
why would it be less intuitive to use the same thing for all loops, rather than
using goto in a while()? Maybe I'm just not understanding what you're saying
here.
--
Erik Nielsen <eln@rmci.net>
solaris/perl/qmail/dns weenie
this post != views of anyone at all, really
"You are like...unix GOD" -- local tech support
------------------------------
Date: Tue, 12 May 1998 14:15:12 -0400
From: "Phil R Lawrence" <prl2@lehigh.edu>
Subject: initializing $self
Message-Id: <6ja3jb$h0k@fidoii.cc.Lehigh.EDU>
I have a module that constructs and blesses a new self. Other methods store
values in $self using one of the two following ways:
$href = $self->{key1}{key2};
$href->{key3} = 'value';
or
$self->{key1}{key2}{key3} = 'value'
Problem:
If I haven't yet initialized the self hash up to key2 and say
$href = $self->{key1}{key2};
I get null instead of an hash reference
Solutions:
1. Initialize the whole hash in the new method:
sub new {
<snip!>
$self = { key1 => { key2 => { key3 => ' ' } } };
<snip!>
}
Performance / memory issues?
2. check the value of $self->{key1}{key2} before I assign to $hashref. This
seems cumbersome.
Which solution would you recommend? Or perhaps another?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Phil R Lawrence phone: 610-758-3051
Programmer / Analyst e-mail: prl2@lehigh.edu
194 Lehigh University Computing Center
E.W. Fairchild - Martindale, Bldg. 8B
Bethlehem, PA 18018
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
------------------------------
Date: Tue, 12 May 1998 15:07:40 -0400
From: "Ronald A. Andersen" <ronandersen@hotmail.com>
Subject: Insecure $ENV
Message-Id: <35589DFC.1654@hotmail.com>
When I execute a the following Perl script with the SUID set, I receive
the following message. What does it mean?
****************************************************************
#!/usr/bin/perl
($username, $passwd, $userid ) = getpwnam (getlogin());
`/etc/httpd -f /home/$username/web/conf/httpd.conf`
****************************************************************
output message --> Insecure $ENV{PATH} while running setuid at
/usr/local/bin/start_web.pl line 4.
ronandersen@hotmail.com
------------------------------
Date: 12 May 1998 19:18:48 GMT
From: ryan@mail.ramresearch.com (Ryan McGuigan)
Subject: Re: Installing PERL on NT
Message-Id: <6ja7ao$398$1@news.fred.net>
Glenn Morgan (gmorgan@photographics.co.uk) wrote:
: Try downloading the Win32 port from www.activestate.com
: It's a self extracting binary distribution, just download it and then
: exectue the file to install it.
: I've not had any problems with - dead easy.
No offense but you must not do much with it. Activestate's distribution
of perl is very limited. For a decent distribution of perl for win32, try
Garusamy Sarathy's distribution, you can download it from CPAN.
: Hauk Langlo wrote in message <3557F603.33C0D4B0@forumnett.no>...
: >Hi there. After using PERL at work for some weeks I have finally got my
: >own PC at home. I'm pretty new to the PC format and have not managed to
: >successfully install/build perl on my PC. I got a file called
: >perl5.00402-bindist04-bc. I have done the installation process but my
: >perl programs will not work like they do at my job, they will not work
: >at all really. Do anyone know exactly what kind of thins I will have to
: >do in order to run PERL programs on my Win-NT PC? Any help would be
: >apprecuated. Thanks.
: >
: >Hauk Langlo (JAPH)
: >
: >
------------------------------
Date: Tue, 12 May 1998 14:14:03 -0400
From: comdog@computerdog.com (brian d foy)
Subject: Re: Learning Perl vs Programming Perl (Books)
Message-Id: <comdog-ya02408000R1205981414030001@news.panix.com>
Keywords: from just another new york perl hacker
In article <Treeskunk-1105981828100001@beethoven.triplesoft.com>, Treeskunk@aol.com (Treeskunk) posted:
>I'm a programmer and am interested in both of these books. I would like
>to get Learning because it talks about CGI. However, I would like to get
>Programming because I feel it is probably more for programmers. Any
>suggestions? Is the information from the CGI chapter in Learning available
>anywhere else (on the net) so if I get Programming I will not miss
>anything?
the information on CGI programming in the Llama is available
directly from the CGI.pm documentation and other resources (see
the CGI Meta FAQ for instance). in my opinion, that particular
chapter is not the reason to buy the book.
i recommend buying both books though - Learning Perl is a tutorial,
while Programming Perl is a reference book.
good luck :)
--
brian d foy <comdog@computerdog.com>
CGI Meta FAQ <URL:http://computerdog.com/CGI_MetaFAQ.html>
Comprehensive Perl Archive Network (CPAN) <URL:http://www.perl.com>
Perl Mongers <URL:http://www.pm.org>
------------------------------
Date: 8 Mar 97 21:33:47 GMT (Last modified)
From: Perl-Request@ruby.oce.orst.edu (Perl-Users-Digest Admin)
Subject: Digest Administrivia (Last modified: 8 Mar 97)
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.
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 2568
**************************************
