It always scared me what my perl script is doing under Winduz because, frankly, there's no security. One can pretty much write over any file, causing potentially system-damaging results if, for example, the script is placed in the wrong directory.

Everyone knows that fork under Winduz is certainly not the same as fork under UN*X. Hell, it works only in the most minimal cases. It's rather obvious that Perl is UN*X-centric, I don't mind at all. That's my domain. For the Winduz users, it is really only an "adaptation".

The first hurdle for any programmer is to learn the environment. For MacOS and Winduz, this means potentially screwing with the GUI API and other system functionality. While Perl lets you get around that and even makes it easy to link to these APIs, there is no such hurdle under UN*X. If you want your text streamer, you get text streaming, there's no faking it. UN*X programmers benefit from a well-documented, clean-filesystem, and generic library interface.

For folks who have never programmed before, I would say it would make little difference whether they start with M$ or UN*X. They've never seen such constructs and Perl is extremely portable, meaning that the code is really the same. (OK, pretty much) What's the difference? The editor comes to mind. While they may feel more secure using a colorful IDE under their native operating system, I guess it's really just a matter of taste. While I'm programming, I abhor the mouse. The only two commands I need are:

emacs hackthematrix.pl
perl hackthematrix.pl
[download]

Enjoy Linux and reap the benefits of a fine server-capable, stable machine!

AgentM Systems nor Nasca Enterprises nor Bone::Easy nor Macperl is responsible for the comments made by AgentM. Remember, you can build any logical system with NOR.

If all you're going to be doing is text manipulation and reporting (e.g., desecting web server logs and spitting out HTML reports), then there are few practical differences between the two platforms.

If you're going to be writing CGIs that connect to databases, the differences between the two platforms are minor. Both platforms support CGIs (thought the details differ a small bit between IIS/PWS and Apache). Both platforms support DBI, though you might choose ODBC for Win32. As AgentM mentions above, you do have to worry about file ownership and permissions on *nix. (Oh, and no flock() on Win95/98.)

Simple network programming is pretty much the same on both platforms, with some minor (but irritating) differences (e.g., no reliable Alarm on Win32).

It's a bit harder to install CPAN packages on Win23, though ActiveState has many packages available for download via PPM.

The differences between the platforms are more apparent when you starting writing servers, particularly when they need to fork. Perl doesn't yet have a reliable fork() simulation on Win32. It is possible to write multiplexed servers on both platforms (Lincoln Stein's book "Network Programming with Perl" works through this in some detail), but it takes a bit of work.

Bottom line: If you're stuck on Win32, that needn't be an obstacle to learning Perl. It might not make much difference at all, depending on what you need to do with Perl.

If you are not familiar with Unix I would suggest you to install Cygwin on a windows machine. Then you get essentially a Unix environment (shell, pipes, vi, gcc...) without the learning curve involved in installing and administrating a Linux machine.

That said, if you want to learn Linux, then by all means go for it!

If you use Perl on Win32 then you won't have fork() nor alarm(). I find this to be a noticeable impediment. So, since you have the choice, I'd go with Unix.

Yes, Perl 5.6.0 for Win32 has fork() emulation but I found it trivial to break and can't recommend its use. Perhaps 5.6.1 will be significantly better (perhaps not).

The reliance on unix in the perldoc(umentation) has always been a pet peeve of mine. On the one hand, a lot of perl's functions are straight from C unix functions, but perldoc still refers you to unix manpages. The first paragraph of the sprintf documentation:

Returns a string formatted by the usual printf() conventions of the C library function sprintf(). See sprintf(3) or printf(3) on your system for an explanation of the general principles.

I mean, that just slams the door in the face of anyone trying to learn perl on a system without manpages. I might expect this for something obscure like setpgrp, but sprintf?. The docs also has very limited examples. I've been using sprintf since before Perl was conceived, so this is not an issue for me, but it's always rubbed me the wrong way when I peruse the perldocs (even ActiveState's Win32 version) and come across references to unix functions and manpages. Surely we (the perl community) can come up with something better? Telling people to learn unix is not a solution: one of the strengths of perl is, IMO, the way it transcends notions of OS and system flavors. It's a better "write once, run everywhere" than Java is (with exceptions). Basic C books take the time to expand on s?printf - why shouldn't we?

</SOAPBOX>

P.S. I know, less talk, more action. Maybe I'll add it to my incredibly long "todo" list. :)

I'm one of the select few who learned Perl on the Amiga. I've developed Perl apps for both Linux and Win32. The Amiga has an OS that's sort of like a cut-down Unix, and there are very many ports of Unix tools available, so the transition to Unix was very easy for me to make.

There are a fair few problems with using Perl on an Amiga; the ports have often been patchy at best (the last widely available pre-compiled version before 5.6 was 5.002), but I still managed to make my way through most of Learning Perl without encountering any real showstoppers. Those that I did find were with features that just plain don't work (fork being the most notable) and modules that assume facilities that can be taken for granted on Unix.

The point being, the ease with which you learn Perl is going to comparable regardless of the system it sits on. Learning specific modules and techniques may be less easy or impossible.

Personally, I feel that if Perl on Unix is a bicycle, then Perl on Win32 is a bicycle with training wheels, the brakes slightly wedged on and the front forks sawn halfway through; in some ways it's more restrictive, in others it can be a little more dangerous. It will still get you where you want to go.
"sir, you are charged with being inept in charge of an analogy. How do you plead?"

Unix is probably `easier', in that that is the OS Perl was originally designed, something that still shows throughout the language. However, if I can learn Perl on an Amiga with an operating system released in 1992, you shouldn't have any problems learning it on Win32.

-- 
flay, here to learn

To make sense of that statement, consider the projects in a CS cirriculum. When you sit down in front of Visual Studio, the IDE does half of the work for you. Now I'm a big proponent of simplified work, but when I was learning the intricate details of developing in a language, this was a barrier to me. In The Pragmatic Programmer, the authors stress that IDEs that do wizard code are only useful if you keep the wizard code away from your code. I think that the fact that "if you want wizard code in Unix, you have to create your own code generator" is a good thing when you are first being introduced to a platform of development. Less experienced programmers will have a tendency to take wizard code and make it theirs.

In the end, it's all about personal preference, but I've known a lot of people that are more comfortable developing in Unix than they are in Windows. (Perhaps the history of the two systems provides explanation to this?)

ALL HAIL BRAK!!!

If you MUST do only one, make it a unix variant like Linux or (Free|Net|Open)BSD or even Solaris.

--
$you = new YOU;
honk() if $you->love(perl)

The way i prefer to keep my scripts constant across windows and linux platforms is to do two things...

1) always create/edit/save files in the UNIX format. (most decent text editors will have this as an option).

2) find out the path of the perl binary for linux and then (for windows) copy the perl.exe binary to the same path...

for example:
on my linux box, i've got perl under '/usr/bin/', so on my windows machine, i created the directory 'C:\usr\bin\' and copied my perl.exe binary into that directory (make sure you've got all your perl directories (lib, inc, bin, etc...) in the windows PATH, or else it'll grumble and complain)
(Or, you could just install the perl distribution directly into the directory 'C:\usr'...)

along with the windows port of apache i use, and activestate perl distribution, my scripts are identical across linux/windows platforms...

of course the dos shell is a joke compare to the unix shell, all these years (20+) and somehow they cannot provide a decent command line.

good luck with your linux experimment...you may want to even try out *BSD (glad this is a no-flame node) :)

Or better yet, an Emacs -- I know that at least Emacs 20 has been ported to Win32.

Update: 20.6, to be precise.

Update again: 20.7, to be precise.

Then if you ever really need to do something on Windows you could, with the knowlege of what correct operation is. Of course by then you still might decide to stick with a networked Linux box.

I find Windows is a constant obstacle to getting the job done, in particular the programming and building is more cumbersome than Linux and also I often come up with bugs which I wonder if they are due to Microsoft or not.

For example when I use a lot of memory in CGI (Apache/Perl5.004/ Mysql on NT) I found the browser to sometimes contain an error message at the top of the page saying that system resource or command was not found. This doesn't happen in Unix; Unix and C are the reference used in Perl.

Also you can easily take advantage of automatic download, compilation, build, test, and install of tons of packages on the CPAN all from the command line. This will give you tons of material to study. And the man page system is extremely useful. I'd say you would waste a lot of time trying to install everything with Cygwin and still you might have some missing pieces.

I have found that XEmacs for NT and Mysql for NT are useful. If you develop for Linux, moving your Perl programs to other Unix environments should be a breeze too.

I have only found a couple of times I wasn't sure if Perl would be good to use, which are generally when a big part of the system is already built in heavily Microsoft-owned products like FrontPage for example. Recently someone came to me with a request to redevelop their huge tax system using open source technology since they had to rewrite it whenever new Microsoft products came out.. but that kind of work costs serious money since they are locked in. Also, an ecommerce firm I work with does Java development (on Xemacs/NT but Linux is the preferred platform and the target OS) but you probably aren't thinking about Java right now.

Finally, I develop mostly in Perl, and try to limit the time I spend with C/C++ because it costs me money. I find ASP developers on NT (who are the rest of the crowd at my company) depend on button clicks and "support" provided by other vendors instead of really understanding what is going on. Recently someone had to spend 2 thousand bucks to buy a VB liscense (in Japan) just to download automatically a web page in ASP. If you know Perl, you know its motto: There Is More Than One Way To Do It (TIMTOWTDI) and it is true. I could have used the Net library, sockets, calls to lynx or wget or ftp, or some other bunch of ways to do it, all free. The way you pay is develop something useful and put it back into the CPAN. I'd say that is the best learning environment, and since a developer always has to keep learning, a great professional development environment too. I think you'll find that writing your own code and learning to critique other people's modules will be interesting and a good investment in yourself.

Regards from Tokyo,

Matt Rosin

Hi,

From my experience, I have the two background: Windows and Unix. As I start to leanr Perl, it's true that the knowledge of the basic Unix command is a great help. But right after, it's only depends (I think) of your preference. You may not have the possibility on the two OS but Perl is very portable.

Also think to the future, if you're going to program in majority for the Windows world or from the Unix world. If you learn on Unix, you may spend more time when you will program on NT just because you started to use command that only apply/work under Unix.

lmarecha

I never really knew what shell scripts, emacs, etc. were until I started this linux trip.

My question is this: With the 3 days worth of Linux that I've seen, it seems to me that Perl would be a lot easier to learn with a linux background. Can someone with experience in both Linux/Windows give an opinion on this?

I say:

It's easier to learn Perl in an environment with a command line. Perl is wonderfully platform independent so W2K's cmd.exe, one of the Linux shells, or even clunky old command.com are fine for learning.

Unix was developed long before the advent of graphical interfaces it has very sophisticated character-oriented features and is a pleasure to use. The windows shells lack elegance but are perfectly serviceable.

If your job, like mine, has you mostly working with Wintel then stick with that until you're comfortable with Perl. Once you know Perl the transition to Linux (if you go that way) will be smoother.

If you're intrigued by emacs or vi (my DOS editor of choice since 1985) you'll find multiple versions compiled for Wintel on the internet.

Good luck. Have fun

-- David Innes

Downloading and installing perl modules on a Unix system is almost always a piece of cake.

1. download
2. gunzip
3. tar -xvf
4. perl Makefile.PL
5. make
6. make install

Update:Thanks everyone for pointing out that the way I have been installing packages for the past few months or so is not the easiest or best way. I should use ppm which I can learn about here.

whispers "PPM"

There's an even easier way to do it in Unix.

ALL HAIL BRAK!!!

ppm install DBI

          vs.

perl -MCPAN -e "install DBI" (and hope it compiles and such)

Sorry...which one was easier? :)