Thanks in advance,
a confused,
Rosemary
The documentation is broken up into sections based on topic.
Reading docs this way isn't all that much fun. For an html version, go to:
http://www.perl.com/pub/q/documentation
If you are new to Perl, i highly recommend that you buy Learning
Perl, by Randal Schwartz and Tom Phoenix. It provides the best
introduction to the language that i've seen so far.
I'd also recommend BBEdit: http://www.barebones.com/products/bbedit/index.shtml
Besides being a great text editor, it is a lot of shell integration
that comes in handy when writing Perl scripts.
Good Luck and have fun.
I'd suggest a good starting point is to at least briefly forget about
being on the Macintosh, or a desktop system of any kind. You're on Unix,
for the most part, so far as the standard installation of Perl is
concerned. This means Perl is located in /usr/bin/perl, you run Perl the
same way as on Unix (either by running "/usr/bin/perl <scriptname>" in the
Terminal or by putting "#!/usr/bin/perl" at the top line of your script
and making it executable), and so on.
You might want to take a look at the many good introductory Perl books.
Most of them assume you're running on Unix unless the title says
otherwise.
(And incidentally, we don't use the colon as folder-delimeter in OS X
anymore. It's a slash, so the path would be better written
/Applications/System/Library. But Perl isn't there, it's in /usr/bin,
along with the other common Unix tools.)
Trey
--
Trey Harris
Vice President
SAGE -- The System Administrators Guild (www.sage.org)
Opinions above are not necessarily those of SAGE.
> I am a newcomer to both OS/X and Perl.
Welcome aboard!
> I'm told that while there are no
> plans to port MacPerl to OS/X, that standard Unix Perl works under OS/X
> with no problems.
That's correct, for the most part. There are no plans to port MacPerl
itself, as the standard UNIX Perl not only works with no problems, it's
shipped with OS X. Many of the Toolbox modules that previously came with
MacPerl have been Carbonated, however, and can be used with the standard
Perl that ships with OS X - see <http://projects.pudge.net> for details.
If you'd like to give GUI programming in Cocoa a whirl, there's also
Camelbones (<http://camelbones.sf.net>, with some additional examples at
<http://www.dot-app.org>). If you're just getting started, though, it
might be a good idea to try some simpler things first. Cocoa is fairly
easy going, when compared to other GUI toolkits - especially when
compared to the Classic MacOS Toolbox - but it's still somewhat complex.
> Is the Perl that came with my 10.2 complete?
Yes, it's a complete base installation of 5.6.
One thing that newbies often do is immediately attempt to install 5.8 -
something I regard as a mistake. There's nothing wrong with 5.8, it's
just that upgrading can be a trouble-prone task, and if things go wrong,
it takes some fairly deep knowledge in order to troubleshoot the
problems. What's more, if you're just getting started with Perl, there's
nothing in 5.8 that you're going to need right away anyway.
> I can find
> no documentation or executable among the files either in
> Applications:System:Library:Perl or Applications:Library:Perl. How do I
> get started? Is there a manual as part of the system?
As others have said, "Learning Perl" is a great getting-started book. If
you've programmed in other languages such as C, and you're a quick
learner, you might want to skip it and go with "Programming Perl"
instead.
All of the standard Perl docs are present; you can use either 'perldoc
perl' or 'man perl' to get started reading them. (Those are shell
commands, by the way - something you're going to need to get used to if
you're new to UNIX.)
Also, if you'd prefer, I believe there are GUI readers for browsing man
pages. I'm not familiar with any specific apps, though - see
VersionTracker. There's also ShuX, a GUI browser for perl documents in
perldoc format, similar to the MacPerl Shuck app. ShuX is part of
CamelBones, and useful even if you don't plan to write Cocoa apps.
One thing to keep in mind when reading the Perl docs is that many of
them have caveats with respect to MacOS that have not been updated to
reflect Mac OS X. If you find a document that says "if you're using UNIX
do this, but if you're using a Mac do that" - the Mac instructions are
probably referring to MacPerl under the older MacOS. For the purposes of
Perl docs, you should follow the UNIX instructions unless Mac OS X is
specifically mentioned.
sherm--
If you listen to a UNIX shell, can you hear the C?
Others have mentioned BBEdit, which is a much used interface for
running perl, but you have a huge choice of ways to do things.
First write a script in a cocoa editor, or in BBEdit, making sure that
1. You begin with the shebang
2. That the shebang is followed by a UNIX line feed.
3. That you use /UNIX/ path names and not :Mac: path names for files.
In practice you will almost certainly use UNIX line feeds throughout,
but this is not a requirement.
In your user directory create a directory named "perl_scripts" and
save this script as test.pl
#!/usr/bin/perl
for (33..93) {
s~.+~$_.chr(9).chr().$/~e ;
print
}
Now open the Applescript Script Editor and type either this:
do shell script "perl ~/perl_scripts/test.pl"
-- ~/ means YourStartupDisk:Users:YourUserName:
or this:
do shell script "cd ; perl perl_scripts/test.pl"
-- (cd means change directory to the user's home directory)
You will get the output in the result window when you click the run
button or type command-r.
Now you can try the same thing in the Terminal
/Applications/Utilities/Terminal.
Launch this and type at the prompt:
[eremita:~] jd% perl perl_scripts/test.pl
You will see the same result.
You can then try making the script executable. Type cd to get to the
home directory; type the next line to change to the perl_scripts
directory. Type ls to get a list of file names and permissions in the
dir. Then change the permissions of test.pl to make it executable.
You can now run it by typing ./test.pl in your home directory or
~/./test.pl wherever you are. Now that the script is executable, you
can also put it in ~Libary/Scripts/ and run it from the Script Menu
(click on
/Applications/Applescript/Script Menu.menu to install this).
eremita:~/perl_scripts] jd% cd #go home
[eremita:~] jd% cd perl_scripts # change dir
[eremita:~/perl_scripts] jd% ls -l #list dir
-rw-r--r-- 1 jd staff 69 May 2 01:53 test.pl
[eremita:~/perl_scripts] jd% chmod +x test.pl #make executable
[eremita:~/perl_scripts] jd% ls -l # check that it worked
-rwxr-xr-x 1 jd staff 69 May 2 01:53 test.pl
[eremita:~/perl_scripts] jd% ./test.pl # run the script
33 !
34 "
35 #
36 $
37 %
38 &
39 '
40 ( ...etc
Have fun!
JD
I've been working with Test::Unit on Mac OS X lately, I've been trying
to set up a good environment to do XP-style programming. But I can't
figure out how to assign a key command in BBEdit to run a script
(running testRunner.pl on my Test.pm file).
Right now I've got a tcsh script to run TestRunner.pl on my test.pm
module, it seems to work ok. But I've got to keep the tcsh script open,
and find it behind a bunch of other windows, which I haven't figured
out how to do quickly. I would love to minimize my mouse use while
writing perl.
Has anyone on this list set up a fast environment for unit testing?
I've seen eclipse running on linux and windows doing this, xunit
plugins for java, and it seemed to be pretty quick. Much faster than
eclipse on Mac OS X, anyway.
Any advice would be greatly appreciated.
One other curiosity: Anyone here worked with Aspect.pm? I never could
figure out the MVC model, and I'm looking to use aspects instead, seems
to make a little more sense to me. Anyone here working with aspects in
perl?
Cheers,
Troy
> Hi all,
>
> I've been working with Test::Unit on Mac OS X lately, I've been trying
> to set up a good environment to do XP-style programming. But I can't
> figure out how to assign a key command in BBEdit to run a script
> (running testRunner.pl on my Test.pm file).
Open the Scripts Palette (Windows -> Palettes -> Scripts).
Select your script from the Palette and press the "Set Key" button in the
top right corner.
Note that your script must be somewhere inside the Scripts folder of the
BBEdit Support folder for it to appear in the Scripts Palette and thus be
"key-assignable".
HTH
Riccardo
--
mailto:per...@pobox.com
http://www.riccardoperotti.com
>> Hi all,
>>
>> I've been working with Test::Unit on Mac OS X lately, I've been trying
>> to set up a good environment to do XP-style programming. But I can't
>> figure out how to assign a key command in BBEdit to run a script
>> (running testRunner.pl on my Test.pm file).
And then I wrote:
> Open the Scripts Palette (Windows -> Palettes -> Scripts)....
I just realized you were talking about perl scripts (duh!, this *is* a perl
list, after allm what was I thinking?). Sorry.
The above applies just the same, however, for scripts placed in your "BBedit
Support/Unix Support/Unix Scripts" folder. They will appear in your
"Windows->Palettes->Unix Scripts" Palette, of course.
> I've been working with Test::Unit on Mac OS X lately, I've been trying
> to set up a good environment to do XP-style programming. But I can't
> figure out how to assign a key command in BBEdit to run a script
> (running testRunner.pl on my Test.pm file).
I don't have an answer to your question, but I will tell you that, from
a Perl point of view, it's not a good idea to use Test::Unit. It was
never finished, and the maintainer has abandoned it. It has been
largely made obsolete by the release last year of Test::Class. But at
any rate, the main unit testing framework for Perl is Test::Harness
plus Test.pm, Test::Simple, or Test::More. Test::Class provides an
xUnit-like framework over Test::Harness and Test::More. If you'd like
to see an example of it in action, see the t/Bric/Test classes in the
Bricolage sources.
But most Perl users just write Perl scripts in t/ and run them using
`make test`. Grab Test::Simple from CPAN and check it out. Or just look
here:
http://search.cpan.org/dist/Test-Simple/
HTH,
David
--
David Wheeler AIM: dwTheory
da...@kineticode.com ICQ: 15726394
Yahoo!: dew7e
Jabber: The...@jabber.org
Kineticode. Setting knowledge in motion.[sm]
On Friday, May 2, 2003, at 05:17 am, Troy Davis wrote:
> I've been working with Test::Unit on Mac OS X lately, I've been trying
> to set up a good environment to do XP-style programming.
<cough bias="author"> Test::Class </cough>
> But I can't figure out how to assign a key command in BBEdit to run a
> script (running testRunner.pl on my Test.pm file).
Stick it in BBEdit Support/Unix Support/Unix Scripts, select Unix
Scripts from the Palette menu. Select your script and hit Set Key to
define a key.
[snip]
> Has anyone on this list set up a fast environment for unit testing?
> I've seen eclipse running on linux and windows doing this, xunit
> plugins for java, and it seemed to be pretty quick. Much faster than
> eclipse on Mac OS X, anyway.
>
> Any advice would be greatly appreciated.
I just use BBEdit and, since I am too lazy to press a key to run my
tests, have a little perl script that runs them automatically every
time I change a file.
I leave this sitting in a background iTerm window and have my unit
tests run every time I hit save. Instant feedback and it keeps me good.
Switch between the iTerm and BBEdit with Cmd-Tab.
See <http://www.perlmonks.org/index.pl?node_id=189293> if you're
interested.
Also, both Test::Unit and Test::Class may well be overkill for what you
want. A lot the time simple test scripts based on Test::More and
friends are more than enough for unit testing. See Test::Tutorial
<http://www.perldoc.com/perl5.8.0/lib/Test/Tutorial.html> for an
introduction.
> One other curiosity: Anyone here worked with Aspect.pm? I never could
> figure out the MVC model, and I'm looking to use aspects instead,
> seems to make a little more sense to me. Anyone here working with
> aspects in perl?
Beyond a brief play when it came out, no. I've yet to find a compelling
reason to use aspects in general, apart from some debugging tasks (if
anybody knows of some nice simple arguments I'd love to have a
reference).
I have to admit I can't really see how it would be simpler than an MVC
model :-)
There's an MP3 of a talk the author gave a few years back at
<http://prometheus.frii.com/~gnat/yapc/mp3/2001-lightning-marcel-
grunauer.mp3> that might be of interest.
If I need to do aspectish things I tend to use Devel::Symdump and
Hook::LexWrap. See <http://www.perlmonks.org/index.pl?node_id=242974>
for an example.
Hope this helps.
Cheers,
Adrian
Thank you to everyone who responded to my questions, I greatly
appreciate the pointers. (A BBEdit unix script palette, how did I miss
that before?!) I haven't had a chance to try the unit-test-on-save
plan yet, but that's next on my list after I figure this next item out:
I took the (completely unbiased ;-) advice to check out Test::Class,
but I had some trouble installing it. I might have even short-circuited
the pod test that was failing, but I got the test to pass, so I'm not
sure if I fixed it or broke it worse...
This is near the bottom of pod.t:
my $ok = $checker->num_errors < 1 && $errors !~ m/WARNING/;
$Test->ok($ok, "$module POD legal") || $Test->diag($errors);
I was getting podchecker warnings on Class.pm, which caused 'make test'
to fail in cpan. So I tried podchecker on the command line:
[Ganesha:~] davistv% podchecker
/Users/davistv/.cpan/build/Test-Class-0.03/blib/lib/Test/Class.pm
*** WARNING: multiple occurrence of link target 'Test::SimpleUnit' at
line - in file
/Users/davistv/.cpan/build/Test-Class-0.03/blib/lib/Test/Class.pm
*** WARNING: multiple occurrence of link target 'Test::Unit' at line -
in file
/Users/davistv/.cpan/build/Test-Class-0.03/blib/lib/Test/Class.pm
/Users/davistv/.cpan/build/Test-Class-0.03/blib/lib/Test/Class.pm pod
syntax OK.
I deleted one of the entries in Class.pm of "=item Test::SimpleUnit",
and the first warning disappeared. I figured since I wasn't seeing
errors from podchecker at the command line, this would overt failure
due to a warning:
my $ok = $checker->num_errors < 1 || $errors !~ m/WARNING/;
I couldn't find the uses of Test::Unit in Test::Class.pm, though. Maybe
those show up in the modules it uses?
But I also thought that my hack could lead to false positives, so I
tried this with a fresh copy:
my $ok = $checker->num_errors < 1 && $errors !~ m/ERROR/;
... and the tests passed, the module installed.
So did I just sabotage a perfectly good test, perhaps one that's
pointing to a lower-level issue on my system?
Cheers,
Troy
(I will get around to a new release soon.. really.. honest this time..
no fibbing.. Real Soon Now...)
Adrian
> I will get around to a new release soon.. really.. honest this time..
> no fibbing.. Real Soon Now...
Great news. When's the big day?
D