On Wed, 11 Apr 2001, Simon Myers wrote:
> Thanks to everybody who's offered advice. I've grouped things together
> in this message, because I thought that would be easier on people than
> if I sent a bunch of mails to the list in a row -- apologies if this
> screws up anybody's threading. Oh, and I've thought of some specific
> questions (at the end).
>
> Clinton A . Pierce wrote:
>
> > glob() can be fun,
>
> I think I'll avoid it -- if people don't know Unix, then they won't be
> used to the concept, so using readdir() then skipping files you aren't
> interested in is probably saner.
Note that if they are accostomed to running:
C:\>del foobar.*
then they'll be familiar with globbing.
> > If you're doing basic Perl, then you may not get into things like
> > fork(), kill and other process handling things.
>
> They are in there (because they are actually basic Perl -- if the
> audience is Unix C programmers, then there isn't anything inherently
> difficult about the way Perl does these things so it would silly not to
> include them) but I think I'll skip them as not being relevant.
>
> > Speaking of "sample text files" don't use things like /etc/passwd for
> > examples.
>
> That's a great point that I hadn't thought of. Ta.
>
> > Otherwise, the main problem I've had is people wanting to know how to
> > pop up dialog boxes. :)
>
> Well Perl does GTK, doesn't it? And there's a GTK port for Windows
> isn't there? Fortunately the audience are mostly concerned about using
> Perl for CGI programming, so this won't be an issue.
Tk and various Win32::* things that are a bit more native. Popping
up dialog boxes does come up even in an intro, although you are free to
offer for sale your services for a more advanced perl on win32 class ;-)
Note that dialog box popping is one of the big reasons for VBasic's
extraordinary popularity and some Win32 programmers are apt to think in
terms of "Why do I need this if VBasic can already do this?".
> > I have everyone keep a command window open and install doskey to make
> > re-execution easier.
>
> That sounds like a plan. (Why doesn't doskey /i run by default anyway?)
I think you can put that in an autoexec.bat file that is run on NT,
but my understanding is that the latter versions of Windows (2000 and
perhaps betas of XP) will automatically delete an autoexec.bat file for
you since MS is trying to cut the rug out from under software that fiddles
with autoexec.bat files upon installation (in investment banking they call
the practice "churning portfolios", in the software industry it is called
"Microsoft calls the shots and requires us to upgrade all of our
desktops" ;-)
> Peter Prymmer wrote:
>
> > ... I would have thought that encountering a Unix LINE FEED file in a
> > "Perl on Windows" class would have been an opportune time to
> > introduce how to deal with them on Windows using perl.
>
> Nice idea!
Thanks. I held a discussion off list on the matter of the seemingly
strange regular expression I advocated yesterday and it appears that
some (unixoid) folks suspect that "\n" in a double quotish context is two
characters on Windows. It is not. It is a single linefeed character.
The following will not print anything on Windows:
if ("\n" eq "\015\012") {
# this will not print on Windows:
print "\\n is indeed two characters here!\n";
}
Whereas the following will print on Windows:
if ("\n" eq "\012") {
# this will print on Windows, Unix, and VMS:
print "\\n is indeed a single line feed character here!\n";
}
> Peter Scott wrote:
>
> > Double clicking on a program will cause the output to flash in a DOS
> > window and promptly go away.
>
> Double-clicking? I was assuming we'd be able to run scripts from the
> `Command Prompt', no?
Yes you can - see also below for the "bat wrapper" approach.
> > END { print "Done, hit <RETURN>: " and <STDIN> if $^O =~ /Win32/ }
>
> I do like that, though.
>
> > You will spend most of your excess time going, "Ok, just grep the
> > files for the line containing -- oh, wait a minute --"
>
> Yes, I'll have to watch out for that. (It might provide the opportunity
> for a small amount of Unix advocacy, but I don't want to come over as
> some kind of Unix bigot who resents having to work with Windows -- the
> client is very much committed to Windows, and there wouldn't be any
> point in my causing offence.)
This would appear to be yet another place where one can show off the
capabilities of perl:
C:\>grep foo myfile.txt
The name specified is not recognized as an
internal or external command, operable program or batch file.
C:\>perl -ne "print if /foo/" myfile.txt
foo
> Now, here are some more specific questions that I've thought of:
>
> I asked the client which version and port of Perl we'll be using, but
> apparently it's up to me to specify it. Presumably I say ActivePerl
> 5.6.0.623? This seems to come in MSI and AS forms -- is this important?
>
> What's the best way of running programs? Assuming that perl.exe is in
> the path, I assume the following will work, but is there a shorter way?
>
> C:\My Documents\Perl> perl -w Hello.pl
>
> but is there a less verbose way, the equivalent of the Unix #! line?
Yes there is a way of wrappering a perl program in batch file syntax
such that it will be renamed to have a .bat file type and run when
called by name. On NT 4 w/ perl 5.005_03 (type is the NT equiv of cat):
C:\> type hello_world.pl
#!perl -w
print "Hello World\n";
C:\> pl2bat hello_world.pl
C:\> hello_world
Hello World
Note what happened (this is important for command line I/O redirection):
C:\> type hello_world.bat
@rem = '--*--Perl-*--
@echo off
if "%OS%" == "Windows_NT" goto WinNT
perl -x -S "%0" %1 %2 %3 %4 %5 %6 %7 %8 %9
goto endofperl
:WinNT
perl -x -S "%0" %*
if NOT "%COMSPEC%" "%SystemRoot%\system32\cmd.exe" goto endofperl
if %errorlevel% == 9009 echo You do not have Perl in your PATH.
goto endofperl
@rem ';
#!perl -w
#line 14
print "Hello World\n";
__END__
:endofperl
This is the cmd.exe and commmand.com equivalent of the legendary 'eval
exec' trick on strict AT&T unices that do not allow the BSD-ish
#!/path/to/perl file magic startup. Note that not being on NT (e.g.
9x) limits you to command line parameters 1 through 9.
One poorly understood or poorly documented aspect of NT file types (e.g.
associating a '.pl' type with 'perl.exe') are the 'ftype' and 'assoc'
commands. Go to a windows machine and fire up an MS-DOS window (aka DOS
virtual machine or DVM) and type:
C:\>ftype
C:\>assoc
with no argument they spew out various file type associations. With
arguments they can be used to customize your current shell environment (a
bit like issuing a setenv or export command in a unix shell without
putting it into $HOME/.tcshrc or $HOME/.bashrc). NT comes with online
help for each command.
> Related to that, is there a way of embedding the -w flag directly in
> scripts, like it can be on the Unix #! line?
See above - test it by checking for $^W.
> Obvious I can't expect Unix manpages, but does the perldoc command work
> on Windows?
Yes it does, but the ever present browser reading the local html pages is
probably just as well.
> What do you pass as the second parameter to the mkdir() function, since
> an octal permission number doesn't make a lot of sense on Windows?
Leave the argument the same as you would have used it on Unix.
> Finally, would it be worthwhile my getting the Gecko book? On the
> O'Reilly site it's described as "an introduction to `the Perl way' for
> Windows users", and I really want the opposite of that. The first few
> chapters on hashes and regexps and the like obviously won't be anything
> new, but is there anything later on that would be worth reading?
There is a brand new book with the words "Perl" and "ADO" in the title
that might prove helpful. I saw it at a bookstore recently but did not
buy it, perhaps it is this tile(?):
ActivePerl with ASP and ADO
by Tobias Martinsson
Paperback - 290 pages Bk& Cd rom edition (April 4, 2000)
John Wiley & Sons; ISBN: 0471383147 ;
Dimensions (in inches): 0.73 x 9.21 x 7.54
The content of which may be too advanced for a beginning perl class,
but it should be helpful for the instructor to study ahead of time
in preparation for the inevitable questions from advanced students.
HTH.
Peter Prymmer
