At 7:04 -0500 2000.09.22, David Steffen wrote: >1) What is the newline character under OS X? Same as regular Unix, LF (\012, \x0A). While under Mac OS, I copied text files from my Mac OS startup disk to my Mac OS X disk, drag and drop. Then I needed to run `perl -pi.bak -e 's/\015/\012/g' *.PL` to fix them. I don't know of a "solution" to this problem. It might be nice to have a special drag modifier key that would convert text files appropriately (as well as a special argument to cp). Also note: perl 5.6 comes with Mac OS X Beta, but there is no perldoc, pod2man, etc. Of course, there are no compilers or other build tools, either (yet; I understand they will be made available). >2) I deleted a rambling discourse on this; so to say it briefly, >anyone who has run Perl under Windows knows why MacPerl is so >wonderful. Developing short little scripts in the simple integrated >MacPerl enviroment is quick, easy, and intuitive. Droplets fit >nicely into both the Perl and Macintosh paradigms. Unless MacOS X >eliminates drag and drop, point and click as the primary interface, I >see just as much a need for the MacPerl application under OS X as >under OS 1-9 (sez he who still has a copy of OS 1). It seems to me >this is entirely separate from the whole issue of porting the >interpreter per se; the application consists of the basic interpreter >plus a simple, intuitive development environment plus the droplet >code. OS X may change how best to port the interpreter, but it seems >to me that the development environment and the droplet code are as >useful as ever. Am I missing something? Well, I see little or no need for the MacPerl application. As for droplets, well, they would be pretty simple to create in Mac OS X. Now, here is the bad news: I made a perl script executable (chmod a+x), but it appears as a text file. This is Bad. However, I imagine it would be mostly trivial to create an executable wrapper for the script, just like the current droplet code, which would send the script and the dropped contents to /usr/bin/perl instead of MacPerl. >3) Is it anticipated that all web serving and CGI programming will be >done in an essentially Unix environment? Will the need for "save as >CGI script" have past? I imagine so. >4) Will the AppleEvents interapplication interface be entirely >replaced by a Unix stdin/stdout interface? No. Take Internet Explorer, for example. It is a Carbon or Cocoa app (which is it, and how does one tell? I dunno), yet it has no STDIN/STDOUT. I should be able to talk to it with Apple events (though I haven't yet tried, or figured out how :-). -- Chris Nandor pudge@pobox.com http://pudge.net/ Open Source Development Network pudge@osdn.com http://osdn.com/ # ===== Want to unsubscribe from this list? # ===== Send mail with body "unsubscribe" to macperl-request@macperl.org