Re: [MacPerl] MacPerl and OS X (yet again :-)

[Joel Rees <joel_rees@sannet.ne.jp>]

Mon, 25 Sep 2000 22:30:07 -0400, Chris Nandor wrote:
>At 11:00 +0900 2000.09.26, Joel Rees wrote:
>>Adding options to cp is probably not a good idea. Better to write your
>>own cp with newline filtering options. Or, better still, just save the
>>one-liner Chris mentions here as a script (say, newlnfilter) and pipe I/O
>>that needs to be filtered through your brand-new filter:
>>
>>     % cat source.pl | newlnfilter > target.pl
>>
>>Which points out the killer problem (killer solution waiting to be found)
>>hidden behind the excitement about scripting. With true scripting,
>>program options don't have to be added. The desired effects can be
>>achieved by external filter programs. Non-algebraically minded users tend
>>to blur the distinction between option and filter, but that's no big
>>deal. (Well, maybe it's a pride issue for some engineers and
>>theoreticians like myself about ten years ago.)
>
>That's all true, but I specifically had in mind the h* tools I used to use
>in  the MkLinux distributions, like hcp that would do newline conversions
>for you and copy from mounted HFS volumes.  I don't really care what method
>is used, except insofar as Joe User has an easy go of it.
>
And that's what I would have wanted you to mean. I'm a little reactionary 
about things like putting non-standard features in standard parts.
>
>>>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).
>>
>>I wonder why. I see lots of pods and manpages about perl. The source code
>>should be easy enough to compile. License issues?
>
>Well, I imagine the perldoc/pod2man/etc. omissions were oversights.  They
>are just perl programs that need to be run:
>
>   perl pod2man.PL
>   cp pod2man /usr/bin
>
>So it is not hard.  :-)  As to the build tools (cc, make, etc.), those I
>expect to see in a distribution for us Mac OS X Beta users at some point in
>the near future.
>
Very near. Developers get two disks (which is noted on the public sites 
so I am not breaching the NDA). The tools are on the second disk. Oh, 
wait. That's select and above. On-line ADC members don't get the second 
disk, if I read that right. They have to download the tools. 

Ick. 270MB. That definitely puts things in the "near future" for many, 
one way or the other.
>
>>>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.
>>
>>Ahh! I see you have run into one of the walls between UNIX and Mac. While
>>you would not want chmod to mess with the actual contents of the file,
>>you might hope that the system commands for UNIX would influence the Mac
>>side's interpretation of a file. But this would basically require the Mac
>>OS version of chmod to build the underlying package structure around the
>>file being converted to executable, move the file down in the directory
>>structure, and generate an alias in the file's original position.
>
>I don't see why.  Why couldn't the Desktop app just see that it is +x, and
>then allow me to drop files on it, and when I do, launch a terminal, chdir
>to where the original file is, and run the executable with that file?  It
>doesn't seem Hard to me at all to do that much.  For extra points, a
>terminal window would only actually come up if there was output from the
>program; otherwise, it would just happen in the background.
>
Yeah. Wasn't that what I said? I'm sure if you reversed the belt on your 
CD-R drive and wrote my message in little-endian order UNICODE it would 
say exactly that.

But wait. Beta is hiding /bin and /usr/bin from Joe User. You can see 
them from the shell, but not from the finder. That might put a wrench in 
things. On the other hand, if the finder simply passes the drop list to 
the shell, we don't have to worry about what level the file system is 
being hidden from the finder. Maybe.

And that brings up another issue that I am sure has been kicked around. 
What happens when Joe User drops a file list on a script or program that 
expects the last name in the list to be a target? Or a tool that expects 
flags separating sublists of files? Do we dare let Joe User face the 
results of that? Is there anyway to have the finder tell what tools are 
going to cause problems with these kinds of things?
>-- 
>Chris Nandor                      pudge@pobox.com    http://pudge.net/
>Open Source Development Network    pudge@osdn.com     http://osdn.com/
>


Joel Rees
---------------------------
joel_rees@sannet.ne.jp
http://www.page.sannet.ne.jp/joel_rees


# ===== Want to unsubscribe from this list?
# ===== Send mail with body "unsubscribe" to macperl-request@macperl.org