Starting Perl

[Yomna el-Tawil]

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.
for O'Reilly, i couldn't subscribe or even have the 14
days trial because i don't have a credit card.. :(
I have a question, because really i couldn't help
myself...
I don't know where to write the Perl code...
it may sound weird, but it's true..
I've got something called : "Perl Package manager", in
activestate activeperl 5.6
I don't know what to say but i need someone to tell me
from where to start...
Thank you again


__________________________________________________ ______________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger [url]http://mail.messenger.yahoo.co.uk[/url]

[Thomas bätzler]

yomna el-tawil [mailto:siwysiwy@yahoo.co.uk] asked:

> i'd like to say first that i'm using activePerl ,
> under windows.

If you've installed that properly, you're set.

> for O'Reilly, i couldn't subscribe or even have the 14
> days trial because i don't have a credit card.. :(
> I have a question, because really i couldn't help
> myself...
> I don't know where to write the Perl code...

Basically, it doesn't matter. Preferably, create
a directory for your Perl code somewhere on your
disk drive. Use any editor you like (my preference
is TextPad from [url]http://www.textpad.com/[/url]) and write
your code, i.e. for starters:

use warnings;

print "Hello, World!\n";

Save that as hello.pl in your directory. Now, open a
DOS box (i.e. Start Menu => Run => cmd.exe on Win2k/XP),
and change to your Perl directory. Now you can run your
code using the command

perl hello.pl

If you use Textpad, you can also integrate Perl in the
editor as a tool. Write your code, save it, and the hit
a simple key combo like CRTL+1 to imediately run your
code. The output is catured in another editor window.

HTH,
Thomas

HTH,
Thomas

[Rob Dixon]

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.
>
> for O'Reilly, i couldn't subscribe or even have the 14
> days trial because i don't have a credit card.. :(

I'm not sure what you mean here. O'Reilly is a book publisher
who publishes, amongst other things, the definitive 'Programming
Perl'. As far as know there's no subscription available.

> I have a question, because really i couldn't help
> myself...
>
> I don't know where to write the Perl code...
>
> it may sound weird, but it's true..

That's fine; let's try to get you started. You need to
create a file called something like 'hello.pl', containing
exactly this line:

print "Hello, world!\n";

If you have no other text editor you can use Windows' 'notepad'.

Then open a command prompt window and enter

perl hello.pl

You should get something printed if I have guessed right
about where you are.

> I've got something called : "Perl Package manager", in
> activestate activeperl 5.6

You don't need PPM unless you want to add new modules to
the ones already installed in ActivePerl. Forget about it
for now.

> I don't know what to say but i need someone to tell me
> from where to start...

Try this and post some more questions if you're stuck.

Rob

[Paul Kraus]

Notepad, emacs, vi, word with save as text only, anywhere you can write
text. That is saved as text with no special formatting.

-----Original Message-----
From: yomna el-tawil [mailto:siwysiwy@yahoo.co.uk]
Sent: Tuesday, November 11, 2003 7:09 AM
To: Beginners Perl
Subject: Starting Perl


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.
for O'Reilly, i couldn't subscribe or even have the 14
days trial because i don't have a credit card.. :(
I have a question, because really i couldn't help
myself...
I don't know where to write the Perl code...
it may sound weird, but it's true..
I've got something called : "Perl Package manager", in activestate
activeperl 5.6 I don't know what to say but i need someone to tell me
from where to start... Thank you again


__________________________________________________ ______________________
Want to chat instantly with your online friends? Get the FREE Yahoo!
Messenger [url]http://mail.messenger.yahoo.co.uk[/url]

--
To unsubscribe, e-mail: [email]beginners-unsubscribe@perl.org[/email]
For additional commands, e-mail: [email]beginners-help@perl.org[/email]

[Steve Grazzini]

On Tue, Nov 11, 2003 at 01:25:03PM -0000, Rob Dixon wrote:

> Yomna el-Tawil wrote:

>>
>> for O'Reilly, i couldn't subscribe or even have the 14
>> days trial because i don't have a credit card.. :(

>
> I'm not sure what you mean here. O'Reilly is a book publisher
> who publishes, amongst other things, the definitive 'Programming
> Perl'. As far as know there's no subscription available.

[url]http://safari.oreilly.com[/url]

They have lots of Perl books -- mostly from O'Reilly, but a few other
publishers are available as well.

--
Steve

[Drieux]

On Tuesday, Nov 11, 2003, at 04:08 US/Pacific, yomna el-tawil wrote:
[..]

> But I've got some problems,
> i'd like to say first that i'm using activePerl ,
> under windows.

remember everyone started some place.

> for O'Reilly, i couldn't subscribe or even have the 14
> days trial because i don't have a credit card.. :(

you might want to check out your local book store, as you
will ultimately want to purchase a few basic books that
will just wind up being around 'for the duration'. Ultimately
you will want to get "Programming Perl, 3rd Edition", you
would probably do well to get the learning perl for win32,
and then on to 'Perl Objects'...

The other trick is to use the available 'online' information
that should be accessible through 'perldoc' on your machine,
or you can read it online at:

<http://www.perl.org/>

which of course will recommend <http://learn.perl.org> and
more links... Since you are working with 5.6 you might want
to browse your way through

<http://www.perldoc.com/perl5.6/>

where you can read the 'POD' { Plain Old Documentation }....

> I have a question, because really i couldn't help myself...

don't feel bad, Perl is it's own 12-step programme,
and we all keep planning on gettin cured any day now.
Trust us, we can all give up coding any time we want....

> I don't know where to write the Perl code...

Well there are three core rules to always keep in mind

/Project/<name_of_project>/[files for project]

/src/tarBalls/[tarballs of projects worth keeping about]
/src/<language>/Examples/[ short files with illustrations of useful
bits ]

/MuckingAbout/[files we were just mucking about with, not a project
yet]

Remember you are the person who will have to find them when you
have that moment about

"oh FreeMonge, I did that trick once...."

So if you keep your Projects seperate from your src code tree,
and those separated from your directory for just mucking about,
then you should be able to keep them nice and tidy.

Granted, more of us are hanging out the 'useful bits' as web
pages so we can use web-search technology on our own site to
get us clues which bits were useful...

> it may sound weird, but it's true..
> I've got something called : "Perl Package manager", in
> activestate activeperl 5.6
> I don't know what to say but i need someone to tell me
> from where to start...

[..]

In the Beginning Coding was harder,
Now we have Perl, and it's just sillier and sillier.


ciao
drieux

---

[Dan Anderson]

> i'd like to say first that i'm using activePerl ,

> under windows.
> for O'Reilly, i couldn't subscribe or even have the 14
> days trial because i don't have a credit card.. :(
> I have a question, because really i couldn't help
> myself...

You're probably either going to need to pick up a book on perl or read
through the documentation and tutorials on perldoc.com. O'Reilly's
Learning Perl is a great book for beginners. Programming Perl is even
better -- but it assumes a lot of experience programming and doesn't
waste time with anything.

> I don't know where to write the Perl code...
> it may sound weird, but it's true..

Perl code takes the form of a text file. If you're under windows you'll
name your perl files with the .pm extension. If you're under unix you
put the following line as the first line of your perl file:

#! /usr/bin/perl

Of course, perl may be somewhere else then /usr/bin. Check with your
sysadmin.

> I've got something called : "Perl Package manager", in
> activestate activeperl 5.6

That's something different.

> I don't know what to say but i need someone to tell me
> from where to start...

You need a text editor. Check out GNU Emacs:

[url]http://www.gnu.org/software/emacs/emacs.html[/url]


-Dan

[Rob Dixon]

Dan Anderson wrote:

>
> Perl code takes the form of a text file. If you're under windows you'll
> name your perl files with the .pm extension.

Hi Dan.

Perl programs conventionally go in *.pl files. Perl modules
are in *.pm.

Rob

[Randal L. Schwartz]

>>>>> "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?

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. :)

Rob> Perl modules are in *.pm.

Yes, this is enforced by Perl.

--
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!

[Chris McMahon]

I name my Perl scripts on my FreeBSD box "something.pl" because I'm
the first (and so far only, but not for long) user of a Unix-y system in an
all-Windows shop, and I don't want my colleagues to be confused.
Quizzicality cuts both ways... =)
-Chris

-----Original Message-----
From: [email]merlyn@stonehenge.com[/email] [mailto:merlyn@stonehenge.com]
Sent: Wednesday, November 12, 2003 8:55 PM
To: [email]beginners@perl.org[/email]
Subject: Re: Starting Perl

>>>>> "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?

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. :)

Rob> Perl modules are in *.pm.

Yes, this is enforced by Perl.

--
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!

[Drieux]

On Thursday, Nov 13, 2003, at 07:49 US/Pacific, McMahon, Chris wrote:
[..]

> I name my Perl scripts on my FreeBSD box "something.pl" because
> I'm the first (and so far only, but not for long) user of a Unix-y
> system in an all-Windows shop, and I don't want my colleagues to be
> confused. Quizzicality cuts both ways... =)
> -Chris

[..]

You might want to be a bit more Culturally Sensitive to
the 'old guys', since, well, technically TLA's ( Three Letter Acronymns
)
should be Three Letters Long.

Once upon a time, a long long time ago, *.pl was the
official designatore for a 'perl library', then the
Perl Module suffix *.pm came into being to help ease
folks from 'require foo.pl;' across to 'use foo;' so
technically *.pl was actually taken, and should not
have been used, since it

a. had history
b. is not three letters long

hence if you wish to migrate a TLA model you should
adopt the Orthodoxy of *.plx for "perl executable".

Alternatively you might get freaky and notice that in
the Unixy World, BSD or otherwise, that there is no
need to put 'extensions' on executables, one merely
flips the executable bit on the code, and in the
dark leaves the execution to the executioner.

Helping your professional peers transition into
the realm of BSDisms is a laudable goal, but you
might want to be a bit more up front with them
about the actual options open to them.

ciao
drieux

---

[Chuk Goodin]

On Wed, Nov 12, 2003 at 07:55:24PM -0800, Randal L. Schwartz wrote:

> 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?
>
> 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. :)

What kind of naming structure would you suggest for people who just want
to use extensions for organizational purposes?

--
chuk

[Drieux]

On Thursday, Nov 13, 2003, at 09:32 US/Pacific, Chuk Goodin wrote:
[..]

>
> What kind of naming structure would you suggest for people who just
> want
> to use extensions for organizational purposes?
>

[..]

when you say for 'organizational purposes' do you
mean in terms of tracking the 'source code' in a
source code control system? Or do you mean tracking
named applications????

Allow me to illustrate my point, there is the compiled
binary executable 'head' that happens to have no extension.
But one of the small oopsies of installing the LWP onto a
Mac OSX box was that the file system is 'case insensitive'
so HEAD - the perl code stepped on 'head' the binary. So
I had two choices,

a. get the c-code source for 'head' and recompile
b. whack in the perl code alternative for it

Ok, so I also liked some of the SYSV arguments that can
be used with 'head' the binary, that are not in the BSD
variant, so I hacked the perl code to do what I wanted
rather than the standard BSD release version.

At which point we get to the core problem,

how to manage the name space problem associated with
wanting to use 'code' that will be found in the environmental
variable PATH so that one does not have to type out the fully
qualified path to the executable at the command line

One solution is the /opt/<myPackage>/bin approach in which one
will install all of their 'applications' inside of their own
package name space on the file system under "/opt" per the
POSIX standard. This is an approach that the Fink Folks like.

Yes, if one wanted to have 'head.plx' as the lwp link
to the lwp-request code that would check to see how it was
called to set default options, then one would have to hack
the actual lwp-request code to clean that up...

And that gets us where in all of this???

So the real question is

Which Organizational Process????


ciao
drieux

---

[Chuk Goodin]

> >What kind of naming structure would you suggest for people who just

> >want
> >to use extensions for organizational purposes?

>
> when you say for 'organizational purposes' do you
> mean in terms of tracking the 'source code' in a
> source code control system? Or do you mean tracking
> named applications????

Sort of both, but more of the former. Basically, if I've got a directory
sitting there with three or four different types of files in it, I'd like
to know which ones are perl (and I can just open them up in vi and fix
them) and which ones aren't (and I'll have to find the source somewhere if
I need to fix them). Right now I use .pl for that.

> how to manage the name space problem associated with
> wanting to use 'code' that will be found in the environmental
> variable PATH so that one does not have to type out
> the fully
> qualified path to the executable at the
> command line
>
> One solution is the /opt/<myPackage>/bin approach in which one
> will install all of their 'applications' inside of their own
> package name space on the file system under "/opt" per the
> POSIX standard. This is an approach that the Fink Folks like.

That seems pretty extreme for my needs.

> So the real question is
>
> Which Organizational Process????

Calling it a "process" is probably going too far.

--
chuk

[Drieux]

On Thursday, Nov 13, 2003, at 10:34 US/Pacific, Chuk Goodin wrote:
[..]

> Basically, if I've got a directory
> sitting there with three or four different types of files in it, I'd
> like
> to know which ones are perl (and I can just open them up in vi and fix
> them) and which ones aren't (and I'll have to find the source
> somewhere if
> I need to fix them). Right now I use .pl for that.

[..]

>
> Calling it a "process" is probably going too far.

[..]

You will forgive me if I whine a bit here,
first at the Unpleasant irony of 'organizational process'
as, well, .... yes, good quip.

So let us step back and look at the 'root cause problem'

so I want to just 'fix it on the fly'

and yes, foo.pl as an editable text file will allow you
simply open it with a text editor and WHACK a fix in. Unlike
RealCode[tm] that has to be 'compiled' and installed. But
why not treat your 'perl code' like as if it were RealCode[tm]?

The code that makes it out onto the 'production machines' should
be treated with some respect, irregardless of the language used, eh no?

So why not start an 'organizational process' that begins with the

this is our source code control system
this is our build and release mechanism
this is our installation mechanism

that type of process does not discriminate on the basis of
origins of source code. It likewise does not really care
much about the 'extensions' that may be 'fashionable', no?

Likewise it will help 'repeatability' and 'recoverability'
in the long run, since if you have your code under some form
of source code control, you can keep track of what got modified
by whom, and perchance why. You can also keep track of what is
'installed' - whether one is using the RPM information, or the
Solaris "Package Info", etc, etc, etc.

There is nothing quite as ugly as finding out that the only
copy of the foo code just got stomped on by an 'older version'
because, well, it was simpler to 'edit on the fly' the foo code,
because, well, it is just perl and it is editable, and it's not
like it was you know c-code or a RealCoding[tm] language...

If you back up your source tree, and cache it off site, then
one has the 'golden master' from which all can be rebuilt to
the current standard. In like manner, while at present you
may not see the usefulness of the POSIX style approach of /opt,
you may find that it will become useful for a variety of reasons
that lead to the creation and adoption of the 'standard'.

If you start this process early on, you CAN actually save yourself
much grief in the long run. ESPECIALLY when you start noticing that
there are common blocks of code in a bunch of *.pl files that could
be shifted into a common Our::Foo::Stuff perl module, and of course
at that point you want to be building it out with h2xs, so that you
can make the simpler process of having a Makefile created from the
Makefile.PL that will simplify installing the Perl Module in the
canonical CPAN style location so that all of the 'executables'
that are going to be delivered with it do not have to go gerryMeandering
around wondering where the Module got installed and can all start out
with that simple elegance of

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

use Our::Foo::Stuff;
#------------------------------
# this code does.....
....

Today it is one or two scripts, tomorrow you are up to your
yaba-Hoo-Hoo-Hoo
trying to find all n-gagillion of them that all have the same common
defect because everyone opted to just fix it on the fly, and they
cut and pasted from one to the next, and there are cats and dogs
living together....

But by going back to the 'source' you get to edit in one fix,
crank the build and release handle that punks out one more
installable, and you haul it around, just like as if it were
RealCode[tm] and have some knowledge about what is installed where
and that your life is so much simpler.

ciao
drieux

---

ps: ok, if you name is Neo, going back to the Source
may make you twitch, but it is the right thing to do,
just get in touch with your inner, uh, correctness...

[Chuk Goodin]

On Thu, Nov 13, 2003 at 11:33:14AM -0800, drieux wrote:

> So let us step back and look at the 'root cause problem'
>
> so I want to just 'fix it on the fly'
>
> and yes, foo.pl as an editable text file will allow you
> simply open it with a text editor and WHACK a fix in. Unlike
> RealCode[tm] that has to be 'compiled' and installed. But
> why not treat your 'perl code' like as if it were RealCode[tm]?

While that would indeed be the Best Practice, as a beginner just learning,
one of the things I like about perl are the differences from other
(usually compiled) languages that I'm used to. I think your answer to my
original question could be summed up as "don't do it that way". Which is
of course valid.

> But by going back to the 'source' you get to edit in one fix,
> crank the build and release handle that punks out one more
> installable, and you haul it around, just like as if it were
> RealCode[tm] and have some knowledge about what is installed where
> and that your life is so much simpler.

Thanks for spending the time to answer this, because that was a nicely
readable and accurate description of some things that are definitely a
good idea.

--
chuk

[Drieux]

On Thursday, Nov 13, 2003, at 12:29 US/Pacific, Chuk Goodin wrote:
[..]

> While that would indeed be the Best Practice, as a beginner just
> learning,
> one of the things I like about perl are the differences from other
> (usually compiled) languages that I'm used to.

[..]

Chuk, et al,

a part of the reason that we all like perl is that
we can hack quick and get something done, down and dirty.
The PROBLEM is that we can hack quick and regret at leisure.

So it is precisely BECAUSE you are in the 'learning' phase
that it is best to 'keep your eye on the prize' and remember
that "Just Because you CAN", is rarely a good enough excuse.

From my experience I actually do have all three of the
directories I have recommended

$ENV{HOME}/
src/ #
perl/ # illustrative code things
c/ # illustrative c89/c99 code things
java/ #illustrative java things
scripts/ # sh and awk stuff
tarballs/ # projects and stuff
projects/ # projects, both gigs and for fun
tmp/ # generic play space

as well as:

bin/ # my apps here
lib/ # my lib stuff - while I decide if it should be installed
perl/ # the root of the perl foo for moi
# so that I can test with
# use lib "$ENV{HOME}/lib/perl";
docs/ # stuff that documents code stuff
man/ # where manpages go...

so that I can work on ideas that I find interesting that
are not related to any specific 'paying gig' and/or
'proprietary code' - but things that make my life easier.

In this personal approach, I don't actually 'source code control'
with SSCS|RCS|Perforce|yourWidgetWingDingHere but the simpler model
of either keeping the snippets in my home src directory, or,
in the case of interesting ideas, I did the 'make dist' and
saved off the foo_bar_baz.tar.Z and stuffed it away in the tarballs
for some other day to play with it.

When the contract/gig has a source code control system,
then I use that, and well, my 'home directory' in those
cases, look just like my home directory everywhere else.
So yes, there are 'perl scripts' and there are 'perl code'
and folks need to respect BOTH classes of madness for their
appropriate use. In my case I use the *.plx so that it is
'obvious' when ported over to places that need a TLA. But
I also have 'code' that has no extension because, well,
it is just code and it just runs.

As the saying goes, the person wanted to have an idea about
how to start, so I thought I would thump the bully pulpit
on the point of starting right so as not to start bad habits
that will need to be fixed.

We of course have not stepped into 'POD' yet, but of course
that too is IMPORTANT, since if you write your POD well,
I personally have opted for the foo.pod and foo.pm and
deliver both, then when I am using foo, I just cut and
past from the pod into the code... So I raise that as
a part of the process now. It is also fun to create the
POD for the applications as well, and you can 'manify' it
so that your 'old guy unix heads' can do

man WingDingDing

and get a 'unix style manpage' on what WingDingDing as
an application is suppose to do, just like every other
vol one application...

In my own case, I finally broke down, and to simplify my
life I hung illustrative code on my web-pages, so that
way I could send the URL, vice the code. I thought I was
being Polite until one day I needed a 'trick' that I could
not remember and found myself at google doing a search on
my site for the token..... It was 'easier', it was embarrasing,
but it got cut and pasted into the code I was cutting and
worked as I wanted it.

At which point we have a nice working space in which to
go about dealing with the idioms of perl, the questions
of good form, and with any luck you will not be the
source of those postings

Need Perl Coder who can write good clean perl
based upon awkward and ungainly perl code....

and that on going problem of folks who figure out that
there are all sorts of 'operation'|QA code that is out
there that no one really knows about that keeps the shop working
but now needs to be brought under source code control
and dealt with as RealCode[tm] that has actually become
'mission critical'.

As I warned one of my friends,

If you code it,
It will go into production.

He thought I was joking right up to the moment that
he got his first bug report on his code, and there
were engineers standing around wanting to actually
know how it actually worked....

Start Right, Live Well,
laugh at the stuff you have to...

ciao
drieux

---

[Randal L. Schwartz]

>>>>> "Chuk" == Chuk Goodin <cgoodin@sfu.ca> writes:

Chuk> Sort of both, but more of the former. Basically, if I've got a
Chuk> directory sitting there with three or four different types of
Chuk> files in it, I'd like to know which ones are perl (and I can
Chuk> just open them up in vi and fix them) and which ones aren't (and
Chuk> I'll have to find the source somewhere if I need to fix them).
Chuk> Right now I use .pl for that.

Why do you need to know that before going in to the file? If the
program "frazzy" is broken, you go to "frazzy". Why do you want
to know that's Perl already?

And if you need to know, "file frazzy" will tell you precisely what it
has.

Extensions for programs convey redundant useless information, and serve
only to distract. Please don't use them on Unix.

--
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!

[Randal L. Schwartz]

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

Chris> I name my Perl scripts on my FreeBSD box "something.pl"
Chris> because I'm the first (and so far only, but not for long) user
Chris> of a Unix-y system in an all-Windows shop, and I don't want my
Chris> colleagues to be confused.

If they're using Windows, they're already hopelessly confused. :)

--
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!

[Chris McMahon]

OK, I just can't leave this one alone, I have to know... =)
You *are* the one who wrote "Learning Perl on Win32 Systems", yes?
The more-or-less definitive guide to arguably the most powerful Windows
scripting language around? Were you an entirely different person in 1997?
Posessed by MS demons, maybe? Is there anything you need to confess? I
sense some interesting Perl history here...
Apologies in advance, and please read this message with the kindness
that I wrote it (and also feel free to ignore it!)...
-Chris

-----Original Message-----
From: [email]merlyn@stonehenge.com[/email] [mailto:merlyn@stonehenge.com]
Sent: Friday, November 14, 2003 8:29 AM
To: [email]beginners@perl.org[/email]
Subject: Re: Starting Perl

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

Chris> I name my Perl scripts on my FreeBSD box "something.pl"
Chris> because I'm the first (and so far only, but not for long) user
Chris> of a Unix-y system in an all-Windows shop, and I don't want my
Chris> colleagues to be confused.

If they're using Windows, they're already hopelessly confused. :)

--
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!