[11002] in Perl-Users-Digest
Perl-Users Digest, Issue: 4602 Volume: 8
daemon@ATHENA.MIT.EDU (Perl-Users Digest)
Sat Jan 9 07:08:04 1999
Date: Sat, 9 Jan 99 04:00:18 -0800
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, 9 Jan 1999 Volume: 8 Number: 4602
Today's topics:
Re: "internal server error" (Bart Lateur)
Re: "internal server error" <webpages@email.com>
__FILE__, __LINE__ not set <design@raincloud-studios.com>
Re: best way to track time in a script for tuning? <dtbaker-@busprod.com>
c to perl webmaster@galilnet.co.il
c to perl <jimbo@internet-zahav.net>
Re: c to perl <expert@friko.onet.pl>
detecting a sentence.. <rahulk@iname.com>
Re: Gratuitous warnings when statting files with newlin rupert@no.spam.leeds.ac.uk
Re: If Larry Wall's listening out there.... <design@raincloud-studios.com>
Re: If Larry Wall's listening out there.... <design@raincloud-studios.com>
Re: If Larry Wall's listening out there.... <design@raincloud-studios.com>
Re: Need CGI database <design@raincloud-studios.com>
Re: Password Encryption <design@raincloud-studios.com>
Re: Perl Criticism (David Formosa (aka ? the Platypus))
Re: Perl Criticism (David Formosa (aka ? the Platypus))
Re: Perl Criticism (Bart Lateur)
Re: Perl Criticism (Bart Lateur)
Re: Perl uses in NT <mctaylor@primenet.com>
Re: Permission probs <design@raincloud-studios.com>
Re: possible bug in perl format with ~~ <jlewis@gnv.fdt.net>
Special: Digest Administrivia (Last modified: 12 Dec 98 (Perl-Users-Digest Admin)
----------------------------------------------------------------------
Date: Sat, 09 Jan 1999 09:02:41 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: "internal server error"
Message-Id: <369b177c.4471609@news.skynet.be>
Bart Lateur wrote:
>Probably a syntax error. Try adding this to your script. At least it'll
>tell you some more.
I think you might need a __DIE__ handler as well, so that at least you
get a "text/plain" header if the script simply dies without warning
first.
my $headerPrinted; # to avoid a warning
BEGIN {
$| = 1;
$SIG{__WARN__} = sub {
$headerPrinted ||= do { print "Content/type: text/plain\n\n"};
print @_;
};
open STDERR,'&STDOUT';
$SIG{__DIE__} = sub { &{$SIG{__WARN__}}; print "Died.";
exit(1) };
}
Now, unless your script doesn't do anything, your should ALWAYS get a
response, even if just Perl's error messages. The script dying without
outputting anything to STDOUT is what would give a "internal server
error".
Bart.
------------------------------
Date: Sat, 09 Jan 1999 12:32:10 +0100
From: Eirik Johansen <webpages@email.com>
Subject: Re: "internal server error"
Message-Id: <36973E3A.882879A2@email.com>
The suggestion from Eugene Sotirescu worked. Thank you so much! Also thank to
James Ludlow who gave me a lot of advice. But I also have a simple(?) question. Is
it possible to have to different operating systems on a PC (win95 AND Linux). And
isn't Linux really hard to use?
Regards
Eirik !
Eugene Sotirescu wrote:
> Eirik,
>
> change
> $FORM{$recipient}
> to
> $FORM{'recipient'}
> (you're not setting a $recipient variable after all).
>
> Also the s/%40/@/ is not really necessary.
>
> Eirik Johansen wrote:
>
> > Who wants to learn Perl after feedback like this???
> >
> > When one gets a lot of replies one should probably thank for them, but in
> > this case, there are few replies to thank for. It's okay to give
> > constructive critisism, but very little of this critisism is constructive. I
> >
> > agree that my first posting should'be been clearer, but why don't someone
> > just say that in a nice way instead of making such a big deal out of how
> > stupid I am.
> >
> > Before I repost my question, I would like to say something to some of the
> > people replying to my message:
> >
> > Abigail: What's your problem? Did you actually read my posting? The first
> > line goes something like this: "I've just started learning Perl..." Did it
> > ever occur to you that I either know what "-w" "use strict" or modules are
> > nor do I know how to use them. I'm supposing that modules are some pre-made
> > scripts since you say they are "made by people with a clue".(It's probably
> > not!) Well, you obviously didn't read the rest of the the first sentence,
> > cause it goes something like this: "...and I recently modified a CGI-script"
> >
> > And did it ever occour to you that I might want to "have a clue" myself
> > someday? And the only way to leraning this, is by doing it myself !
> > I'm eager to learn CGI-scripting - so what if I "don't have the appropriate
> > environment to test my work with."? I want to learn it just the same, and I
> > will too, you'll see. And that I didn't give you an error message. The only
> > error message I can give is in the subject line, you see THAT'S THE PROBLEM.
> >
> > If I had an error msg, I would've worked out the problem myself.
> >
> > There - that's some constructive critisism for you. Try using it sometime,
> > instead of telling people to crawl under a rock (are you sure that your
> > daddy allows you to play with the computer?)
> >
> > Bart Lateur:
> > Thanks for actually caring about helping a novice. The other posters have
> > got a lot to learn from you !
> >
> > Okay, let's rewind this tape and start from the top.........<<............
> >
> > Hi!
> >
> > I have a problem with a CGI script which I altered. The script is a usual
> > mil-the-form
> > script which sends tha data of the form to someones (my) E-mail adress. I
> > altered the script a little so that it would read the recipient and the
> > subject-line from a two hidden-fields in the the form, and added the
> > following line:
> >
> > $value =~ s/%40/@/;
> >
> > and I also changed the output HTML-code to suit my needs. But when I hit the
> >
> > submit-button I get a page in the web-browser with the following msg:
> >
> > Internal Server Error
> >
> > The server encountered an internal error or misconfiguration and was unable
> > to complete your request.
> >
> > Please contact the server administrator, webmaster@bardblikk.no and inform
> > them of the time the error occurred, and anything
> > you might have done that may have caused the error.
> >
> > The form can be found at http://home.sol.no/~webpages/mailform.htm and a
> > copy of the script in *.txt version can be located at
> > http://home.sol.no/~webpages/mailform.txt
> >
> > I would appriciate any help you can give my !
> >
> > Regards
> >
> > Eirik Johansen
> > A NEWBIE IN CGI AND PERL!!!
> >
> > Eirik Johansen wrote:
> >
> > > Hi !
> > >
> > > I've just started learning Perl and I recently modified a CGI-skripy,
> > > but now it won't work and I don't know why. Would someone be as kind as
> > > to rund it un their Unix shell (I don't have Unix) and tell me which
> > > line makes the error.
> > >
> > > Thanks so very much !
> > >
> > > Regards
> > >
> > > Eirik Johansen
> > >
> > > #!/usr/bin/perl
> > >
> > > # This script will take information from a form
> > > # and place it in a mail to the desired recipent
> > >
> > > print "Content-type:text/html\n\n";
> > >
> > > read(STDIN, $buffer, $ENV{'CONTENT_LENGTH'});
> > > @pairs = split(/&/, $buffer);
> > > foreach $pair (@pairs) {
> > > ($name, $value) = split(/=/, $pair);
> > > $value =~ tr/+/ /;
> > > $value =~ tr/%40/@/;
> > > $value =~ s/%([a-fA-F0-9][a-fA-F0-9])/pack("C", hex($1))/eg;
> > > $FORM{$name} = $value;
> > > }
> > >
> > > $mailprog = '/usr/sbin/sendmail';
> > >
> > > # this opens an output stream and pipes it directly to the sendmail
> > > # program. If sendmail can't be found, abort nicely by calling the
> > > # dienice subroutine (see below)
> > >
> > > open (MAIL, "|$mailprog -t") or &dienice("Can't access $mailprog!\n");
> > >
> > > # here we're printing out the header info for the mail message. You must
> > >
> > > # specify who it's to, or it won't be delivered:
> > >
> > > print MAIL "To: $FORM{$recipient}\n";
> > >
> > > # In case the owner of the form has any questions, I'll set the
> > > # reply-adress as my own
> > >
> > > $reply = 'webpages@email.com';
> > >
> > > print MAIL "Reply-to: $reply\n";
> > >
> > > # print out a subject line so you know it's from your form cgi.
> > > # The two \n\n's end the header section of the message. Anything
> > > # you print after this point will be part of the body of the mail.
> > >
> > > print MAIL "Subject: $FORM{$subject}\n\n";
> > >
> > > # here you're just printing out all the variables and values, just like
> > > # before in the previous script, only the output is to the mail message
> > > # rather than the followup HTML page.
> > >
> > > foreach $key (keys(%FORM)) {
> > > print MAIL "$key = $FORM{$key}\n";
> > > }
> > >
> > > # when you finish writing to the mail message, be sure to close the
> > > # input stream so it actually gets mailed.
> > >
> > > close(MAIL);
> > >
> > > # now print something to the HTML page, usually thanking the person
> > > # for filling out the form, and giving them a link back to your homepage
> > >
> > > print <<EndHTML;
> > > <h2>Thank You</h2>
> > > Thank you for writing. Your mail has been delivered.<p>
> > > Do you want a form like this one? Then visit <a
> > > href="http://webpages.findhere.com" target="_top">The Webpage of
> > > Webpages</a>
> > > </body></html>
> > > EndHTML
> > > ;
> > >
> > > sub dienice {
> > > ($errmsg) = @_;
> > > print "<h2>Error</h2>\n";
> > > print "$errmsg<p>\n";
> > > print "</body></html>\n";
> > > exit;
> > > }
------------------------------
Date: 9 Jan 1999 06:59:28 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: __FILE__, __LINE__ not set
Message-Id: <776uog$jaj@bgtnsc03.worldnet.att.net>
Is there any common reason that __FILE__ and __LINE__ would not follow
into &CgiDie?
I have a few library files I'm trying to debug, but since the __FILE__
does not show up, I really can't figure out which one it is complaining
about. I am using the $! variable, but the error given is vague and
could apply to any of the 4-8 that load depending on a given situation.
CT
------------------------------
Date: Fri, 08 Jan 1999 23:14:07 -0600
From: Dan Baker <dtbaker-@busprod.com>
Subject: Re: best way to track time in a script for tuning?
Message-Id: <3696E59F.C0F9FE88@busprod.com>
brian d foy wrote:
>
> In article <369668E2.59B9992B@busprod.com>, Dan Baker <dtbaker-@busprod.com> posted:
>
> > I'm looking for tips and hints on good methods to do some final tuning
> > on scripts... I have some that are running, but take a little longer
> > than I expect. Are there good ways to throw in some prints that will
> > show the time in msec or something like that so I can narrow down what
> > areas need tuning?
>
> have you tried the Devel::DProf or ::SmallProf modules?
-----------------
nope, not yet.... didn't know about'em until now! I haven't gone looking
yet, but I'm assuming that if they aren't in the standard release they
are on CPAN? Any tips on usage? limitations, etc?
D
------------------------------
Date: Sat, 09 Jan 1999 06:45:50 GMT
From: webmaster@galilnet.co.il
Subject: c to perl
Message-Id: <776tuu$mgc$1@nnrp1.dejanews.com>
Is there a utility that converts c to perl?
Jim
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
------------------------------
Date: Sat, 09 Jan 1999 09:27:31 +0200
From: Jim Catz <jimbo@internet-zahav.net>
Subject: c to perl
Message-Id: <369704E3.522A@internet-zahav.net>
Is there a utility that will do this?
Jim
------------------------------
Date: Sat, 09 Jan 1999 09:11:31 GMT
From: Expert <expert@friko.onet.pl>
Subject: Re: c to perl
Message-Id: <36970DE3.C45@friko.onet.pl>
webmaster@galilnet.co.il wrote:
>
> Is there a utility that converts c to perl?
> Jim
>
I am looking for a utility that converts perl to c .
Jack
------------------------------
Date: Sat, 09 Jan 1999 00:45:34 -0600
From: Rahul K <rahulk@iname.com>
Subject: detecting a sentence..
Message-Id: <3696FB0E.5976CC6E@iname.com>
Hi,
Sorry if this has been brought up before. How do I detect the end of a
sentence?
Detecting the end of this sentence is easy:
The quick brown fox jumped over the lazy dog. The other quick brown fox
was ill.
but how do I detect the end of this sentence:
The quick brown fox (Netscape Inc.) jumped over the lazy dog. The other
quick brown fox was ill.
or this:
For eg. the quick brown fox jumped over the lazy dog. The other quick
brown fox was ill.
Thanks in advance,
-rahul
------------------------------
Date: Sat, 9 Jan 1999 11:35:11 +0000 (GMT)
From: rupert@no.spam.leeds.ac.uk
Subject: Re: Gratuitous warnings when statting files with newlines
Message-Id: <3697AEF5.CAF@no.spam>
[ SNIP ]
>$SIG{__WARN__} = sub
> { ($_[0] =~ /^Unsuccessful .* on filename containing newline/s)
> || warn $_[0]; };
>
> However, grepping through textual error messages seems enormously
> kludgy. I wish there were a way to say something like
> $WARNING{FILENAME_NEWLINE} = 0;
This is a most interesting thread. I get this warning frequently
because many directories on a Mac contain a file with a name like
"Icon\r", which is a genuine newline at the end of a file.
In may cases this is whilst doing, say, a -d on each of the results
of a readdir(). (So it was not obvious to me that it only occurred on
failling stat calls).
Whilst the suggestions made so far have been good ones, and we could
add to them the fact that interpolated newlines are more likely to
be genuine that trailling ones. I would like to see an extension
to the stat system of
-h # file is hidden
-sys # file is a system file
on many occasions one wishes to filter out from operations files
which are hidden from the user, or have no specific meaning to him
or her. On unix, filtering out hidden files is trivial (they look like
directories but aren't), but a call may be needed on other systems
such as my preferred one.
In general though, the warning is a good one because it is a reasonable
sanity check: files containg newlines are difficult to present to the
user, and more difficult for him or her to use, and therefore evidence
that something could be wrong.
Ben.
------------------------------
Date: 9 Jan 1999 09:45:52 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: Re: If Larry Wall's listening out there....
Message-Id: <7778gg$ftb@bgtnsc02.worldnet.att.net>
>Those of us working in a Windows environment generally will use notepad
as a
>text editor. Simple-mindedly, notepad does *not* display line numbers.
(it
>also doesn't do brace matching, but this I can live with)
<chainsaw to rest>
Notepad is like painting on Toilet Paper. Nothing but a mess. If you
want to be unbelievably cheap, there is a real easy fix that alot of
folks overlook...
Make a shortcut to edit.com (C:\WINDOWS\COMMAND\EDIT.COM) then place it
in your SendTo folder. From then on, you can open any text based file by
doing the following....
right mouse click over
select sendto->MS-DOS Editor
You can have multiple screens open, and the BONUS you get with this
freebie (not mentioning lines numbers) fix is being able to split the
window in 2 so you can view two seperate areas of code in one file at
the same time. (A real headache when you are in one area and want to
look at some other sub or variable.) You also overcome the memory limit
(52,000 ?!?!? bytes) notepad has.
Buy or download another editor. Anyone who ever bought Visual Basic made
their own version of Notepad. www.winfiles.com and www.zdnet.com are
good resources for some of the more 'reviewed' software. Or if you know
windows programming and design your own darn editor. That's what I did.
I've got my own little database libraries of code with hotkeys, etc. A
real time saver.
CT
------------------------------
Date: 9 Jan 1999 09:58:46 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: Re: If Larry Wall's listening out there....
Message-Id: <77798m$i43@bgtnsc02.worldnet.att.net>
>>4. Lack of structures (aka VB types) and enums - at least, I can't
find such
>>things. Sure, hashes are very nice, but they're not really the same
thing.
>
> Sure they are. Hashes of hashes and lists of lists and lists
>of hashs provide you with all the structural richness you could ever
>want.
The day I was told I could put subs in a hash, I almost went insane from
glee. I had to restrain myself from trying to put a whole app in one. :)
CT
------------------------------
Date: 9 Jan 1999 10:08:49 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: Re: If Larry Wall's listening out there....
Message-Id: <7779rh$jsl@bgtnsc02.worldnet.att.net>
>Oh you've got it all wrong. The newest technology is VPN. Basically
>you tunnel your Morse-encoded IP through smoke signals. Your
building's
>ventillation system takes care of propogation. No messy wires to run.
>To connect to the Internet, simply cut a hole in the roof.
Hmmm....lessee... bigger hole, more bandwidth! :)
(Waking up wife with the chainsaw)
CT
------------------------------
Date: 9 Jan 1999 07:01:38 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: Re: Need CGI database
Message-Id: <776usi$k0k@bgtnsc03.worldnet.att.net>
>Depends how big this database is going to be. For smaller databases you
can
>get good results by tieing a hash to a DBM file. For something larger
you
>could look at something like MySQL.
>
>hth,
>
>Dave...
Could you define 'large' in sort sort of relative sense? I've often
wondered just what constitutes moving up from Flatfiles or DBM's to
something a bit more powerful.
CT
------------------------------
Date: 9 Jan 1999 10:32:26 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: Re: Password Encryption
Message-Id: <777b7q$njm@bgtnsc02.worldnet.att.net>
>Given enough time (years/centuries/millenia),
>anything can be decrypted.
&explain('David Hasselhoff');
Don't worry... you have millenia. :)
------------------------------
Date: 9 Jan 1999 07:58:18 GMT
From: dformosa@zeta.org.au (David Formosa (aka ? the Platypus))
Subject: Re: Perl Criticism
Message-Id: <slrn79e30o.sgo.dformosa@godzilla.zeta.org.au>
In article <775olp$m66$1@nnrp1.dejanews.com>, topmind@technologist.com wrote:
>.
>
>Reply to Tom Christiansen's 1/8 message:
>
>>> I'm not saying they're the same languages, but that they share with perl
>a generality that is not to be found in these actor-puppet languages
>such as I have demonstrated above. <<
>
>Where are you getting *your* definition of "scripting" from?
We might ask you the same question.
[...]
>>> Pardon me, but your unfounded accusations of `poor research' on the
>part of these languages' authors is unprofessional in the extreme.
>Can you substantiate your claims? Please list languages, authors,
>and your incontrovertible evidence that these authors engaged in
>`poor research'. Don't forget haskell and dylan. <<
>
>Since I have no Poor-O-Meter (either do you), it is only an opinion.
>I have never seen language builders publish in the public domain
>a list of reasons, trade-offs, considerations, etc. of why they
>picked what they did for the final version.
You have ever read the workings of the verious design comminties?
You have ever read the works of Wirth ect? A starting place would be
"Concepts of Programming Languaeges" by Robert W. Sebesta then read
all the books in its Bibliography.
[...]
> Thus, bad ideas are
>taken from other's bad ideas. (Note that what programmers like
>is not necessarily the same as what managers like
Programers should be the ones who are responable for languge choose
ect. Mangers are not progrmers they don't program there not experened
in what it is to program, they have no quilifications to judge what is
or is not a good langage.
[...]
>>> First, you allege that the authors of all these myriad languages ignored
>the past, and then without even taking a breath, you say that they did
>the very opposite, mindlessly copying existing art. Which one is it?<<
>
>They focus too narrowly on a few specimens. They make insufficent
>attempts to step back and look at the forest before disecting trees.
Ok, prove this stament. In the case of perl it has borrowed what the
authour considered good idears form a great number of langues.
>>> Ah, you were there, then? <<
>
>No, but I am not being selfish by hiding away the decision
>process so that the next language maker has to start from
>scratch and repeat the same mistakes.
You have on the other hand not seemed to have read even an elermentry
book on languge therory so you haven't been able to gain the benifit
of these people. There are plenty of papers and books on the subject
of languge desine, the fact that you can't find any of them is not the
fault of these languge designers.
[...]
>>>'Only one command line'? What ever does thatmean? <<
>
>Unix tends to use what I call "command piping" where the
>results of operation A get fed into operation B, and
>B's results go to C, etc.
The whole of computer science depends in some way or anouther with the
results of one stament effecting enoguther one. Unix simply exposed
this power to the command line.
>>> Subroutines in Perl most certainly do *NOT* `inherit the scope' of
>their caller. <<
>
>
>I just ran this example:
>
>$a = 5;
>print "before " . $a . "\n";
>mysub();
>print "after " . $a;
>
>sub mysub {
> $a = 2;
> mysub2();
>}
>
>sub mysub2 {
> $a = 99;
>}
>
>An here is the output:
>
>before 5
>after 99
>
>Where did the 99 come from if each sub did not inherit the variable
>scope of it's parent?
It just happend to coinedently happened to share a commen scope of the
package main. If they where in diffrent scopes then they would no
such effect,
$a = 5;
print "before " . $a . "\n";
a::mysub();
print "after " . $a;
package a;
sub mysub {
$a = 2;
b::mysub2();
}
package b;
sub mysub2 {
$a = 99;
}
If subs inferet the scope from there callers the result would be 99
lets see what heppens.
before 5
after 5
[...]
>>> Yet more factual errors. When will they ever end? @_ is not
>an operator. It is an array. <<
>
>One can also look at it as an operator that returns
>or feeds to an array.
You could call any array an operator then. Its not a usefull def of
an array.
> The distinction is probably trivial in Perl.
>Even the Camel Book resorts to calling stuff "thingies"
>because they have a hard time classifying Perl parts themselves.
They call them thingies because "referant" is to hard to say.
[...]
>>> More factual errors. You really have no idea how Perl really works,
>do you? Perl is perfectly happy having multiple values for a given key,
>or if you would, non-unique keys. <<
>
>Being do-able and natural are two different things.
I do it quite alot in meny of my programs its quite natural to do.
[...]
>>> And automatic persistence through DBM files has been with us since perl3. <<
>
>I believe DBM is an *add-on* to Perl, not built into the language.
You can beleaave what you wish but it doesn't make them truthfull.
>My docs show DBM to not be fully relational anyhow.
If you wish relational access in perl you can make use of the
extreemly popular RDBM intterfaces.
>>> What are you talking about? Perl doesn't work like that at all. <<
>
>Does too!
>Let me reword it:
>
>somefunc(x) // result goes into $_
>another_op() // reads from $_
The use of global vars in any lang are not a good thing. But this
isn't something unique to perl.
[...]
>Until you can find a better collection of freely available
>lists and evaluation of langauge implimentation options,
>you have very little room to criticize me.
The perl5 archives would be a good place.
--
Please excuse my spelling as I suffer from agraphia. See
http://www.zeta.org.au/~dformosa/Spelling.html to find out more.
How to win arguments on usenet http://www.zeta.org.au/~dformosa/usenet.html
------------------------------
Date: 9 Jan 1999 08:10:34 GMT
From: dformosa@zeta.org.au (David Formosa (aka ? the Platypus))
Subject: Re: Perl Criticism
Message-Id: <slrn79e3nq.sgo.dformosa@godzilla.zeta.org.au>
In article <775phs$n4b$1@nnrp1.dejanews.com>, topmind@technologist.com wrote:
>In article <slrn79addn.mcd.dformosa@godzilla.zeta.org.au>,
> dformosa@zeta.org.au (David Formosa (aka ? the Platypus)) wrote:
[...]
>> Ok how do you diffrentuate a scripting languge from a nonscriptiong langage?
[...]
>There are no clear boundries, but most agree that the distinctions
>are useful for discussion and classification. Here is a quick rough
>attempted list of scripting characteristics:
>
>1. Partially or fully interpreted.
>
>2. Loose typing
>
>3. Not meant for making mass-distribution apps, fast math,
>OS building, and life-support operations.
>
>4. Often have good string-processing capabilities.
Under your rules elisp is a scripting lang, and perl + PDL would not
be a scripting lang.
--
Please excuse my spelling as I suffer from agraphia. See
http://www.zeta.org.au/~dformosa/Spelling.html to find out more.
How to win arguments on usenet http://www.zeta.org.au/~dformosa/usenet.html
------------------------------
Date: Sat, 09 Jan 1999 09:02:39 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Perl Criticism
Message-Id: <369a13b4.3503775@news.skynet.be>
topmind@technologist.com wrote:
>In another message I challenged someone to come up with power-Perl
>code that MUST BE cryptic in order to be powerful.
How is this (very basic example)?
@sorted = sort { $a <=> $b } @ary;
Bart.
------------------------------
Date: Sat, 09 Jan 1999 10:24:45 GMT
From: bart.lateur@skynet.be (Bart Lateur)
Subject: Re: Perl Criticism
Message-Id: <369f2d41.10035950@news.skynet.be>
topmind@technologist.com wrote:
>I have received a dozen language recommendations, but you are the 3rd person
>to recommend Python. Maybe the next time at the book store I look more.
There is a book out about Python, yes. But if they don't carry it, you
can just download Python, including dozens of sample codes, and try it
out for free.
I think that, apart from TCL, Python is the main competitor to Perl, for
their typical application areas.
>> Let the Perl people have their syntactic abusabilty. It is by design.
>> Really. Most seem to like it that way.
>
>Of course! It is job security. Only they can fix their own spehgetti,
>so they are called back with a pay hike.
For that, locking the source away would be simpler. But Perl people, in
particular the "leaders", want to give the client what he pays for: the
source. They want to be asked back because they're *good*, not because
they've hostaged him. Most clients hate feeling like a hostage, so they
really appreciate this. That's part of what the whole "free software"
thing is about.
Anyway.
It looks like orthogonality is mainly what you're after (= "apply the
same rules everywhere"). Python is designed to be far more orthogonal
than Perl.
But, it seems like some programmers may be far more productive by not
following a strictly orthogonal approach. Larry Wall himself said
something like "orthogonality is largely overrated". After all, matching
using a regexes is not quite the same as toggling a bit in a hardware
card, not even mentally. So why should it look the same?
Many people say "use the right tool for the right job". Perl tries to be
many tools in one. Each tool has it's own incompatible (with the rest)
syntax, because it looks like the best syntax for that job.
A final remark: don't try to make the designer change Perl because you
don't like it. You may have valid reasons for not liking it. Others feel
the same. That's why there have already been designed literally hunderds
of programming languages. Many are freely available. Check the "free
compilers" list, which is accessible through internet (I think on a
Swiss site; I think Yahoo has a link). It may be that your one true love
(programmerwise) is in there. After all, it's not because very many
people use Perl, that you should too.
Bart.
------------------------------
Date: Fri, 8 Jan 1999 23:51:27 -0800
From: "Mike Taylor" <mctaylor@primenet.com>
Subject: Re: Perl uses in NT
Message-Id: <7772oc$nde$1@nnrp02.primenet.com>
Thank you!
Alain Martineau wrote in message <369601F3.6AF1606D@francomedia.qc.ca>...
>I think he's asking why he should read it. How Perl would help his NT
>administration tasks. I wonder.
>
>I use Perl for CGIs on an NT web server, but could I use it for system
>administration as I can on Unix ? The Unix world is all administrable
>via the command line or open APIs. NT is all done through a maze of GUI
>screens without a command line equivalent. And I keep hearing that not
>all APIs required to administer are published by Microsoft. Can you for
>instance write a program to create/modify/delete users using public
>information ?
>
>Les wrote
>
>> Zenin wrote:
>>
>> > Isn't there a book, "Learning Perl on Win32 Systems"?
>>
>> Very good book. (As are all of Oreilly's that I've used.)
>>
>> http://www.oreilly.com/catalog/lperlwin/
>>
>> Les Driggers
>
------------------------------
Date: 9 Jan 1999 10:27:25 GMT
From: "Charles R. Thompson" <design@raincloud-studios.com>
Subject: Re: Permission probs
Message-Id: <777aud$mqm@bgtnsc02.worldnet.att.net>
<CT's first post here comes back to haunt him :) >
>I have a problem with permissions, the CGI scripts I've written will
only
>create a directory with-in a directory with chmod 0777 and will also
only
>create files with-in a directory with chmod 0777. It all works if
asked to
>create a directory or file within a DIR with chmod 0777, but not
otherwise.
Although not Perl related, I've been through this one lately. Depending
on your server configuration.... If it runs as 'group' then you can go
as low as 710 to execute a cgi Perl script. To read and write under that
directory, it will probably need to be 770. Again, this depends on your
server. You are going to have to experiment to understand exactly what
is going on there...
(as I well know from a previous post).. If you need to do 777, your
server is broke, and you are open to all kinds of security problems. My
tip to you would be to write 2 *incredibly small* scripts that
create/delete directories/ subs and files. script 1 writes , script 2
deletes what script 1 writes. Using FTP and your browser, you should...
set permissions for directory to 777
run first script, check via ftp that directory / file exists
run second script to delete, verify..
set permissions to 775, repeat, 771, etc, 770, 750, 710.
Keep drilling down until something doesn't work. Write down what you
notice, then you will know what permissions are *truly* correct for your
read/write scripts.
>Do any of you know if it is possible to do either of the following:
>1. let perl create a mapping file/dir, so that a directory will be
called
>from another location when asked for but appear as if it was in the
location
>asked for.
I'm not sure exactly what you are asking.
>2. Set a user or group within the script so that the dir doesnt have
to be
>777 but can be 775 or 755 as it knows it is user x or part of group
x?
Refer to the first question. I am assuming from your style in the post
that you are using a hosting service. Again... 777 isn't right. You need
to try my recommendation and read up on permissions. Most hosting
services disable chown (which sets ownerships) so you can't mess up
their server.
If you need further help on permissions, etc..
comp.infosystems.www.authoring.cgi or comp.infosystems.www.servers.unix
are where you need to post this question.
CT
------------------------------
Date: Sat, 9 Jan 1999 02:19:14 -0500
From: Jon Lewis <jlewis@gnv.fdt.net>
Subject: Re: possible bug in perl format with ~~
Message-Id: <Pine.LNX.4.05.9901090216120.24988-100000@yoda.fdt.net>
On Fri, 8 Jan 1999, Tad McClellan wrote:
> Jon Lewis (jlewis@gnv.fdt.net) wrote:
>
> : $sr_notes contains any \r\n's,
>
> : I'm using perl 5.004 on Linux.
>
>
> Why do you have Carriage Returns in your text files?
The perl script in question is processing an HTML form post, and using a
format to generate a nice looking formatted hard copy. Several textareas
have to be printed on the hard copy, and I don't know how long each will
be, or whether or not the user will enter line breaks (carriage returns)
within a textarea.
------------------------------------------------------------------
Jon Lewis <jlewis@fdt.net> | Unsolicited commercial e-mail will
Network Administrator | be proof-read for $199/message.
Florida Digital Turnpike |
______http://inorganic5.fdt.net/~jlewis/pgp for PGP public key____
------------------------------
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 4602
**************************************
