[12221] in Perl-Users-Digest
Perl-Users Digest, Issue: 5821 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Fri May 28 18:07:17 1999
Date: Fri, 28 May 99 15:00:20 -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 Fri, 28 May 1999 Volume: 8 Number: 5821
Today's topics:
calling C from perl - again <kuzniar_slavek@jpmorgan.com>
Changing password w/ Perl on Solaris <anthony@nc.com>
Re: cont'd <upsetter@ziplink.net>
Dealer Locator <webmaster@coastalpet.com>
Re: Dealer Locator (Greg Bacon)
Re: Hash References <uri@sysarch.com>
Re: Help, HTML entities (Greg Bacon)
Re: how to upload file from the form? (Alastair)
Re: Incrementing a value in a slice (Greg Bacon)
Re: Incrementing a value in a slice <uri@sysarch.com>
Re: Newbie: How to post data? (Alastair)
Re: Newbie: Line spacing <upsetter@ziplink.net>
open() question <bklimov@mitre.org>
Re: open() question (Andrew Allen)
Re: PB writing an uploaded file in perl (size changes!) <dgris@moiraine.dimensional.com>
Re: PB writing an uploaded file in perl (size changes!) (Larry Rosler)
RE: Programming Web Graphics with Perl and GNU Software (Chris Davies)
Re: String Substitution & \t (Larry Rosler)
Re: Strip "http" from URL's (Greg Bacon)
Re: Thanks man....HOWS THIS? (I R A Aggie)
Re: Y2K infected Perl code (Stefaan A Eeckels)
Re: Y2K infected Perl code (Stefaan A Eeckels)
Re: Y2K infected Perl code <dgris@moiraine.dimensional.com>
Re: Y2K infected Perl code (Larry Rosler)
Re: Y2K infected Perl code ()
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Fri, 28 May 1999 17:25:48 -0400
From: slawomir kuzniar <kuzniar_slavek@jpmorgan.com>
Subject: calling C from perl - again
Message-Id: <374F09DC.CEFF6DAE@jpmorgan.com>
I realize that this question has been asked many times before but
reading threads and going through man pages did not help much.
We have perl module that is using C network library do to some
client-server interaction. Recently I had to make some changes in the C
library and as an experiment I used C++. Library still exposes only C
interface, only internally uses C++. Now after building perl module I
get run-time error as follows:
Can't load './blib/arch/auto/RDI/RDI.so' for module RDI: ld.so.1:
/usr/local/bin/perl: fatal: relocation error: file
./blib/arch/auto/RDI/RDI.so: symbol _pure_error_: referenced symbol not
found at /usr/local/perl/5.4.0.0/lib/sun4-solaris/5.00404/DynaLoader.pm
line 166.
at test.pl line 11
BEGIN failed--compilation aborted at test.pl line 11.
The problem is caused by dynamic loader not beeing able to locate
_pure_error_
symbol which is not present in libc.so.
I tried building module with CC=CC, LD=CC, LIBC=/lib/libC.so without
success.
While running 'perl -V' I see that it has numerous settings that point
to C compiler and libraries, rather than C++.
Do I have to re-install perl to make this working?
As you may have noticed, I just started playing with perl.
------------------------------
Date: Fri, 28 May 1999 14:01:16 -0700
From: Anthony Lee-Masis <anthony@nc.com>
Subject: Changing password w/ Perl on Solaris
Message-Id: <374F041C.1EE6FE33@nc.com>
Hi people,
here's my problem, hope you can help.
I have a cgi perl script that reads some data from a form. Part of the
data i get is a username and password. I'd like to at that time take
those pieces of information and change the users system password.
I've tried a few things and have had no success. My last attempt was to
try something like this -
code....
open(PASS, "| passwd $username") || die "Can't fork: $!\n";
print PASS "$password\n";
print PASS "$password\n":
close(PASS);
rest of code ......
when i run this what comes up on the screen is a prompt for the New
password: ,
it seems like it's not reading it in from the script and prompting me
for it.
Any ideas suggstions on why this isn't working or a better method to do
this ?
Thanks for your time.
------------------------------
Date: Fri, 28 May 1999 21:52:54 GMT
From: Scratchie <upsetter@ziplink.net>
Subject: Re: cont'd
Message-Id: <WeE33.1103$nn.313908@news.shore.net>
jknoll@my-deja.com wrote:
:> i think we should add the deja.com domain to the list of, if you post
:> from there, you don't know perl.
: You know what, you are right. I don't know perl. THAT IS WHY IM ASKING
: YOU!!! I didnt understand it on my own, so I thought I would ask
: someone that did. But I cant even get an answer or any kind of help
: from this guy. Believe me, if I didnt exhaust my options I wouldnt have
: posted here.
It generally helps to know some perl before you post here. Sorry to break
it to you, but that's the truth. There are numerous ways to begin learning
perl, not necessarily limited to the book "Learning Perl", www.perl.com
and the docs that are installed *with* perl. Once you have a grasp of the
basics, this group is a good place to come if you have a specific piece of
code that isn't working, but it's not the best place for questions like
"Does perl have a way to do a global search-and-replace on a file?"
--Art
--
--------------------------------------------------------------------------
National Ska & Reggae Calendar
http://www.agitators.com/calendar/
--------------------------------------------------------------------------
------------------------------
Date: Fri, 28 May 1999 16:59:43 -0500
From: Webmaster <webmaster@coastalpet.com>
Subject: Dealer Locator
Message-Id: <374F11AD.82CF8977@coastalpet.com>
Does anyone know how to build a dealer locator? I've seen a quite a few
web sites running them. I need the user to be able to input their zip
code in a form and for that zip code to be compared to a text file on
the server. The script will find the zip code on the text file that is
closests to the zip code that was input by the user. In a nutshell I
need to give the website user the ability to type in there zip code and
find the nearest dealer in their area. I've seen this done but I'm not
real sure how to go about doing it. Any help would be greatly
appreciated.
weber@raex.com
------------------------------
Date: 28 May 1999 21:46:08 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: Dealer Locator
Message-Id: <7in2r0$p5n$6@info2.uah.edu>
In article <374F11AD.82CF8977@coastalpet.com>,
Webmaster <webmaster@coastalpet.com> writes:
: Does anyone know how to build a dealer locator? I've seen a quite a few
: web sites running them. I need the user to be able to input their zip
: code in a form and for that zip code to be compared to a text file on
: the server. The script will find the zip code on the text file that is
: closests to the zip code that was input by the user. In a nutshell I
: need to give the website user the ability to type in there zip code and
: find the nearest dealer in their area. I've seen this done but I'm not
: real sure how to go about doing it. Any help would be greatly
: appreciated.
Maybe you didn't see this the first time around:
---
From: mjd@op.net (Mark-Jason Dominus)
Newsgroups: comp.lang.perl.misc
Subject: Re: Dealer locator with zipcodes
Date: 12 May 1998 15:00:29 -0400
Organization: Plover Systems
Message-ID: <6ja68d$ahl$1@monet.op.net>
References: <35587796.0@inout.beachnet.com>
Keywords: lull padlock selector stratify
X-Motto: Why, it's...PLOVERICIOUS!
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.
---
Hope this helps,
Greg
--
Beauty is in the eye of the beer holder...
------------------------------
Date: 28 May 1999 17:11:20 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Hash References
Message-Id: <x7u2swhpc7.fsf@home.sysarch.com>
>>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
LR> Semi-demi-gods, at best. :-)
s/S/Hemi-S/ ;
>> I am having trouble trying to dereference an array of hashes that
>> references arrays. I access each hash list as follows:
>>
>> @{$Records[$i]{$Key}}[$j]
you don't show what is in @records.
when when you doing a complex dereferencing and you want a single value,
it is better to use the -> notation.
assuming $records is an array ref:
$records->[$i] gives the hash reference.
$records->[$i]{$Key} gives the array reference.
$records->[$i]{$Key}[$j] gives the scalar value.
>> push (@new_hash_list, %{$Records[$i]})
LR> This unrolls the hash into key-value pairs and pushes them all onto
LR> @new_hash_list. What you want is an array of references:
LR> push (@new_hash_list, \%{$Records[$i]})
well, how the mighty 1/8 of a god has fallen!
that expression assume either $Records[$i] is a hash ref or a name of a
hash. if the former, then just $Records[$i] is fine and the \%{} is a
noop. if the latter, then you are guilty of promoting symbolic refs.
LR> Try it and see if that is the problem. (I didn't test my
LR> proposal, but semi-demi-gods don't have to do that, right? :-)
you do if you have to add the Hemi.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: 28 May 1999 21:44:35 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: Help, HTML entities
Message-Id: <7in2o3$p5n$5@info2.uah.edu>
In article <374D7C02.A0D508BF@pppl.gov>,
Dan Melomedman <dmelomed@pppl.gov> writes:
: Hi, trying to get rid of those HTML entities from the string $2, how can
: I get rid of it from the variable $2??
:
: foreach $line (@state){
: push @{$1}, $2 if $line =~ /(.*?)=(.*)/;
: ${$1} = $2 =~ if $line =~ /(.*?)=(.*)/;
: }
=head2 How can I use a variable as a variable name?
Beginners often think they want to have a variable contain the name
of a variable.
$fred = 23;
$varname = "fred";
++$$varname; # $fred now 24
This works I<sometimes>, but it is a very bad idea for two reasons.
The first reason is that they I<only work on global variables>.
That means above that if $fred is a lexical variable created with my(),
that the code won't work at all: you'll accidentally access the global
and skip right over the private lexical altogether. Global variables
are bad because they can easily collide accidentally and in general make
for non-scalable and confusing code.
Symbolic references are forbidden under the C<use strict> pragma.
They are not true references and consequently are not reference counted
or garbage collected.
The other reason why using a variable to hold the name of another
variable a bad idea is that the question often stems from a lack of
understanding of Perl data structures, particularly hashes. By using
symbolic references, you are just using the package's symbol-table hash
(like C<%main::>) instead of a user-defined hash. The solution is to
use your own hash or a real reference instead.
$fred = 23;
$varname = "fred";
$USER_VARS{$varname}++; # not $$varname++
There we're using the %USER_VARS hash instead of symbolic references.
Sometimes this comes up in reading strings from the user with variable
references and wanting to expand them to the values of your perl
program's variables. This is also a bad idea because it conflates the
program-addressable namespace and the user-addressable one. Instead of
reading a string and expanding it to the actual contents of your program's
own variables:
$str = 'this has a $fred and $barney in it';
$str =~ s/(\$\w+)/$1/eeg; # need double eval
Instead, it would be better to keep a hash around like %USER_VARS and have
variable references actually refer to entries in that hash:
$str =~ s/\$(\w+)/$USER_VARS{$1}/g; # no /e here at all
That's faster, cleaner, and safer than the previous approach. Of course,
you don't need to use a dollar sign. You could use your own scheme to
make it less confusing, like bracketed percent symbols, etc.
$str = 'this has a %fred% and %barney% in it';
$str =~ s/%(\w+)%/$USER_VARS{$1}/g; # no /e here at all
Another reason that folks sometimes think they want a variable to contain
the name of a variable is because they don't know how to build proper
data structures using hashes. For example, let's say they wanted two
hashes in their program: %fred and %barney, and to use another scalar
variable to refer to those by name.
$name = "fred";
$$name{WIFE} = "wilma"; # set %fred
$name = "barney";
$$name{WIFE} = "betty"; # set %barney
This is still a symbolic reference, and is still saddled with the
problems enumerated above. It would be far better to write:
$folks{"fred"}{WIFE} = "wilma";
$folks{"barney"}{WIFE} = "betty";
And just use a multilevel hash to start with.
The only times that you absolutely I<must> use symbolic references are
when you really must refer to the symbol table. This may be because it's
something that can't take a real reference to, such as a format name.
Doing so may also be important for method calls, since these always go
through the symbol table for resolution.
In those cases, you would turn off C<strict 'refs'> temporarily so you
can play around with the symbol table. For example:
@colors = qw(red blue green yellow orange purple violet);
for my $name (@colors) {
no strict 'refs'; # renege for the block
*$name = sub { "<FONT COLOR='$name'>@_</FONT>" };
}
All those functions (red(), blue(), green(), etc.) appear to be separate,
but the real code in the closure actually was compiled only once.
So, sometimes you might want to use symbolic references to directly
manipulate the symbol table. This doesn't matter for formats, handles, and
subroutines, because they are always global -- you can't use my() on them.
But for scalars, arrays, and hashes -- and usually for subroutines --
you probably want to use hard references only.
To decode and encode HTML entities, have a look at the HTML::Entities
module.
Greg
--
Only great masters of style can succeed in being obtuse.
-- Oscar Wilde
Most UNIX programmers are great masters of style.
-- The Unnamed Usenetter
------------------------------
Date: Fri, 28 May 1999 21:12:30 GMT
From: alastair@calliope.demon.co.uk (Alastair)
Subject: Re: how to upload file from the form?
Message-Id: <slrn7ku599.5l.alastair@calliope.demon.co.uk>
Gleb Ekker <globus@infonet.ee> wrote:
>Hi everybody,
>
>please, help is needed. I want to upload to the server a file from the
>form.
>I use <input name='data' TYPE='file'> in the form and Perl script get
>from it only path to a file and file name.
>How can script get the file from a local machine for the futher
>processing?
I think you should take a look at the CGI module (CGI.pm) and take a look at the
docs that come with it. A very good place to start ;
http://stein.cshl.org/~lstein/
HTH.
--
Alastair
work : alastair@psoft.co.uk
home : alastair@calliope.demon.co.uk
------------------------------
Date: 28 May 1999 21:37:16 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: Incrementing a value in a slice
Message-Id: <7in2ac$p5n$4@info2.uah.edu>
In article <x74skxhve5.fsf@home.sysarch.com>,
Uri Guttman <uri@sysarch.com> writes:
: i agree to a point. showing a beginner a simpler way and later the
: better but more idiomatic way is common.
I'm still not satisfied that you've established that your way is
better or even more idiomatic. The one advantage you might be able
to press with your snippet is that it's more specialized for the task
of finding the mode. Your approach doesn't preserve order either.
In production code, I like to separate code into task chunks as much
as possible to save some hair pulling for the poor sod who has to come
behind me to maintain it. Your approach loses style points in that
category too.
: where to draw the line is an
: issue. at the boston tutorials i heard a line (from randal?) which was
: something like teaching beginners is progressive lying. everything you
: teach early on is rescinded later with better techniques. i just like to
: start off with the better techniques instead of the simpler ones.
"I already have too much problem with people thinking the efficiency
of a perl construct is related to its length."
-- Larry Wall
Greg
--
We have enough youth, how about a fountain of SMART?
------------------------------
Date: 28 May 1999 17:58:24 -0400
From: Uri Guttman <uri@sysarch.com>
Subject: Re: Incrementing a value in a slice
Message-Id: <x7pv3khn5r.fsf@home.sysarch.com>
>>>>> "GB" == Greg Bacon <gbacon@itsc.uah.edu> writes:
GB> "I already have too much problem with people thinking the efficiency
GB> of a perl construct is related to its length."
GB> -- Larry Wall
i have shown and seen that many times here. efficiency analysis of perl
code is not something you can always eyeball.
uri
--
Uri Guttman ----------------- SYStems ARCHitecture and Software Engineering
uri@sysarch.com --------------------------- Perl, Internet, UNIX Consulting
Have Perl, Will Travel ----------------------------- http://www.sysarch.com
The Best Search Engine on the Net ------------- http://www.northernlight.com
------------------------------
Date: Fri, 28 May 1999 21:05:18 GMT
From: alastair@calliope.demon.co.uk (Alastair)
Subject: Re: Newbie: How to post data?
Message-Id: <slrn7ku4rp.5l.alastair@calliope.demon.co.uk>
keviny@hk.super.net <keviny@hk.super.net> wrote:
>Hi, all,
>
>I have read some html form basics and cgi tutorials but I couldn't find
>my answer. I would really appreciate it if you could give me some hints.
>Lots of tutorials assume you write your perl script on your server to
>generate HTML to be sent to the browser. However, I need the opposite: I
>have an HTML form that I use often and I want to automate this process
>on my client. I wanted to know how I can post data to the server using
>perl. I am new to perl, form and cgi.
I think you might want to take a look at the LWP (libwww) module. From the LWP
docs (lwpcook) ;
use LWP::UserAgent;
$ua = new LWP::UserAgent;
my $req = new HTTP::Request 'POST','http://www.perl.com/cgi-bin/BugGlimpse';
$req->content_type('application/x-www-form-urlencoded');
$req->content('match=www&errors=0');
my $res = $ua->request($req);
print $res->as_string;
HTH.
--
Alastair
work : alastair@psoft.co.uk
home : alastair@calliope.demon.co.uk
------------------------------
Date: Fri, 28 May 1999 21:55:21 GMT
From: Scratchie <upsetter@ziplink.net>
Subject: Re: Newbie: Line spacing
Message-Id: <dhE33.1104$nn.313908@news.shore.net>
Ed Bogart <e.h.bogart@larc.nasa.gov> wrote:
: They remind me of the
: days (a looooong time ago) when I was a computer center 'consultant' and
: the dweebs would come in with the printout from their first compile and
: announce that they had discovered a bug in the compiler!
Good thing that never happens around here! (colon-hyphen-left paren)
--Art
--
--------------------------------------------------------------------------
National Ska & Reggae Calendar
http://www.agitators.com/calendar/
--------------------------------------------------------------------------
------------------------------
Date: Fri, 28 May 1999 17:18:28 -0400
From: Boris Klimovitsky <bklimov@mitre.org>
Subject: open() question
Message-Id: <374F0819.CAA9F98E@mitre.org>
Hi, sorry if this is a FAQ (though I didn't see it in perldoc -q...)
open() takes at least two arguments, FILEHANDLE and an optional EXPR,
that being usually the file and any modifiers (<,>,+< etc), and then the
return value should be tested.
However, is there some way (without perhaps
for (@ARGV) {
open (FILE, $_) or die "Couldn't open $_: $!";
}
) to get the filename into $_ ?
Such that the open command would look more like
open (FILE, shift) or die "Couldn't open $_: $!";
or would that be unadvisable for some reason that escapes me at the moment?
And in this case I am thinking of only one argument, rather than
several.. so the command would look merely like:
command filename
as opposed to
command filename next_filename ...
Thanks,
Boris
------------------------------
Date: 28 May 1999 21:43:18 GMT
From: ada@fc.hp.com (Andrew Allen)
Subject: Re: open() question
Message-Id: <7in2lm$pms$1@fcnews.fc.hp.com>
Boris Klimovitsky (bklimov@mitre.org) wrote:
: ) to get the filename into $_ ?
: Such that the open command would look more like
: open (FILE, shift) or die "Couldn't open $_: $!";
Ummm... open(FILE,$_=shift) or die "Couldn't open $_: $!";
Andrew
------------------------------
Date: 28 May 1999 15:09:11 -0600
From: Daniel Grisinger <dgris@moiraine.dimensional.com>
Subject: Re: PB writing an uploaded file in perl (size changes!)
Message-Id: <m3pv3koqa0.fsf@moiraine.dimensional.com>
Uri Guttman <uri@sysarch.com> writes:
> here is a documentation suggestion. binmode for binary files should be
> discussed in perlport and linked to there from binmode and open in
> the docs.
Two things, Uri.
First, did you happen to check to see if these changes had been
made already?
Second, don't you think that you are a little beyond the `Gosh, I hope
somebody will make this patch for me' stage of perl hacking? That
attitude is tolerable from clueless newbies, y2k gurus, and others of
Reesian intelligence-- from actual perl hackers, though, it's
completely unacceptable. :-(
dgris
--
Daniel Grisinger dgris@moiraine.dimensional.com
perl -Mre=eval -e'$_=shift;;@[=split//;;$,=qq;\n;;;print
m;(.{$-}(?{$-++}));,q;;while$-<=@[;;' 'Just Another Perl Hacker'
------------------------------
Date: Fri, 28 May 1999 14:22:43 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: PB writing an uploaded file in perl (size changes!)
Message-Id: <MPG.11b8a90199eb5ca7989b28@nntp.hpl.hp.com>
In article <x7wvxtgcdc.fsf@home.sysarch.com> on 28 May 1999 16:36:47 -
0400, Uri Guttman <uri@sysarch.com> says...
> >>>>> "LR" == Larry Rosler <lr@hpl.hp.com> writes:
>
> LR> But TomC has made it clear that he, at least, will not adopt my
> LR> suggestion on how to eliminate this question being asked ad nauseam:
>
> LR> 'binmode' binary files on every implementation of perl!
>
> do you mean have perl do it? or the code call binmode on binary files
> regardless of the OS?
No. That is impossible. The programmer must do it.
The heuristic for the '-B' test (which we discussed recently) on input
files is far too unreliable. And what about output files?
> if the latter, then i still have a bone to pick as i am not writing to
> be platform independent in some cases. so i can skip it if i know the
> program is destined to always run on unix.
My point is -- why bother to skip it? The documentation and the books
and the teachers should say that This Is THE Way To Do It. Where it is
not needed, it costs NOTHING (modulo the time to read and parse one Perl
statement during compilation). Where it is needed, it is essential.
> here is a documentation suggestion. binmode for binary files should be
> discussed in perlport and linked to there from binmode and open in
> the docs.
At the least.
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Fri, 28 May 1999 19:38 +0100 (BST)
From: news@roaima.demon.co.uk (Chris Davies)
Subject: RE: Programming Web Graphics with Perl and GNU Software
Message-Id: <memo.19990528193831.30295A@roaima.demon.co.uk>
In article <14157.11498.483000.380395@gargle.gargle.HOWL>,
dsaff@tvisions.com (David Saff) wrote:
> Chris Davies writes:
> > 3. Change the test for a referer (lines 51 et seq) to be this,
> >
> > unless ($referer eq '' or $referer =~
> > /http:\/\/($users)(.*)/) {
> > exit $error->black_box('You do not have privileges' .
> > ' to access this counter.');
> > }
>
> Forgive me, but what are we accomplishing here? Admittedly, a referer
> can be easily fudged, but why make it easy on the fudger by accepting
> a null referer? I'm just not clear on the goal here. Thanks,
Agreed. However, if you look at the original code, you'll see a line that
sets the referrer to '' if it's not defined. I'm following through with
what I understand is the original programmer's ideas.
Note that it's not necessarily how I'd have approached the problem were I
to have coded it from scratch.
I like your suggestion of determining what the browser sends as its
referer. However, what about browsers that don't send referer information?
Given it's easy to fudge, we're not really going to save anything on
security (just convenience if someone tries to use the script from other
pages), so I don't see why we shouldn't simply accept an empty referer
value.
To the original poster: has either of the suggestions helped you, or are
we off on the wrong track(s)?
Regards,
Chris
--
FLARE Solutions Limited, Leeds, UK
Tel +44 (0)7970 987909 Email <info@roaima.demon.co.uk>
------------------------------
Date: Fri, 28 May 1999 14:40:44 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: String Substitution & \t
Message-Id: <MPG.11b8ad364e92eeb6989b29@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <374EFEB7.5A656D31@ix.netcom.com> on Fri, 28 May 1999
13:38:15 -0700, Clarence <djjr@ix.netcom.com> says...
> I'm new to perl so this is probably a easy question
> I'm trying to print out the following string(A directory)
> "\\usan\data\inet\transfer\choin"
> but it sees the \t in the string as a tab obviously. I tried
> substituting "\\" for every "\" in this small test program :
>
> #!/usr/bin/perl
> my $teststr="\\usan\data\inet\transfer\choin";
> my $teststr2="\\\\usan\\data\\inet\\transfer\\choin";
> print "$teststr\n";
> print "$teststr2\n";
> $teststr=~s/\/\\//g;
> print "$teststr\n";
>
> When I print $teststr2 I get the desired results
> but when I print $teststr I get the wrong results both before and after
> the substitution.
> This is what I get when I print $teststr : \usandata\inet\
> transfeoin
First of all, your regex doesn't say what you think. It says this:
"Delete every occurrence of forward-slash followed by back-slash."
Second of all, even if you used the regex you want:
s/\\/\\\\/g;
it wouldn't help much, because the string really contains only one
backslash (at the beginning). The others have been dropped (\d -> d, \i
-> i) or converted as escape sequences (\t -> tab, \ch -> backspace).
> I'm actually going to read these values from a Oracle database, so I
> need to clean them up before I print them.
Why? You are confusing the contents of a string (which you retrieve
from the database) which the way such a string might be written using a
Perl string literal.
> Am I approaching this the right way? Or is there a easier way to do
> this.
1. Print the strings as you get them from the database.
2. Use single-quotes around string literals when there is no
interpolation or escape-sequence processing.
3. Use forward slashes to represent directory delimiters. (The
Best Kept Secret of Windows/DOS.)
--
(Just Another Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: 28 May 1999 21:28:01 GMT
From: gbacon@itsc.uah.edu (Greg Bacon)
Subject: Re: Strip "http" from URL's
Message-Id: <7in1p1$p5n$3@info2.uah.edu>
In article <MPG.11b8901ea72f5545989b25@nntp.hpl.hp.com>,
lr@hpl.hp.com (Larry Rosler) writes:
: In article <m1g14hf2mf.fsf@halfdome.holdit.com> on 28 May 1999 11:52:40
: -0700, Randal L. Schwartz <merlyn@stonehenge.com> says...
: > Modules are useful. Don't knock them.
:
: They serve a useful purpose where pedantry is involved.
s/pedantry/completeness/
Greg
--
It has been discovered that C++ provides a remarkable facility for concealing
the trival details of a program--such as where its bugs are.
-- David Keppel
------------------------------
Date: 28 May 1999 20:51:57 GMT
From: fl_aggie@thepentagon.com (I R A Aggie)
Subject: Re: Thanks man....HOWS THIS?
Message-Id: <slrn7ku0ld.f6.fl_aggie@thepentagon.com>
On Fri, 28 May 1999 19:39:50 GMT, jknoll@my-deja.com <jknoll@my-deja.com>, in
<7imre6$24h$1@nnrp1.deja.com> wrote:
+ perl for my summer job. I couldnt find out how to do it, so i thought
+ someone here would know.
'perldoc perl' is your friend. Once you have become familiar with it,
and learnt how to 'grep' its wisdom, you'll be able to come up with
your own solutions in a much more rapid fashion than relying upon
usenet, making you look smart *and* handsome, causing the PHB to give
you a raise and promotion (without any real reason), and having babes
chase you down and beg you to be the father of their children...
James
------------------------------
Date: 28 May 1999 20:49:13 GMT
From: Stefaan.Eeckels@ecc.lu (Stefaan A Eeckels)
Subject: Re: Y2K infected Perl code
Message-Id: <7imvg9$e9l$1@justus.ecc.lu>
In article <374ed9b7.2337186@news.sgi.net>,
elcore@sgi.net (Lane Core Jr.) writes:
> On 28 May 1999 12:04:34 +0100, Jonathan Stowe
> <gellyfish@gellyfish.com> wrote:
>
>>I think that uri's point is that basically if someone is too dumb to have
>>read and understood the documentation for the localtime function then its
>>basically tough shit - it is not a problem with Perl its a problem with
>>the meatware.
>
> Yeah, but it's still a problem. :-(
But most emphatically *not* a Perl problem. If you use your
Toyota to kill a couple of pedestrians it is *your* problem,
not Toyota's.
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exupiry
------------------------------
Date: 28 May 1999 20:52:39 GMT
From: Stefaan.Eeckels@ecc.lu (Stefaan A Eeckels)
Subject: Re: Y2K infected Perl code
Message-Id: <7imvmn$e9l$2@justus.ecc.lu>
In article <KrB33.129$K2.4278@iad-read.news.verio.net>,
docdwarf@clark.net () writes:
>
> Please be so kind, then, as to address the situation posed and not my
> responses to it... what happens if a person writing code is not a 'retard'
> but the specs demand the adherance to certain standards?
If said standards mandate the introduction of bugs, then they
should be changed. If management is not prepared to accept
corrections to erroneous standards, get the hell out before the
joint goes bankrupt :-)
--
Stefaan
--
PGP key available from PGP key servers (http://www.pgp.net/pgpnet/)
___________________________________________________________________
Perfection is reached, not when there is no longer anything to add,
but when there is no longer anything to take away. -- Saint-Exupiry
------------------------------
Date: 28 May 1999 15:23:24 -0600
From: Daniel Grisinger <dgris@moiraine.dimensional.com>
Subject: Re: Y2K infected Perl code
Message-Id: <m3iu9copmb.fsf@moiraine.dimensional.com>
[posted only to clpm, it's still offtopic, but at least I know
the people there :-)]
Stefaan.Eeckels@ecc.lu (Stefaan A Eeckels) writes:
> In article <374ed9b7.2337186@news.sgi.net>,
> elcore@sgi.net (Lane Core Jr.) writes:
> > Yeah, but it's still a problem. :-(
> If you use your Toyota to kill a couple of pedestrians it is *your*
> problem, not Toyota's.
I think that the pedestrian's problem would be far greater than
your's or Toyota's. :-)
dgris
--
Daniel Grisinger dgris@moiraine.dimensional.com
perl -Mre=eval -e'$_=shift;;@[=split//;;$,=qq;\n;;;print
m;(.{$-}(?{$-++}));,q;;while$-<=@[;;' 'Just Another Perl Hacker'
------------------------------
Date: Fri, 28 May 1999 14:12:01 -0700
From: lr@hpl.hp.com (Larry Rosler)
Subject: Re: Y2K infected Perl code
Message-Id: <MPG.11b8a67be8966326989b27@nntp.hpl.hp.com>
[Posted and a courtesy copy mailed.]
In article <7imvcs$eho$1@mathserv.mps.ohio-state.edu> on 28 May 1999
20:47:24 GMT, Ilya Zakharevich <ilya@math.ohio-state.edu> says...
> [A complimentary Cc of this posting was sent to Larry Rosler
> <lr@hpl.hp.com>],
> who wrote in article <MPG.11b88d13c9d1bde9989b24@nntp.hpl.hp.com>:
> > > The nice thing about Open Source is, you can always hack
> > > the interpreter to change any string concatenation of
> > > a three-digit number to the literal "19" to be an addition.
This must mean 'an addition of 1900'. Ye gods!!!
> > > Problem solved.
> >
> > Barf bag provided? (I'll supply the smiley that you forgot. :-)
>
> In your infinite wisdom you may be interested to know that 5.00558 may
> contain code not *that* dissimilar to the above suggestion.
As history has shown you to be incapable of humor, Ilya, I must take you
seriously.
I thought that DWIMming was based on syntactic analysis. Applying it to
the contents of string literals takes it to new heights (depths?).
s?printf '...19%d...', ..., $year, ...;
will be next, I presume? That is the most likely manifestation of this
problem.
Trying to eliminate programmer bugs by fixing them 'under the covers'
seems inane, if not downright malicious.
--
(Just Another INFINITELY WISE Larry) Rosler
Hewlett-Packard Company
http://www.hpl.hp.com/personal/Larry_Rosler/
lr@hpl.hp.com
------------------------------
Date: Fri, 28 May 1999 21:22:58 GMT
From: docdwarf@clark.net ()
Subject: Re: Y2K infected Perl code
Message-Id: <SOD33.140$K2.4704@iad-read.news.verio.net>
In article <7imvmn$e9l$2@justus.ecc.lu>,
Stefaan A Eeckels <Stefaan.Eeckels@ecc.lu> wrote:
>In article <KrB33.129$K2.4278@iad-read.news.verio.net>,
> docdwarf@clark.net () writes:
>>
>> Please be so kind, then, as to address the situation posed and not my
>> responses to it... what happens if a person writing code is not a 'retard'
>> but the specs demand the adherance to certain standards?
>If said standards mandate the introduction of bugs, then they
>should be changed.
This, in a nutshell, is the heart of many Y2K flaws; that which 'should
have been' was not 'that which was'.
>If management is not prepared to accept
>corrections to erroneous standards, get the hell out before the
>joint goes bankrupt :-)
Ahhhh, but remember... *every* shop will state, at some point, 'Well, what
you says might have merit but we cannot do it that way... Things Are
Different Here.'
... and, of course, if Tings Are Different everywhere then Things Are The
Same everywhere.
DD
------------------------------
Date: 12 Dec 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 Dec 98)
Message-Id: <null>
Administrivia:
Well, after 6 months, here's the answer to the quiz: what do we do about
comp.lang.perl.moderated. Answer: nothing.
]From: Russ Allbery <rra@stanford.edu>
]Date: 21 Sep 1998 19:53:43 -0700
]Subject: comp.lang.perl.moderated available via e-mail
]
]It is possible to subscribe to comp.lang.perl.moderated as a mailing list.
]To do so, send mail to majordomo@eyrie.org with "subscribe clpm" in the
]body. Majordomo will then send you instructions on how to confirm your
]subscription. This is provided as a general service for those people who
]cannot receive the newsgroup for whatever reason or who just prefer to
]receive messages via e-mail.
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 5821
**************************************
