At 07:08 +1000 on 30/7/97, Vicki Brown wrote: >Why call system and spawn a new process when you don't have to? Perl has >almost everything you need built in or available in the libraries. Hear hear! Just remember to use File::Copy (or is it FileCopy... I've got both and I'm confused) when copying files, rather than "open IN and OUT, read from IN write to OUT". >This brings up an interesting (IMNSHO :-) point I've noticed. I do much of >my Perl programming on the Mac. And, until I needed to write programs on >the Mac, I wrote all of my UNIX scripts in shell, awk, sed, ... That's >what I'd been doing for 10 years and I had no need to change. Then, one >day, I had to do some massive data filtering exercise; it was a choice of >MacPerl or Excel macros. (No contest; the choice took about a picosecond to >make :-) I'm using MacPerl to develop a semi-automated publishing system. The client writes their documents in Word (I *HATE* Microsoft Visual Basic). I've written a barest minimum script in Visual Basic to save the document as HTML (after reformatting it and making sure the Word copy has been saved yadda yadda). Then Perl scripts on the Solaris host take over, incorporating the documents into a FrontPage web site. I wrote the scripts entirely with MacPerl, transfer them to Slowaris, edit a couple of lines (eg: my $pathsep = "/"; my $base_directory = "/here/somewhere/") and away it goes... >I think the folks who start by writing MacPerl scripts develop a different >way of thinking ... > $cdf = "find $cd -type f -print | sort |"; As Vicki said, why fork other processes to do stuff you can do in Perl, and do it portably? Obvious answer - if you can fork on a multiprocessor system, you'll probably save time. Of course, if you're forking for a serial task or on a single processor system, you're probably wasting time. One trick I'm hoping to play with soon is RPC between Mac and Linux... one day I'll have a little "remote control" on my Mac to tell the Linux box "dial in", "restart the Web daemon" or whatever. I already do this through email (using procmail & shell scripts), but why not do it with something else? >I guess I'm wondering about other folks on this list. ... > [Do you think about] things like system() and "open ...|" ? Only in my nightmares. > Do the Mac's limitations (I work at Apple; I can call them >limitations :-) affect your Perl coding style? Yes. I write the script in Perl, as opposed to using Perl to execute my shell scripts. More often than not, a quick browse through "...:MacPerl:lib:" will reveal that someone else has already done what I was intending to do. I'm also well-set in the "portability" way of thinking, since all my first scripts have to work on my development platform (MacOS) and the target platform (Slowaris). > ___ UNIX is user-friendly ___ > (It just isn't promiscuous about which users it is friendly with) Similar to Windows 95, which is user friendly, but happens to be selective about who it works for. Regards, -Alex Windows 95: n. 32 bit extensions and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company. ***** Want to unsubscribe from this list? ***** Send mail with body "unsubscribe" to mac-perl-request@iis.ee.ethz.ch