Starting Perl

[Randal L. Schwartz]

>>>>> "Chris" == McMahon, Chris <CMcMahon@loronix.com> writes:

Chris> You *are* the one who wrote "Learning Perl on Win32 Systems", yes?

I wrote the "Learning Perl" parts yes. Eric Olsen (I'm probably
mangling the spelling of his name) wrote the Win32 parts though. I
didn't even know the book was coming out until it showed up on
shelves. :-)

Luckily, with the modern Learning Perl book, there's no need for a
separate version. O'Reilly continues to sell it though, simply
because it's selling. :) We've come a long way from that first series
of books.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[Rob Dixon]

Randal L. Schwartz wrote:

>

> >>>>> "Rob" == Rob Dixon <rob@dixon.port995.com> writes:

>
> Rob> Perl programs conventionally go in *.pl files.
>
> No. Only on broken architectures that demand it (read: "windows").
> On Unix, Perl programs have no extension, any more than "cat" has an
> extension. Why should the user care what the implementation language is?

(sigh)

Yomna el-Tawil wrote:

>
> Thank you all for ur answeres...
> But I've got some problems,
> i'd like to say first that i'm using activePerl ,
> under windows.

Randal L. Schwartz wrote:

>
> If you name your Perl program "something.pl" on a Unix machine, I shall
> continue to look at you quizzically until either you or I leave the room. :)

Don't worry. I won't touch your Unix machine. (looking quizzically back)

> Rob> Perl modules are in *.pm.
>
> Yes, this is enforced by Perl.

Mm.

Rob

[Bob X]

"Randal L. Schwartz" <merlyn@stonehenge.com> wrote in message
news:8665hnrl3j.fsf@blue.stonehenge.com...

> >>>>> "Chris" == McMahon, Chris <CMcMahon@loronix.com> writes:

>
> Chris> You *are* the one who wrote "Learning Perl on Win32 Systems", yes?
>
> I wrote the "Learning Perl" parts yes. Eric Olsen (I'm probably
> mangling the spelling of his name) wrote the Win32 parts though. I
> didn't even know the book was coming out until it showed up on
> shelves. :-)
>
> Luckily, with the modern Learning Perl book, there's no need for a
> separate version. O'Reilly continues to sell it though, simply
> because it's selling. :) We've come a long way from that first series
> of books.
>

So, by your comment, I can take it to mean that the book can now cover both
*nix and Windows and that you have either told the Windows people to use .pl
or .plx correct? I look at many books on "learning" Perl and I see naming
conventions with either a *.pl or *.plx and so as a beginner this is what I
do. If it isn't supposed to be that way it shouldn't come out in print that
way. I personally like the fact that I can look at an extension and know
what type of file it is (unless subterfuge is involved).

Maybe when I ditch Windows for Linux (in the very near future) I will try it
without the extension and see if I have withdrawals. : )

[Drieux]

On Friday, Nov 14, 2003, at 08:06 US/Pacific, Randal L. Schwartz wrote:
[..]

> Luckily, with the modern Learning Perl book, there's no need for a
> separate version. O'Reilly continues to sell it though, simply
> because it's selling. :) We've come a long way from that first series
> of books.

[..]

For the FNG's - read that part again.

If you can get your hands on a 1990 edition of
programming perl, you will SOOOOOO appreciate
the literature that is out there! You will also
find that 'perldoc' that comes with perl and
the POD that is already available is way much
better than it has been!

ciao
drieux

---

[Randal L. Schwartz]

>>>>> "Bob" == Bob X <bobx@linuxmail.org> writes:

Bob> So, by your comment, I can take it to mean that the book can now
Bob> cover both *nix and Windows and that you have either told the
Bob> Windows people to use .pl or .plx correct?

Yes, I seem to recall that is what we did. We spent a lot of work
making sure that Learning Perl, 3rd edition, was Windows compatible,
although still being biased toward Unix. The intent was to make the
Gecko obsolete.

Bob> I look at many books on "learning" Perl and I see naming
Bob> conventions with either a *.pl or *.plx and so as a beginner this
Bob> is what I do.

Most Learn-Perl-in-$x-time books were written for Winders users, or
the people writing them apparently weren't familiar with the Unix (and
hence Perl) conventions.

Bob> If it isn't supposed to be that way it shouldn't
Bob> come out in print that way. I personally like the fact that I can
Bob> look at an extension and know what type of file it is (unless
Bob> subterfuge is involved).

I don't mind it for source files, but having to type "foo.pl" to run
the "foo" command strikes me as excessive user hostility.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[R. Joseph Newton]

"Randal L. Schwartz" wrote:

> >>>>> "Rob" == Rob Dixon <rob@dixon.port995.com> writes:

>
> Rob> Perl programs conventionally go in *.pl files.
>
> No. Only on broken architectures that demand it (read: "windows").

Oh?
Greetings! E:\d_drive\ocf\discuss\prototype>perl mailparse
[Picture Tk-based interface coming up--working
perfectly--here]
Greetings! E:\d_drive\ocf\discuss\prototype>

Windows doesn't impose restrictions based on extensions. It simply offers
shortcuts based on them. The use of extensions provides a visible,
human-readable [excuse me while a change my fiename back--I don't like having to
call Perl explicitly...] indication of the type of data the file contains. When
we want the system to find the application to open a file, we use the convention
provided by the system.

The OP clearly specified that he was operating under Windows. Rob's advice was
right on the mark, since the ActiveState installations do not rely on the old .pl
extensions [Perl modules need no extension under Windows, since they are opened
programatically. I have associated the Edit command with Programmers File
Editor, though, for speedier right-click access]. Perl does use the extension
system for identifying modules under Windows. It looks specifically for files
with the .pm extension.

I just checked. Without an extension, the compiler couldn't find the module.
With the .pl extension, the compiler couldn't find the module. With the .pl
extension, the comiler couldn't find the module. The OS is not imposing this
limitation. The .pm extension has no magic for Windows, because neither the
installer program nor I have imbued it with any beyond the Edit association.

So what is the Perl issue here?

Joseph

[R. Joseph Newton]

drieux wrote:

>
> Which Organizational Process????
>

The one here on Earth, specifically the one a beginner to Perl, and probably also to
programming, faces in taking his first steps to learning the language. This was the
subject of the original post, from a user who stated that he operated under Windows,
using a system that self-installs quite transparently. Rob clarified some misinformation
concerning filename associations and convention when developing in that environment.

The most recent comment seems to be about the organizational process involved with
keeping files sorted by category. It is a fairly straightforward issue. It seemed a
very cogent point. Nothing in the origin of the thread concerns the fine detail of
maintaining concurrency in an enterprise development environment. That is material for
next term, or maybe next year, for the OP.

Joseph

[R. Joseph Newton]

"Randal L. Schwartz" wrote:

> I don't mind it for source files, but having to type "foo.pl" to run
> the "foo" command strikes me as excessive user hostility.

...and so does double-clicking on the script icon?

Joseph

[Rob Dixon]

Joseph wrote:

>

> > I don't mind it for source files, but having to type "foo.pl" to run
> > the "foo" command strikes me as excessive user hostility.

>
> ..and so does double-clicking on the script icon?

Which, to be fair, doesn't allow any command-line parameters apart
from those that you thought of yesterday.

Windows uses a graphical interface with a nervous nod towards
command-line interaction. It is largely sculpted by marketing
considerations.

Similarly, Unix uses a command-line interface with bolt-on
graphics capability. Its course of life has been the result
of user bigotry.

It's up to individuals whether they choose to cross swords or
shake hands.

Rob

[Drieux]

On Saturday, Nov 15, 2003, at 23:38 US/Pacific, R. Joseph Newton wrote:
[..]

> The most recent comment seems to be about the organizational process
> involved with keeping files sorted by category. It is a fairly
> straightforward issue. It seemed a very cogent point. Nothing in
> the origin of the thread concerns the fine detail of
> maintaining concurrency in an enterprise development environment.
> That is material for next term, or maybe next year, for the OP.

[..]

and your point?

When should persons new to coding and/or perl be introduced
to the ongoing problems that both professional and amatuer
coders are all going to have to deal with, namely the classic
conflict between

code design
code maintenance

It's not like I presume that in the best of all possible worlds
folks will waltz in and have the best of all possible organization
processes in play. If anything the problem as the OP and I have
chatted a bit back channel, is that no one is teaching them about
the Great Holy Wars about which were the top level directories
in the Unix Grand Struggle between the forces of SYSV v. BSD
let alone the compromises that became the POSIX approach.

So why not offer some ideas on why a person can replicate the
basic structure in their own home directory with

/bin
/lib
/include
/src
/tmp
/man
/doc

This provides them with a basic framework of thinking about
how to provide SOME structure to that process. It also helps
them prep up for the rest of the core work that they will
need to acquire along the way. Clearly if they want to
test their installer, they can target

$ENV{HOME}/bin
$ENV{HOME}/lib/perl

They will also be able to run their own code at the command
line, or by what ever means floats their boat, by making
sure that their PATH element has that $HOME/bin element,
most likely as the first... it of course will then be
able to use as folks like to note, the FindBin offset
and/or the standard 'use lib' tricks - and NOT require
that they bloat out their command line shell environment.
Since at some point in the process they ARE going to wind
up asking that Ugly Question

I have some [functions,globals,configInfo] that I want
to share between scripts....

and then they are no longer in the happy land of merely
cobbling a few scripts here or there...

The ChomskyIte freaks tend to get into ideological struggles
about the technical minutia of syntax and semantics, and one
knows that the coding language one is working with has fully
arrived when it CAN have it's very own "Obfuscatory <ourLanguage>"
contest to establish the complete WhackoNeff that 'can' be
done in a language. Most folks forget that these started out
originally based upon the unpleasantries of 'spaghetti code'
that was unreadable, unfathomable, and PAINFULLY unmaintainable.
So the obligatory "Obfuscatory <ourLanguage>" contests, in
which I also include 'perl golf' are great for showing the
arcanea, as well as for demonstrating where THAT EDGE lies.
This allows one's fellow peers and associates to politely
recommend that one 'refactor that code' by simply suggesting
that it

a. could have won the Obfuscatory contest in <year>
b. should be nominated for this years contest.

and hence that there might be some 'best practice' that
was overlooked and should be reconsidered. If anything I
so enjoy watching the young bucks come up with, well,
"interesting solutions" to technical minutia. And the
stuff worth remembering stays and winds up in code. But
I fear my days of running off to the CodingJihaud between
this or that coding style, OS, whatEver have come and left.

Which leaves me with the dull and boring 'back and fill'
stuff to write about. Those bits of experience about why
a given set of 'habits' have become the 'best practice'.

Oh to be young again, and Dashing...

ciao
drieux

---

[R. Joseph Newton]

Rob Dixon wrote:

> Joseph wrote:

> >

> > > I don't mind it for source files, but having to type "foo.pl" to run
> > > the "foo" command strikes me as excessive user hostility.

> >
> > ..and so does double-clicking on the script icon?

>
> Which, to be fair, doesn't allow any command-line parameters apart
> from those that you thought of yesterday.
>
> Windows uses a graphical interface with a nervous nod towards
> command-line interaction. It is largely sculpted by marketing
> considerations.

I would definitely grant that limitation. I'm just not a big fan of
command-line parameters, for the most part.. I'll admit, when I
double-clicked the file I'd been working on to test my point, it was a rare
event. I'm usually running from the prompt in order to get my debugging
info. Bear in mind that that information is not significant to my user. I
only get output to STDOUT when something is going wrong.

> Similarly, Unix uses a command-line interface with bolt-on
> graphics capability. Its course of life has been the result
> of user bigotry.

Hmmmm, maybe we won't speculate on whose

> It's up to individuals whether they choose to cross swords or
> shake hands.

> Rob

Good point. Sometimes its just the weather that makes that choice. Here
Randal and I are both under these thick, clammy grey skies, following a
workweek filled with pleasant and sunny days. Bound to make one a bit
grumpy, ya know. SAD is pretty much ubiquitous in Aura-gone.

Joseph

[R. Joseph Newton]

"R. Joseph Newton" wrote:

> "Randal L. Schwartz" wrote:
>

> > Rob> Perl modules are in *.pm.

>

> > Yes, this is enforced by Perl.

>
> ... Perl does use the extension
> system for identifying modules under Windows. It looks specifically for files
> with the .pm extension.
>
> I just checked. ...

> ...

> So what is the Perl issue here?

Whoops, I forgot that Randal had covered this point. This still seems a bit strange,
that a system that Perl itself uses to keep track of file types should be such an
object of scorn when made available through an operating system. I totally forgot,
by the time I got to addressing .pm, that extensions in any context could be other
than Evil in Randal's universe.

Joseph

[Drieux]

On Sunday, Nov 16, 2003, at 13:19 US/Pacific, R. Joseph Newton wrote:

> Rob Dixon wrote:

>> Joseph wrote:

>>>> I don't mind it for source files, but having to type "foo.pl" to run
>>>> the "foo" command strikes me as excessive user hostility.
>>>
>>> ..and so does double-clicking on the script icon?

>>
>> Which, to be fair, doesn't allow any command-line parameters apart
>> from those that you thought of yesterday.
>>
>> Windows uses a graphical interface with a nervous nod towards
>> command-line interaction. It is largely sculpted by marketing
>> considerations.

>
> I would definitely grant that limitation. I'm just not a big fan of
> command-line parameters, for the most part.. I'll admit, when I
> double-clicked the file I'd been working on to test my point, it was a
> rare
> event. I'm usually running from the prompt in order to get my
> debugging
> info. Bear in mind that that information is not significant to my
> user. I
> only get output to STDOUT when something is going wrong.

[..]

before I jump into the 'sorta depends what you want'
effort to point out gooder and badder solutions in
the GUI v. CLI Jihaud, a brief refresher course on history.

let's skip over the technical details that
Windows noticed that Apple's GUI approach was
a great way of solving many of the basic simple
user interface types of problems. Since that way
would take us back to Xerox PARC, and we might not
want to get into the problems of Human Interfaces.

At which point we would also need to deal with the
slow up take that Microsoft went through in its awakening
to the fact that not only was there an internet out there
and that the web was not merely some set of Drug Addled
behaviors comeing out of CERN and DOE.... So please,
do try to remember that some of us here were around when
the sysadds at microsoft.com had their little series of
email oopsies about correctly configuring their sendmail
daemons, et al... Or should we be impolite and chat about
the MIT based 'x windows' - currently at X11R6(???) and still
a fun solution for various types of cross platform GUI solutions.

If anyone should get smacked around for

... uses a graphical interface with a nervous nod towards
command-line interaction. It is largely sculpted by marketing
considerations.

then that would be Steve Jobs, who right up to the release
of OS X was trying to convince folks that the 'terminal.app',
their CLI tool, was not really something that they were sure
was going to still be around in the production release. Mac's
were suppose to be 'gui driven' simple 'point and click' tools
for 'normal people'. But of course the Freaks who like unix
will give up their CLI interfaces ONLY after you have ripped
them from their Cold Dead Hands..

That most of the current generation of windows users may not
remember the history, let us please not try to re-write it.

That having been said, the problem of 'command line interfaces'
is one I soooooo love. If I hate anything its the freaking
'swiss army blade' approach that some folks take to making the
One True App with a Gagillion command line options. ( and
yes, if you have not read the compiler options, please, do,
those people are a leading cause of things like Make and Ant,
because, well, no SANE PERSON wants to remember all of that
smack and type any of it at the freaking command line... ).

So yes, there are times I so love the simpler 'click this'
approach to solving 'issues' on the day to day basis for
my desktop system. But there are also many very useful
and important places for 'back end systems' that will run
a whole lot simpler and leaner without a GUI interface
mechanism running to deal with them. The idea of 'headless
servers' is still something that makes many 'intel boxes',
irregardless of OS, twitch since they have this deep seated
need to see the 'monitor, mouse and keyboard' to get through
certain stages of their initialization sequence.

So if one is happy in a headless environment, then telnet,
ftp, yourFaveHere, can be your best friend. In those cases
having simple short commands with a reasonable number of
command line options is all one needs. Even IF one is going
to be stacking some 'GUI monitoring tool' at some 'front end'
to the process, to keep down one's labor costs - it is best
to remember how to build those on top of simple basic code
that becomes a bit more flexible, and hence maintainable, with
an appropriate CLI interface.

If one is never, ever, going to be working with servers,
or back end issues, then of course it is paramount that
one makes their tool set with the Human in mind.

So when we make the assertion

Its course of life has been the result of user bigotry.

it could be because the servers in the back room are for doing
things that do not need to have a lot of human interaction
with mouse, monitor, keyboard I/O sub-systems, hence the folks
who made their choice of OS's are driven by performance issues
that can be less than 'human friendly' - since one only wants
to send a human to deal with it on rare occasions, so there is
no good reason to install minesweeper on them....

I say this, having solved the generalized management solution
in perl, the old fashion way, with a few perl modules that
delivered the core common frame work, then some applications.
All of which got delivered into production, even though the
Really Cool Vendor Supplied, Vendor Supported, Vendor Licensed
GUI suite was not picked up. Ironically, of course, the folks
in the NOC were still able to 'telnet' into the unix machines
on really 'thin pipes' and maintain them with the stock stuff
delivered, but had, well, challenges on the non-unix side of
the house, since all of that was soooo tied to being GUI only...

In short pick the weapon you need for the mission you are on.
Trust me, it's a good maxim in coding as well...

ciao
drieux

[Randal L. Schwartz]

>>>>> "R" == R Joseph Newton <rjnewton@efn.org> writes:

R> I totally forgot, by the time I got to addressing .pm, that
R> extensions in any context could be other than Evil in Randal's
R> universe.

See, I never ever said that. Odd how I would get misheard on this
point.

Extensions for *commands* typed by the *user* to indicate something
that the user doesn't care about is evil. Other uses of extensions
are perfectly fine.

--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

[John W. Krahn]

Pagoda wrote:

>
> Can I improve the performance of script by using constant?

You can use the Benchmark module to test the performance of different
options.

> Which is the better one?
>
> use constant const => 1e-12
>
> or
>
> my $const = 1e-12

use works at compile time and replaces the constant name with the
constant value so it should be faster.

$ perl -MO=Deparse -le' use constant one => 1e-12; print one '

sub one () {
package constant;
$scalar;
}
print 1e-12;

-e syntax OK



John
--
use Perl;
program
fulfillment

[R. Joseph Newton]

pagoda wrote:

> Can I improve the performance of script by using constant?
>
> Which is the better one?
>
> use constant const => 1e-12
>
> or
>
> my $const = 1e-12
>
> Thanks.
> just another perl beginner

I would think that use constant would be faster. Declaring a
scalar would still require the program to access the value of
that scalar whenever it is called. The use constant form
hard-codes the value wherever the constant appears, so there
is no dereference needed:

With use constant:

consant_test.pl:
#!perl -w

use strict;
use warnings;

use constant LIMIT => 25;

for (1..LIMIT) {
print "$_\n";
}

Greetings! E:\d_drive\perlStuff>perl -MO=Deparse
constant_test.pl
BEGIN { $^W = 1; }
use constant ('LIMIT', 25);
BEGIN {${^WARNING_BITS} = "UUUUUUUUUUUU"}
use strict 'refs';
foreach $_ (1 .. 25) {
print "$_\n";
}
constant_test.pl syntax OK

With a variable:

constant_test2.pl:
#!perl -w

use strict;
use warnings;

my $LIMIT = 25;

for (1..$LIMIT) {
print "$_\n";
}

Greetings! E:\d_drive\perlStuff>perl -MO=Deparse
constant_test2.pl
BEGIN { $^W = 1; }
use warnings;
use strict 'refs';
my $LIMIT = 25;
foreach $_ (1 .. $LIMIT) {
print "$_\n";
}

Using a constant does seem to add one more step to the
compilation process, since it sets the WARNING_BITS flag.
After that, though, there should be no runtime overhead relate
to accessing that value. Besides, it is more clear. If an
idetifier is a symbolic constant for a given value, that is a
different thing than a identifier that happens to be storing
the same value at a given moment.

Joseph

[David]

Pagoda wrote:

> Can I improve the performance of script by using constant?
>
> Which is the better one?
>
> use constant const => 1e-12
>
> or
>
> my $const = 1e-12
>

the current implmentation of constant is that when you say:

use constant const => 1e-12;

it's basically translated into:

sub <caller>::const(){
1e-12;
}

where <caller> is replaced by the caller's package. so for example:

#!/usr/bin/perl -w
use strict;

use constant const => 1e-12;

print const;

__END__

is bascially translated into:

#!/usr/bin/perl -w
use strict;

sub main::const(){
1e-12;
}

print const;

__END__

which when Perl's optimizer comes in, translates it into:

#!/usr/bin/perl -w
use strict;

print 1e-12;

__END__

that's how you achive the constantness of a variable and a bit of
performance increase. it has roughly the same affact as saying:

[panda]# perl -MO=Deparse -e 'sub const(){1e-2} print const'
print 0.01;
-e syntax OK

notice the function disappear. i would recommand that you use constant
whenever possible regardless of whether it really makes your code goes
faster because of the gain of readability.

btw, you statment:

my $const = 1e-21;

is not a const at all. it's just a scalar.

david
--
s,.*,<<,e,y,\n,,d,y,.s,10,,s
..ss.s.s...s.s....ss.....s.ss
s.sssss.sssss...s...s..s....
....s.ss..s.sss..ss.s....ss.s
s.sssss.s.ssss..ss.s....ss.s
...s..sss.sssss.ss.sss..ssss.
...sss....s.s....ss.s....ss.s

,....{4},"|?{*=}_'y!'+0!$&;"
,ge,y,!#:$_(-*[./<-@{-},b-t,
..y...,$~=q~=?,;^_#+?{~,,$~=~
y.!-&*-/:-@^_{}.a-t ().;s,;,
);,g,s,s,$~s,g,y,y,%,,g,eval