[12077] in Perl-Users-Digest
Perl-Users Digest, Issue: 5677 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat May 15 23:07:15 1999
Date: Sat, 15 May 99 20: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 Sat, 15 May 1999 Volume: 8 Number: 5677
Today's topics:
File uploading problem <ex5316@netvigator.com>
Re: How to change unix password with perl.... (Matthew Bafford)
Re: Parameter pass to PERL <rra@stanford.edu>
Re: Perl "constructors" <rra@stanford.edu>
Re: Perl "constructors" zenin@bawdycaste.org
Re: Perl "constructors" zenin@bawdycaste.org
Re: Perl "constructors" (Sam Holden)
Re: Perl "constructors" (Sam Holden)
Re: Perl "constructors" zenin@bawdycaste.org
Re: Perl "constructors" (Sam Holden)
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 15 May 1999 22:29:02 +0800
From: Alex <ex5316@netvigator.com>
Subject: File uploading problem
Message-Id: <373D84AE.78577766@netvigator.com>
Hi ,I really need your help.
I'm writting a perl script (for unix) that allow my visitors upload
their file to my server.
My problem is :
1. How can I create a new file when my visitor upload their file to my
server so that
I can open the "new created file" and write the "uploaded file" into the
"new created file"?
2. Or any other better methods ?
Thank you
------------------------------
Date: Sun, 16 May 1999 01:06:46 GMT
From: dragons@dragons.duesouth.net (Matthew Bafford)
Subject: Re: How to change unix password with perl....
Message-Id: <slrn7js5sl.1or.dragons@dragons.duesouth.net>
On Sun, 09 May 1999 23:37:44 GMT, Ryan Ngi <ryanngi@hotmail.com>
held some poor sysadmin at gun point while typing in the following:
: how to (not using system())?
Open the password file.
Lock the password file.
Open the temporary file.
Lock the temporary file.
Read the password file in line by line, changing passwords as you please,
writing the lines to the temporary file as you go.
Seek to the beginning of the password file.
Truncate the password file.
Seek to the beginning of the temporary file.
Read the temporary file in line by line, writing the lines back into the
password file.
Close the password file.
Unlink the temporary file.
Close the temporary file.
Of course, you _could_ just read the file into memory (skipping the
temporary file), but this wouldn't work to well the day you have
142,042,042 users on that one machine.
perldoc -f open
perldoc -f flock
perldoc -f readline
perldoc -f seek
perldoc -f truncate
perldoc -f print
perldoc -f close
perldoc -f unlink
perldoc -f crypt
perldoc perlop
perldoc perlre
YMMV
Hope This Helps,
--Matthew
------------------------------
Date: 15 May 1999 18:14:30 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Parameter pass to PERL
Message-Id: <ylemkh4xzd.fsf@windlord.stanford.edu>
armchair <armchair@my-dejanews.com> writes:
> You find out the number by assigning the array to a scalar which causes
> the number of entries to be assigned.
> my $num_arguments = @ARGV;
> or for a little more logical clarity to non-Perl programmers
> my $num_arguments = scalar(@ARGV);
> and you access the elements like a normal array:
> if ( $num_arguments > 0 )
You can abbreviate this a little if you want by saying:
if (@ARGV > 1) {
if you really want to check if there are more arguments than a given
number, or go to:
if (@ARGV) {
if you're just checking if there are any arguments.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: 15 May 1999 18:11:11 -0700
From: Russ Allbery <rra@stanford.edu>
Subject: Re: Perl "constructors"
Message-Id: <ylhfpd4y4w.fsf@windlord.stanford.edu>
armchair <armchair@my-dejanews.com> writes:
> Where are the core concepts of Perl stated?
They're currently scattered through the documentation; Perl is a very
large culture. I agree with your implication that it might be rather nice
to have a summary of a few of them, although one of the other things that
makes Perl like a culture is that not everyone is going to agree about all
of them. And that's okay too. :)
> Perhaps a majority are, and perhaps a majority of code that is written
> is never modified by anyone other than the author, but in the cases
> where it is, standardization and rules that allow compile time error
> catching are of great value.
And Perl has ways to do that, if you want it. use fields, for example.
I've written a lot of Perl code, and maintained a lot of Perl code written
by other people, and haven't found this to be a major problem. -w and use
strict generally catch it all.
Compile vs. run-time error catching isn't quite as important as I think
some programmers believe. It certainly is important in C, since the
compiler spits out a nice error message whereas the run-time code spits
out "Segmentation fault" and you then have to use a fairly clunky debugger
interface to figure out what went wrong and where. But in Perl, where
Perl itself spits out a fairly nice and informative error message that
includes the exact line where something went wrong, it's not as much of an
advantage.
The fact of the matter is that for any software project that has to be
robust, you need to develop a test suite that tests most of your code
paths anyway to find the logic bugs that a compiler can't find. In the
process of running that test suite, under -w of course, Perl will find
pretty much everything that a compiler for a strict language will find,
along with a bunch of other stuff that it *wouldn't*.
> And surely a proponent of Perl, a language that you have just described
> as libertarian, so libertarian constructors can be of any name, would
> not actually be complaining about a simple user-defined variable
> name????
Like I mentioned elsewhere, just because *Perl* doesn't care doesn't mean
it's a bad idea. Programming is about making other programmers happy as
well as about making the tools happy and the program work.
> Huh? C++ has a required syntax for accessing variables in data
> structures that leaves no abiguity. struct mystruct { int b; }
> mystruct zzz;
> zzz.b = 10;
For structs. Now what about private data members of an object, accessed
from inside a method of that object? In the middle of a long method, it's
often not at all obvious whether one is dealing with a variable local to
that method or a variable that's stored in the object itself.
Perl makes this explicit.
> I guess what bothers me is that in C++ I can construct object member
> data your Perl way, or my desired Perl way. C++ is so libertarian about
> object construction that it allows us to both do it different ways. It
> doesn't enforce an object data member style on either one of us the way
> Perl does.
Er... I think you're not understanding the flexibility of Perl. You're
thinking of the blessed reference as a pointer to the object's data.
That's not a good way to think of it, in my opinion. Instead, think of
that reference as equivalent to the "this" pointer in C++.
C++ basically requires all your objects to be hashes, in the sense that
their data elements are all named values of some sort and you access them
by name. That's the normal way of doing it in Perl as well, but Perl also
allows blessed arrays or even blessed file handles and other odd things,
for those times when you want to do something very different.
--
#!/usr/bin/perl -- Russ Allbery, Just Another Perl Hacker
$^=q;@!>~|{>krw>yn{u<$$<[~||<Juukn{=,<S~|}<Jwx}qn{<Yn{u<Qjltn{ > 0gFzD gD,
00Fz, 0,,( 0hF 0g)F/=, 0> "L$/GEIFewe{,$/ 0C$~> "@=,m,|,(e 0.), 01,pnn,y{
rw} >;,$0=q,$,,($_=$^)=~y,$/ C-~><@=\n\r,-~$:-u/ #y,d,s,(\$.),$1,gee,print
------------------------------
Date: 16 May 1999 01:17:21 GMT
From: zenin@bawdycaste.org
Subject: Re: Perl "constructors"
Message-Id: <926817583.5320@thrush.omix.com>
armchair@my-dejanews.com wrote:
: tchrist@mox.perl.com (Tom Christiansen) wrote:
>snip<
: You strip out to much of the previous post.
Good. Never quote that which is not pertinent, especially
in USENET.
: Try editing less, and answering more.
Try reading more, and BS less.
:> No, that's wrong. Don't test for 0.
:>
:> if ($value) suffices for truth, and unless ($value) for falsehood. This
:> == 0 business is brain-damange.
:
: Why shackle someone's code style to your biases. Try and be more
: libertarian, like Perl and Larry Wall
In Perl TIMTOWTDI, yes. That does not however, preclude particular
ways from simply being wrong.
>snip<
: Is raising and exception supposed to be the die function?
Yes, and before you ask we spell "try" as "eval", and "catch" as
"if".
>snip<
:> :Very expensive, not intuitive.
:>
:> Liar. Twice.
:
: As it turns out, only once. Someone has proclaimed it not expensive, but
: no sane man, woman or child would ever call it intuitive.
In the context of Perl, it is completely intuitive. Perl is
optimized for the user, not the student. If you want to learn how
to program go play with Pascal or BASIC.
--
-Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
Pizza......for the body.
Sushi......for the soul.
-- User Friendly
------------------------------
Date: 16 May 1999 01:37:43 GMT
From: zenin@bawdycaste.org
Subject: Re: Perl "constructors"
Message-Id: <926818805.230749@thrush.omix.com>
armchair@my-dejanews.com wrote:
>snip<
: Where are the core concepts of Perl stated?
In /usr/local/src/perl5.005_03/*.[ch]
>snip<
: Perhaps a majority are, and perhaps a majority of code that is written is
: never modified by anyone other than the author, but in the cases where it
: is, standardization and rules that allow compile time error catching are
: of great value.
See the strict and fields man pages.
>snip<
: Wrong. I am using an array because I have created an object that needs
: to hold multiple scalars, one of which is total_attendees.
Then use a hash.
: I have no choice but to $rSelf->[10].
And a hash failed you, how exactly?
: You should have attacked me for not using a hash to store the data where I
: could have written $rSelf->{"total_attendees}.
He did.
: And surely a proponent of Perl, a language that you have just described as
: libertarian, so libertarian constructors can be of any name, would not
: actually be complaining about a simple user-defined variable name????
Just because particular code is allowed doesn't preclude it from
being trash.
>snip<
: Huh? C++ has a required syntax for accessing variables in data
: structures that leaves no abiguity. struct mystruct { int b; }
: mystruct zzz;
: zzz.b = 10;
my $zzz = { b => 0 };
$zzz{b} = 10;
--
-Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
Pizza......for the body.
Sushi......for the soul.
-- User Friendly
------------------------------
Date: 16 May 1999 01:44:14 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl "constructors"
Message-Id: <slrn7js8nd.d4q.sholden@pgrad.cs.usyd.edu.au>
On Sat, 15 May 1999 09:40:32 GMT, armchair@my-dejanews.com wrote:
>In article <ylzp366dm2.fsf@windlord.stanford.edu>,
> Russ Allbery <rra@stanford.edu> wrote:
>> armchair <armchair@my-dejanews.com> writes:
>>
>> > I can speak to this: connect() and prepare() should be member
>functions
>> > and not constructors as a member function can return a status code
>of
>> > success or various error codes. A constructor cannot.
>>
>> Constructors certainly can return various error codes, as well as
>success
>> or failure.
>
>And what does your code look like?
>
>#constructor...
>if ( success )
>{ return bless a; } else { return 0; }
No since return 0 is not how you return false in perl. But since you can't
be bothered looking up simple things you just make an incorrect statement
and then use it to show perl isn't how you like.
>
>#caller
>
>my $reference = myclass->new();
>if ( $reference == 0 )
>{
> print "constructor failed\n";
>}
>
>Correct?
No more likely the simple :
my $reference = myclass->new() || die "constructor failed";
Perl does not restruct what a sub returns. It is not a strongly typed
language. You are placing stupid restrictions on perl that don't exist.
If you want you could return anything you feel like on failure. If you
want to return the string "I failed" then you can. If you want to return
the error code 42 then you can. If you want to return a reference to an
array of arrays of hashes to indicate error then you can.
>>
>> > In any event, you can't get around the fact that constructors return
>a
>> > blessed reference. It's nice for functions that can fail, to return
>> > error codes. Or perhaps you are printing error messages and exiting
>your
>> > program when your constructors fail??
>>
>> Have you heard of exceptions?
>
>In C++ and Java, but not in Perl. Does it have them, and if so which
>perl HTML page section are they documented in?
It's documented in perlfaq8 which you should have read before posting, but
you are obviously too stupid.
It's also documented in perlfunc. It's mentioned in perltoc (how could you
not read that one?), and in perldelta, and perlfaq7, and I couldn't be
bothered checking elsewhere...
>> > I don't think it is too much to ask for a function, a complement to
>> > "exists" if you will, that tells how many items are in a hash.
>>
>> What, like $count = keys %hash?
>
>Very expensive, not intuitive. What is the hash has 2000 items. Create
>a matching array just to get a count of them?
Who ever said that an array will be created. Did you bother to read the
documentation of keys. Obviously not. You have no understanding of perl
so stop pretending you know how it works.
>
>>
>> > How about: %hash = ();
>>
>> > if (entries($hash) > 0 )
>>
>> Ew.
>>
>> What about
>>
>> if (%hash) {
>> # ...
>> }
>>
>> Much, much simpler, and then you don't even have to worry about this
>> problem.
>
>Asumming I just want to test emptiness. Thanks, just tried it, and it
>worked, but I do have one comment - non-intuitive, non-lookupable,
>obtuse.
It's intuitive to anyone who has bothered learning a little perl. It's
consistent with what happens in a scalar context. It's lookupable since
it is documented. perldata would be the obvious place to look. It's not
obtuse since it is the way perl is.
Now go away and use python.
--
Sam
There's no such thing as a simple cache bug.
--Rob Pike
------------------------------
Date: 16 May 1999 01:46:19 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl "constructors"
Message-Id: <slrn7js8rb.d4q.sholden@pgrad.cs.usyd.edu.au>
On Sat, 15 May 1999 12:42:58 GMT, armchair@my-dejanews.com wrote:
>
>Because the book I have - "Perl From the Ground Up" in it's built-in
>function reference says that keys "returns all the keys for the Hash
>named". It does not mention "scalar context" as some right honorable
>fellow was nice enough to point out that the perlfunc does inside of
>parenthese after stating the above regarding returning all the keys.
So the book is wrong. Throw it out and buy 'Programming Python'.
--
Sam
Many modern computer languages aspire to be minimalistic. They either
succeed in being minimalistic, in which case they're relatively useless,
or they don't succeed in being truly minimalistic, in which case you can
actually solve real problems with them. --Larry Wall
------------------------------
Date: 16 May 1999 01:47:11 GMT
From: zenin@bawdycaste.org
Subject: Re: Perl "constructors"
Message-Id: <926819373.57195@thrush.omix.com>
armchair@my-dejanews.com wrote:
>snip<
: Hmmm, lacking knowledge, or showing poor judgement regarding program
: speed. That's an easy one - I don't know Perl. How does access of hashes
: compare to arrays performance-wise?? And does the size of the hash key
: string affect it?
Test it yourself. See `perldoc Benchmark'
: Actualy, I haven't left C++. Would I be correct in surmising that the
: slogan of this newsgroup is not "everybody join in".
No, but we do have a minimum brain cell count.
>snip<
: Well, hashes are variable in size and you appear to feel they involve no
: meaningful performance degradation (but you also appear to hold bias) but
: one does need to depend on the fact that variables have been added, or use
: exists() which is not necessary with structs.
It's not necessary in Perl either.
: And as we and others have discussed, it does need an entries() function
: for clarity and performance.
Maybe my news feed is broken (not likely), but I have yet to see a
single reply that agrees with you on this. You'll use keys() and
like it.
: And structs, like C++ differing variable types allow the catching of
: syntax errors at compile time. And that is not a trivial benefit.
See fields.pm. You also don't seem to know what the word "syntax"
means.
>snip<
: The "one reference per object" is only a minor complaint.
Who says you can only have one reference per object?
my $self = {};
$self->{ref1} = { foo => 10, bar => 20 };
$self->{ref2} = { this => 10, that => 20 };
: My major complaint with the Perl language (and I felt this way about Basic
: and dBase III and Rexx and other loosely typed interpreted languages as
: well - so don't take it so personally - is that one variable can at one
: moment hold a number, and another moment hold a string (not to mention
: references).
That's a feature.
: And I am trying to learn Perl, but have run into some mixed opinions on
: whether or not I am doing the right thing...
You aren't doing the right thing, but learning Perl is never the
wrong thing to do.
--
-Zenin (zenin@archive.rhps.org) Caffeine...for the mind.
Pizza......for the body.
Sushi......for the soul.
-- User Friendly
------------------------------
Date: 16 May 1999 01:59:51 GMT
From: sholden@pgrad.cs.usyd.edu.au (Sam Holden)
Subject: Re: Perl "constructors"
Message-Id: <slrn7js9kn.d4q.sholden@pgrad.cs.usyd.edu.au>
On Sat, 15 May 1999 10:23:35 GMT, armchair@my-dejanews.com wrote:
>In article <slrn7jptpa.871.sholden@pgrad.cs.usyd.edu.au>,
> sholden@cs.usyd.edu.au wrote:
>> On Sat, 15 May 1999 03:31:11 GMT, armchair@my-dejanews.com wrote:
>> >In article <7hh9rs$58m$1@nnrp1.deja.com>,
>> > John Porter <jdporter@min.net> wrote:
>> >> In article <7hh079$ueo$1@nnrp1.deja.com>,
>> >> armchair@my-dejanews.com wrote:
>>
>> I'd use $rSelf->{total_attendees}. If you would actually use a
>reference to
>> an array like that then you either don't know perl, or you are an
>> optimisation idiot...
>
>Hmmm, lacking knowledge, or showing poor judgement regarding program
>speed. That's an easy one - I don't know Perl. How does access of hashes
>compare to arrays performance-wise?? And does the size of the hash key
>string affect it?
>
>>
>> In fact since I'm using a hash not a stupid C++ variable name, I could
>> get rid of the damn _ if I felt like it and use :
>>
>> $rSelf->{'total attendees'}
>>
>> Maybe you should learn some perl or go back to C++.
>
>Actualy, I haven't left C++. Would I be correct in surmising that the
>slogan of this newsgroup is not "everybody join in".
Of course it's not. It's about perl, so first one should learn some perl
so they actually have a vague clue what is going on...
>
>>
>> >I have not run into any brick wall, but having worked
>> >with C++, I can assure you that having only one reference in an
>object
>> >point to it's data (none of which is a struct or true
>multi-dimensional
>> >array) does not lead to a great convenience in programming.
>>
>> A hash is what perl uses for a struct, it does everything a struct
>does and
>> then some...
>
>Well, hashes are variable in size and you appear to feel they involve no
>meaningful performance degradation (but you also appear to hold bias)
>but one does need to depend on the fact that variables have been added,
>or use exists() which is not necessary with structs. And as we and
>others have discussed, it does need an entries() function for clarity
>and performance. And structs, like C++ differing variable types allow
>the catching of syntax errors at compile time. And that is not a trivial
>benefit.
The performance degredation of a hash compared to a struct is
negligible compared with the performance degradation of using perl
over C.
On uses a hash _exactly_ the same way one uses a struct if that is what
one wants. The advantage is that when you create one instead of all your
values being random crap as in C, they are all set to undef in perl.
If the hash is being used as a struct, then you have no need to check it's
size, you know what's in it. It contains the fields you say it does.
Perl allows the catching of such errors at run time which is just as good,
since perl runtime errors are much clearer then 'Bus error - core dumped'.
>
>>
>> A multi-dimensional array would be $mda[4][3][2][1][0] = 'bill'; How
>> is that not a 'true multi-dimensional' array?
>>
>> Maybe you should learn some perl before start to complain about what
>> it can't do...
>
>The "one reference per object" is only a minor complaint. My major
>complaint with the Perl language (and I felt this way about Basic and
>dBase III and Rexx and other loosely typed interpreted languages as well
>- so don't take it so personally - is that one variable can at one
>moment hold a number, and another moment hold a string (not to mention
>references).
>
>And I am trying to learn Perl, but have run into some mixed opinions on
>whether or not I am doing the right thing...
No your not. Don't use perl. You don't like loosely typed languages. Perl
is loosley typed. So use something that is strongly typed. Pretty obvious
really.
--
Sam
I explicitly give people the freedom not to use Perl, just as God gives
people the freedom to go to the devil if they so choose.
--Larry Wall
------------------------------
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 5677
**************************************
