Re: mea cupla (was Re: unix or mac-style text files?)

[William H. Magill]

On Tuesday, November 26, 2002, at 01:38 AM, Ken Williams wrote:



On Tuesday, November 26, 2002, at 04:40  PM, Chris wrote:



On Monday, November 25, 2002, at 11:20  PM, Ken Williams wrote:

On Tuesday, November 26, 2002, at 03:38  PM, Chris wrote:

On Monday, November 25, 2002, at 10:09  PM, Ken Williams wrote:

There's nothing perl can do about this - the OS (in fact, the 
kernel, I think) reads that shebang line in order to know it 
should call perl.  By the time perl gets to look at it, it's too 
late.
Kernel not involved.  Shell looks to determine with which 
application to launch executable.
The following source says otherwise, as do some knowledgeable unix 
geeks I've asked ...

I appear to have grossly misunderstood discussion on a different list 
regarding what the kernel did vs what the shell did.  I apologize for 
worsening the S/N ratio here.

Mea cupla!

No problem, this is the way people learn.  Also, the situation is 
somewhat blurry for historical reasons - the first support for shebang 
lines *was* in shells, but it's much better to do it at the system 
level (see a 1980 message from Dennis Ritchie: 
http://www.uni-ulm.de/~s_smasch/various/shebang/sys1.c.html), so 
current shells usually don't do this.

On OS X, when I look at 'man tcsh' (most OS X users' default shell) 
and search for '#!', I see some discussion of it.  The shell *can* be 
compiled with the 'hb' option to emulate the kernel's shebang 
processing, but on OS X as Apple ships it, this option is not 
activated.

Use: Http://www.uni-ulm.de/~s_smasch/various/shebang/

As the original URL does not work...

Also the man page for execve describes what is happening.

One hopes that Darwin does not have the old 32 character limit from 
Tahoe! (BSD 4.2) [See the footnotes to the table for the 3 possible 
events when the line is too long.]

The page is quite informative... Thanks for the pointer! [although the 
table is not complete by any means, it brings back memories of LONG 
nights caused by long path names.]

T.T.F.N.
William H. Magill
# Beige G3 - Rev A motherboard
# Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

Re: mea cupla (was Re: unix or mac-style text files?)

[Ken Williams]

On Tuesday, November 26, 2002, at 04:40  PM, Chris wrote:



On Monday, November 25, 2002, at 11:20  PM, Ken Williams wrote:

On Tuesday, November 26, 2002, at 03:38  PM, Chris wrote:

On Monday, November 25, 2002, at 10:09  PM, Ken Williams wrote:

There's nothing perl can do about this - the OS (in fact, the 
kernel, I think) reads that shebang line in order to know it 
should call perl.  By the time perl gets to look at it, it's 
too late.
Kernel not involved.  Shell looks to determine with which 
application to launch executable.
The following source says otherwise, as do some knowledgeable 
unix geeks I've asked ...

I appear to have grossly misunderstood discussion on a 
different list regarding what the kernel did vs what the shell 
did.  I apologize for worsening the S/N ratio here.

Mea cupla!

No problem, this is the way people learn.  Also, the situation 
is somewhat blurry for historical reasons - the first support 
for shebang lines *was* in shells, but it's much better to do it 
at the system level (see a 1980 message from Dennis Ritchie: 
http://www.uni-ulm.de/~s_smasch/various/shebang/sys1.c.html), so 
current shells usually don't do this.

On OS X, when I look at 'man tcsh' (most OS X users' default 
shell) and search for '#!', I see some discussion of it.  The 
shell *can* be compiled with the 'hb' option to emulate the 
kernel's shebang processing, but on OS X as Apple ships it, this 
option is not activated.

So you've got some good reasons for being confused. ;-)

[Note that I've trimmed p5p from the recipient list, since most 
people there probably already know this stuff...]

 -Ken

mea cupla (was Re: unix or mac-style text files?)

[Chris]

On Monday, November 25, 2002, at 11:20  PM, Ken Williams wrote:

On Tuesday, November 26, 2002, at 03:38  PM, Chris wrote:

On Monday, November 25, 2002, at 10:09  PM, Ken Williams wrote:

There's nothing perl can do about this - the OS (in fact, the 
kernel, I think) reads that shebang line in order to know it should 
call perl.  By the time perl gets to look at it, it's too late.
Kernel not involved.  Shell looks to determine with which application 
to launch executable.
The following source says otherwise, as do some knowledgeable unix 
geeks I've asked ...

I appear to have grossly misunderstood discussion on a different list 
regarding what the kernel did vs what the shell did.  I apologize for 
worsening the S/N ratio here.

Mea cupla!

--Chris

Re: unix or mac-style text files?

[Peter N Lewis]

At 15:09 +1100 26/11/02, Ken Williams wrote:

On Tuesday, November 26, 2002, at 12:49  PM, Peter N Lewis wrote:



But is there any reason the # comments are not terminated by the 
first occurrence of *either* \012 or \015?

There's nothing perl can do about this - the OS (in fact, the 
kernel, I think) reads that shebang line in order to know it should 
call perl.  By the time perl gets to look at it, it's too late.

Ahh, yes, good point.

Except - the shell reads the file and executes the program that is 
the first word after the #! so perl will indeed get called for a file 
with the wrong line endings, although it might get called with the 
entire file inserted into the ARGV.  But then perl does all sorts of 
wacky emulation at that point anyway, so don't ask me what goes on 
there, I couldn't figure it out.

For example, a file containing

#!/bin/ps auxw

when executed does the ps with those flags.

A file containing

#!/bin/echo -e 'foreach (@ARGV) { print "$_\n"; }'
blah blah blah

displays 'foreach (@ARGV) { print "$_\n"; }'

But a file containing

#!/usr/bin/perl -e 'foreach (@ARGV) { print "$_\n"; }'
foreach (@ARGV) { print "$_\n"; }

displays nothing, presumably because of perl doing some wacky 
emulation on the command line.

Enjoy,
   Peter.

--
  

Re: unix or mac-style text files?

[Ken Williams]

On Tuesday, November 26, 2002, at 03:38  PM, Chris wrote:


On Monday, November 25, 2002, at 10:09  PM, Ken Williams wrote:


There's nothing perl can do about this - the OS (in fact, the 
kernel, I think) reads that shebang line in order to know it 
should call perl.  By the time perl gets to look at it, it's 
too late.

Kernel not involved.  Shell looks to determine with which 
application to launch executable.

The following source says otherwise, as do some knowledgeable 
unix geeks I've asked about it.

  http://www.faqs.org/faqs/unix-faq/faq/part3/section-16.html


I kinda doubt the shell clips the first line and feeds only the 
later fragment to the executing file;  I suspect Perl gets the 
file and can parse as it likes.

True, perl gets the whole file, but before perl enters the 
picture at all, the kernel has to figure out whether to call 
perl, python, sh, or whatever.  That's the process that we don't 
have the ability to "correct" inside perl.

perl does indeed do some processing of the arguments in the 
shebang line - that's why it honors shebang switches (except 
ones it can't, like -T) even when you invoke it as "perl 
filename.pl" and the shebang mechanism isn't invoked.

 -Ken

Re: unix or mac-style text files?

[Chris]

On Monday, November 25, 2002, at 10:09  PM, Ken Williams wrote:


There's nothing perl can do about this - the OS (in fact, the kernel, 
I think) reads that shebang line in order to know it should call perl. 
 By the time perl gets to look at it, it's too late.

Kernel not involved.  Shell looks to determine with which application 
to launch executable.  I kinda doubt the shell clips the first line and 
feeds only the later fragment to the executing file;  I suspect Perl 
gets the file and can parse as it likes.

Take care,
	Chris

Re: unix or mac-style text files?

[Ken Williams]

On Tuesday, November 26, 2002, at 12:49  PM, Peter N Lewis wrote:


At 13:51 + 25/11/02, Nicholas Clark wrote:

On Mon, Nov 25, 2002 at 02:33:45PM +0100, Rafael Garcia-Suarez wrote:

 Chris Nandor <[EMAIL PROTECTED]> wrote:
 >
 > That shouldn't work.  By the time you get to it in the 
script, if you have a
 > #! line, then the entire script is one long comment, and 
the use() line
 > won't ever be executed.

 That would be an argument for allowing -M/-m on the #! line.

Er, except that the #! line would all have been read by then, 
and treated
as a comment. Or have I got things confused?

But is there any reason the # comments are not terminated by 
the first occurrence of *either* \012 or \015?

There's nothing perl can do about this - the OS (in fact, the 
kernel, I think) reads that shebang line in order to know it 
should call perl.  By the time perl gets to look at it, it's too 
late.

 -Ken

Re: libapreq-1.1 Release Candidate 1

[Ken Williams]

On Tuesday, November 26, 2002, at 12:22  PM, Joe Schaefer wrote:


Ken Williams <[EMAIL PROTECTED]> writes:

[...]


I've attached the full output.


Thanks, Ken.  I looked over the result, but didn't see any
indication that you used the "./configure -> make -> make install"
instructions from the web page.


D'oh!  I just looked at the INSTALL file, despite your 
admonitions to the contrary.  Sorry to overlook it.

I got through "./configure -> make -> make install" 
successfully, installing to /usr/local/lib/ and 
/usr/local/include/.  However, there doesn't seem to be a 
"ldconfig" on my system ('locate' couldn't find one anywhere, 
and I checked manually in /sbin/ and /usr/sbin/).

Did the libtool-based build
of libapreq install successfully before you tried doing the perl
build?


This time around, I installed libapreq and then did 'perl 
Makefile.PL; make test;' and got a different error.  Looks like 
the server didn't start properly.

I've attached the terminal output, and the httpd.conf in case 
it's helpful.  The t/error_log is unremarkable (just a bunch of 
stuff like "[warn] module mod_log_config.c is already added, 
skipping").


 -Ken


libapreq-out
Description: application/applefile


libapreq-out
Description: Binary data


httpd.conf
Description: Binary data

Re: unix or mac-style text files?

[Peter N Lewis]

At 13:51 + 25/11/02, Nicholas Clark wrote:

On Mon, Nov 25, 2002 at 02:33:45PM +0100, Rafael Garcia-Suarez wrote:

 Chris Nandor <[EMAIL PROTECTED]> wrote:
 >
 > That shouldn't work.  By the time you get to it in the script, 
if you have a
 > #! line, then the entire script is one long comment, and the use() line
 > won't ever be executed.

 That would be an argument for allowing -M/-m on the #! line.

Er, except that the #! line would all have been read by then, and treated
as a comment. Or have I got things confused?


But is there any reason the # comments are not terminated by the 
first occurrence of *either* \012 or \015?

I can't see how this would affect any perl script, since presumably 
not unix script has a cr hidden in a comment (and similarly for Mac 
script and lf), and even for DOS, the cr will terminate the comment 
and the lf will be an irrelevant  white space (comments can't be 
inside anything that is storing white space, right?)

This would solve the #! commenting out the entire file issue, and 
allow the -M flag on the #! line to work.

Enjoy,
   Peter.

--
  

Re: Device::SerialPort

[Dave Gomez]

Rob,
I got it to compile on 10.2, but I had to do some tweaks.  I'm using it
to talk to serial port on a keyspan usb->serial device, and also in a imac
with a stealthport, works great.  I used version 0.7 tho, and I'd have to
get it down to do a diff.  If your interested, I can send you the gzip of a
compiled version ready for install, or look at it via a diff, but that'll
take longer.

Dave Gomez

On 11/25/02 6:03 PM, "Rob Barris" <[EMAIL PROTECTED]> wrote:

> 
> 
> http://search.cpan.org/author/COOK/Device-SerialPort-0.12/SerialPort.pm
> 
>   This would be handy (for me) but it doesn't build on OSX, no doubt
> because IOKit's interface is different from POSIX/Linux style device
> control.
> 
>   I do have a couple pieces of sample source for talking to serial
> ports on OSX, but was wondering if anyone else had looked at this type
> of thing or ported similar code that needs to do ioctl's etc.
> 
>   Specific examples of serial port devices that do show up under OSX
> in the /dev directory would be the Keyspan USB->serial adaptors and (I
> believe) the Griffin Stealth Serial plugin card that goes in the modem
> slot.
> 
> Rob
> 
> 

Device::SerialPort

[Rob Barris]

http://search.cpan.org/author/COOK/Device-SerialPort-0.12/SerialPort.pm

   This would be handy (for me) but it doesn't build on OSX, no doubt 
because IOKit's interface is different from POSIX/Linux style device 
control.

   I do have a couple pieces of sample source for talking to serial 
ports on OSX, but was wondering if anyone else had looked at this type 
of thing or ported similar code that needs to do ioctl's etc.

   Specific examples of serial port devices that do show up under OSX 
in the /dev directory would be the Keyspan USB->serial adaptors and (I 
believe) the Griffin Stealth Serial plugin card that goes in the modem 
slot.

Rob

Re: libapreq-1.1 Release Candidate 1

[Ken Williams]

Hi Joe & APReq,

I'm glad this is receiving attention, Apache::Request has had 
some trouble on OS X as I'm sure you're aware.  I just tested 
the RC, using:

 perl 5.6.1
 Apache/1.3.26 (as shipped with the OS, uses dso)
 OS X 10.1.5

and I get this error in 'make test':

dyld: t/httpd multiple definitions of symbol _ApacheRequest___parse
blib/arch/auto/Apache/Request/Request.bundle definition of 
_ApacheRequest___parse
blib/arch/auto/Apache/Cookie/Cookie.bundle definition of 
_ApacheRequest___parse
make: *** [start_httpd] Error 66

I believe this was the same error from several months ago, that 
the binary namespaces of Apache::Request and Apache::Cookie are 
conflicting.

I've attached the full output.

 -Ken

On Tuesday, November 26, 2002, at 10:34  AM, Joe Schaefer wrote:


The apreq developers are planning a maintenance release of
libapreq-1.1.  This version does not include support for
modperl-2, but it does address some outstanding problems in
1.0:

  * OS X support
  * perl 5.8 segfaults related to file uploads.

Please give the tarball at

  http://www.apache.org/~joes/libapreq-1.1_rc1.tar.gz

a try and report comments/problems/etc. to the apreq-dev list
at [EMAIL PROTECTED]  There are special build
instructions for OS X, so be sure to have a look at

  http://www.apache.org/~joes/

for details on OS X support.  We'll be patching the INSTALL &
README documents based on OS X user feedback.

Note:  We really could use more volunteers participating
in apreq-dev, especially folks with OS X experience.  Even though
libapreq is a small (ASF) project, there's plenty of work to be
done- both in improving/supporting the libapreq-1.x codebase as
well as porting apreq to modperl-2.

Thanks.

--
Joe Schaefer



libapreq-out
Description: application/applefile


libapreq-out
Description: Binary data

Re: unix or mac-style text files?

[Rob Barris]

On Monday, November 25, 2002, at 03:27 PM, William H. Magill wrote:


On Monday, November 25, 2002, at 08:50 AM, Chris Nandor wrote:

While they're at it, they might drop file resource forks.


Again, they essentially have.  They are still supported because, as 
with the
CR issue, they cannot just abandon them.  But most apps do not have 
them;
instead, the resource data is in separate files inside the packages.  
I
don't imagine support for resource forks will be dropped any time 
soon, but
resource forks aren't really used by new apps.

  ...


Out of all my apps in there, I got hits in maybe a dozen or so, and 
the only
*Apple* apps were iMovie and DVD Player.  It's fairly clear that 
resource
forks are being used less, and I imagine Apple is discouraging their 
use,
since they are no longer needed.

I believe that you will find Chris' explanation to be correct -- OS X 
does
NOT use resource forks. It is only OS 9 compatibility which maintains 
their existence.


OS X "uses" a resource fork every time it launches a CFM application so 
it can find the 'cfrg' resource in the app :)

But Chris' point makes sense.

Rob

libapreq-1.1 Release Candidate 1

[Joe Schaefer]

The apreq developers are planning a maintenance release of
libapreq-1.1.  This version does not include support for
modperl-2, but it does address some outstanding problems in
1.0:

  * OS X support
  * perl 5.8 segfaults related to file uploads.

Please give the tarball at 

  http://www.apache.org/~joes/libapreq-1.1_rc1.tar.gz

a try and report comments/problems/etc. to the apreq-dev list
at [EMAIL PROTECTED]  There are special build 
instructions for OS X, so be sure to have a look at 

  http://www.apache.org/~joes/

for details on OS X support.  We'll be patching the INSTALL & 
README documents based on OS X user feedback.

Note:  We really could use more volunteers participating
in apreq-dev, especially folks with OS X experience.  Even though
libapreq is a small (ASF) project, there's plenty of work to be 
done- both in improving/supporting the libapreq-1.x codebase as
well as porting apreq to modperl-2.

Thanks.

-- 
Joe Schaefer

Re: unix or mac-style text files?

[William H. Magill]

On Monday, November 25, 2002, at 08:50 AM, Chris Nandor wrote:

While they're at it, they might drop file resource forks.


Again, they essentially have.  They are still supported because, as 
with the
CR issue, they cannot just abandon them.  But most apps do not have 
them;
instead, the resource data is in separate files inside the packages.  I
don't imagine support for resource forks will be dropped any time 
soon, but
resource forks aren't really used by new apps.

  ...


Out of all my apps in there, I got hits in maybe a dozen or so, and 
the only
*Apple* apps were iMovie and DVD Player.  It's fairly clear that 
resource
forks are being used less, and I imagine Apple is discouraging their 
use,
since they are no longer needed.

I believe that you will find Chris' explanation to be correct -- OS X 
does
NOT use resource forks. It is only OS 9 compatibility which maintains 
their existence.

T.T.F.N.
William H. Magill
# Beige G3 - Rev A motherboard
# Flat-panel iMac (2.1) 800MHz - Super Drive - 768 Meg
[EMAIL PROTECTED]
[EMAIL PROTECTED]
[EMAIL PROTECTED]

RE: Perl Help Please

[Chuck Taylor]

Thanks Troy,

The CD was a problem but not entirely, some of my close but not perfect
scripts did not contain the cdTruBlueEnvironment&; statement.  It's amazing
how you look at something a thousand times and never see something until
someone points it out.

TruBlueEnvironment is inside of the contents of "Classic Startup.app" when
launching Classic in this manner via the Applescript it opens Classic
silently no windows at all, well with the exception of the Terminal window.

That's what I was trying to avoid is the window thing, either by terminal or
by the app itself.  Here is another try, but I'm getting the same result
from the terminal "Bad Command"

#!/usr/bin/perl

cd '/System/Library/CoreServices/ClassicStartup.app/Contents/Resources/';./
TruBlueEnvironment&;exit



Should I be saving this script as an executable or make it a Terminal
command?

Thanks
Chuck

-Original Message-
From: Troy Davis [mailto:[EMAIL PROTECTED]] 
Sent: Monday, November 25, 2002 2:23 PM
To: Chuck Taylor
Cc: [EMAIL PROTECTED]
Subject: Re: Perl Help Please

Hi Chuck,

Try this:

---
#!/usr/bin/perl

my $status = `open -a /System/Library/CoreServices/"Classic Startup.app"`;
---

I don't know what this means, though:
../cdTruBlueEnvironment&;

Are you trying to cd into that dir?

Cheers,
Troy

>This Perl newbie needs a little advanced help.  I'm trying a new
>
>Login Hook to start classic, I made the Perl script out of an
>
>Applescript.  However, and probably not surprising to you, it did not
>
>work.
>
>
>
>It does work in the Applescript but I would prefer to make Perl for use
>
>in a hook.  Here is the Applescript
>
>
>
>
>
>property appPath : "/System/Library/CoreServices/Classic
>
>Startup.app/Contents/Resources/"
>
>property appName : "TruBlueEnvironment"
>
>tell application "Terminal"
>
>do script with command "cd '" & appPath & "';./" & appName & "&;exit"
>
>delay 6
>
>end tell
>
>#
>
>
>
>After doing some debugging this is what I thought the Perl script
>
>should look like.
>
>
>
>#!/usr/bin/perl
>
>
>
>/System/Library/CoreServices/Classic
>
>Startup.app/Contents/Resources/';./cdTruBlueEnvironment&;
>
>
>
>I made sure it was executable using chmod +X but each time I test it I
>
>get a bad command.  What did I miss
>
>
>
>Any help would be appreciated, Thanks!
>
>
>
>Chuck Taylor
>
>San Juan Unified School District K-12
>
>
>
>
>
>


-- 
___
There's nothing remarkable about it.  All one has to do is hit the right
keys at the right time and the instrument plays itself.
  - J.S. Bach

Re: Perl Help Please

[Troy Davis]

Hi Chuck,

Try this:

---
#!/usr/bin/perl

my $status = `open -a /System/Library/CoreServices/"Classic Startup.app"`;
---

I don't know what this means, though:
../cdTruBlueEnvironment&;

Are you trying to cd into that dir?

Cheers,
Troy


This Perl newbie needs a little advanced help.  I'm trying a new

Login Hook to start classic, I made the Perl script out of an

Applescript.  However, and probably not surprising to you, it did not

work.



It does work in the Applescript but I would prefer to make Perl for use

in a hook.  Here is the Applescript





property appPath : "/System/Library/CoreServices/Classic

Startup.app/Contents/Resources/"

property appName : "TruBlueEnvironment"

tell application "Terminal"

   do script with command "cd '" & appPath & "';./" & appName & "&;exit"

   delay 6

end tell

#



After doing some debugging this is what I thought the Perl script

should look like.



#!/usr/bin/perl



/System/Library/CoreServices/Classic

Startup.app/Contents/Resources/';./cdTruBlueEnvironment&;



I made sure it was executable using chmod +X but each time I test it I

get a bad command.  What did I miss



Any help would be appreciated, Thanks!



Chuck Taylor

San Juan Unified School District K-12









--
___
There's nothing remarkable about it.  All one has to do is hit the right
keys at the right time and the instrument plays itself.
 - J.S. Bach

Perl Help Please

[Chuck Taylor]

This Perl newbie needs a little advanced help.  I'm trying a new 

Login Hook to start classic, I made the Perl script out of an 

Applescript.  However, and probably not surprising to you, it did not 

work.

 

It does work in the Applescript but I would prefer to make Perl for use 

in a hook.  Here is the Applescript

 



property appPath : "/System/Library/CoreServices/Classic 

Startup.app/Contents/Resources/"

property appName : "TruBlueEnvironment"

tell application "Terminal"

   do script with command "cd '" & appPath & "';./" & appName & "&;exit"

   delay 6

end tell

#

 

After doing some debugging this is what I thought the Perl script 

should look like.

 

#!/usr/bin/perl

 

/System/Library/CoreServices/Classic 

Startup.app/Contents/Resources/';./cdTruBlueEnvironment&;

 

I made sure it was executable using chmod +X but each time I test it I 

get a bad command.  What did I miss

 

Any help would be appreciated, Thanks!

 

Chuck Taylor

San Juan Unified School District K-12

 

 

 

Re: unix or mac-style text files?

[Sébastien Aperghis-Tramoni]

On Monday, November 25, 2002, at 02:09 PM, Chris Nandor wrote:


In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Slaven Rezic) wrote:

Could this be made even more generic, but translating to \n instead of 
\012?

Or use source filters:

package Filter::Any2Unix;


Any2Native?


When I had LinuxPPC on my Mac (when Mac OS X was still Rhapsody),
I had written this little module to run my Perl scripts with Mac 
end-of-lines
under Linux. Not pretty but still functional.

package Eol;
use Carp;

=head1 NAME

Eol - Perl module to execute scripts with foreign end-of-line character

=head1 SYNOPSIS

perl -MEol foo.pl

=head1 DESCRIPTION

This module allow one to execute Perl programs with foreign end-of-line
character. It's primarily intented to be executed on Unix systems as it
must be passed in argument to C, but it may also work on Win32
systems.

=cut

if($0 ne '-e') {
my $script;

READ: {
  local $/;
  open(FILE, $0) or croak "can't read file '$0': $!";
  undef $/;
  $script = ;  ## read whole file
  close(FILE);
}

$script =~s@(\015\012|\015|\012)@$/@g;

eval $script;
print $@ if $@

} else {
carp "warning: module Eol can't be used on -e scripts "
}

1;
__END__


Sébastien Aperghis-Tramoni
 -- - --- -- - -- - --- -- - --- -- - --[ http://maddingue.org ]

Re: unix or mac-style text files?

[Nicholas Clark]

On Mon, Nov 25, 2002 at 02:33:45PM +0100, Rafael Garcia-Suarez wrote:
> Chris Nandor <[EMAIL PROTECTED]> wrote:
> > 
> > That shouldn't work.  By the time you get to it in the script, if you have a 
> > #! line, then the entire script is one long comment, and the use() line 
> > won't ever be executed.
> 
> That would be an argument for allowing -M/-m on the #! line.

Er, except that the #! line would all have been read by then, and treated
as a comment. Or have I got things confused?

 (that's 3 dots, perl.org smtp daemon)

the kernel parses the -M line and invokes perl with those -M options.
then perl runs and reaches the -M line again, and now we just need it not
to complain like it currently does.

I hoped it would be possible to hack round it in some way, relying on
\r being whitespace, so that

#!/usr/local/bin/perl -w
-MFilter if 0;

would behave as a no-op on a system with matching \n, and as 

#!/usr/local/bin/perl -w -MFilter if 0;

on a system where \n and \r are transposed, but I can't make it work.

Nicholas Clark

PS I need to dig it out of the archives for a second time, but nothing came
   of my #! line \r\n protector that works on everything it was tested on
   (Linux, FreeBSD, Solaris - so hopefully all SysV, BSD* and Linux)

Re: unix or mac-style text files?

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Heather Madrone) wrote:

> At 11:05 AM 11/24/2002 -0500, Chris Nandor wrote:
> >But back to the point: there's been some discussion in this threa on 
> >workarounds, but my personal feeling is that this is a bug, or at best a 
> >broken feature, in perl.  Some time ago, the capability was added to perl to 
> >recognize and filter CRLF files to work on Unix and LF to work on Windows 
> >(grep for PERL_STRICT_CR in toke.c).  However, this functionality was not 
> >extended to CR files, as it should have been, IMO.  
> 
> I think you're right.  It's easier to move back and forth from
> Windows to Solaris than it is to move from one side of the Mac
> house to the other.  This is undoubtedly broken, not just in
> perl, but on the Macintosh in general.

Well, I'd say it is only broken in perl because there is some support for 
it, but it is limited only to certain platforms.  Otherwise I'd call it a 
woefully missing feature.

I don't think it is, in the general case, broken on the Mac, however.  They 
can't just abandon CR, and they shouldn't have stuck with CR instead of 
moving to LF.  And CR itself wasn't broken to begin with.  They really 
didn't have many options; that is to say, the brokenness we encounter 
because of the CR/LF differences are not indicative of a brokenness in the 
OS, but just unfortunate confluence of events.


> Personally, I think that Apple would be wise to move to the Unix
> standard for text files.  It would take several releases of
> confusion to do it, but that would be better than carrying 
> forward this schizophrenia to future OS generations.

It has moved to the Unix standard.  Many apps, however, have not entirely 
made the adjustment.


> While they're at it, they might drop file resource forks.

Again, they essentially have.  They are still supported because, as with the 
CR issue, they cannot just abandon them.  But most apps do not have them; 
instead, the resource data is in separate files inside the packages.  I 
don't imagine support for resource forks will be dropped any time soon, but 
resource forks aren't really used by new apps.

  [pudge@bourque]$ perl -MFile::Find -MMac::Files -e 'find(sub{my $f = 
  $File::Find::name; return if ! -f || -l; my $catf = FSpGetCatInfo($_); 
  printf "%s : %d\n", $f, $catf->ioFlRLgLen if $catf->ioFlRLgLen}, shift)' 
  /Applications/

The above one-liner prints out the size of the resource fork in every file 
under /Applications/ (ioFlRLgLen is the logical length of the resource fork, 
while ioFlLgLen is the logical end of the data fork; the -s file test 
operator and other file utilities, in perl and in Unix, only display the 
data fork size, so it should always be the case that -s $f == 
$catf->ioFlLgLen).

Out of all my apps in there, I got hits in maybe a dozen or so, and the only 
*Apple* apps were iMovie and DVD Player.  It's fairly clear that resource 
forks are being used less, and I imagine Apple is discouraging their use, 
since they are no longer needed.


> If Apple doesn't want to give up its own peculiar file formats,
> then they ought to fix their Unix so it handles Macintosh files
> sensibly.

Apple assumes -- for right or wrong -- that people who use the Unix side of 
things will be able to figure out how to deal with the resource forks, the 
newlines, etc. (with tools such as CpMac, ditto)  Let's face it: the Unix 
user side of things is relatively minor in priority to most other things in 
the OS.  And really, it should be that way: it is used relatively little and 
its users are smart enough to figure out workarounds.  Life sucks sometimes.  
;-)

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: unix or mac-style text files?

[Rafael Garcia-Suarez]

Chris Nandor <[EMAIL PROTECTED]> wrote:
> 
> That shouldn't work.  By the time you get to it in the script, if you have a 
> #! line, then the entire script is one long comment, and the use() line 
> won't ever be executed.

That would be an argument for allowing -M/-m on the #! line.

Re: unix or mac-style text files?

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Slaven Rezic) wrote:

Could this be made even more generic, but translating to \n instead of \012?

> Or use source filters:
> 
> package Filter::Any2Unix;

Any2Native?

> use Filter::Util::Call;
> sub import {
> if ($^O ne 'MacOS') {

#?

>   filter_add(sub {
>  my($status) = filter_read();
>  if ($status > 0) {
>  s/\015\012|\015|\012/\012/g;

/\n/g ?

>  }
>  }
> );
> }

#?

> }
> 
> and then call the script with 
> 
>perl -MFilter::Any2Unix script.pl
> 
> or embed "use Filter::Any2Unix" into the script.

That shouldn't work.  By the time you get to it in the script, if you have a 
#! line, then the entire script is one long comment, and the use() line 
won't ever be executed.

-- 
Chris Nandor  [EMAIL PROTECTED]http://pudge.net/
Open Source Development Network[EMAIL PROTECTED] http://osdn.com/

Re: unix or mac-style text files?

[Slaven Rezic]

Chris Nandor <[EMAIL PROTECTED]> writes:

> In article <[EMAIL PROTECTED]>,
>  [EMAIL PROTECTED] (Dan Kogai) wrote:
> 
> > On Monday, Nov 25, 2002, at 01:05 Asia/Tokyo, Chris Nandor wrote:
> > > The bottom line was that it'd be nice to have a PerlIO filter for perl
> > > 5.8.x, so that MacPerl can execute Unix and Windows text files, and 
> > > Mac OS X
> > > perl can execute Mac OS text files, etc.  Patches are surely welcome!  
> > > :-)
> > 
> > One good question may be how to handle newlines in heretext, the only 
> > part that really matters because that's the only exception to the fact 
> > that newlines are nothing but whitespace from perl compiler's point of 
> > view -- oops, shebang is another.  When you feed MacPerl *.pl to MacOS 
> > X, should linefeeds in heretext emit \015 or \012?
> 
> I am talking here about taking (for example) a perl program with Mac OS 
> newlines, and making it run under Unix perl.  In order for that to happen, 
> you need to translate all the CRs to LFs.  That would include the CRs in the 
> heretext, as well as in every literal string.
> 
> 
> 
> > I am not sure which is lazier to simply apply
> > 
> > # Any -> Unix
> > perl -i.bak -ple 's/\015\012|\015|012/\012/g' *.pl
> > # Any -> Mac
> > perl -i.bak -ple 's/\015\012|\015|012/\015/g' *.pl
> > 
> > or teach camel the same trick
> 
> One of the main points of this is that some people will want the same files 
> to be used in more than one context, such as sharing code between Windows 
> and Unix perl over NFS, or sharing code between perl on Mac OS X and MacPerl 
> under Mac OS or Classic.  Right now, the only solution is to make copies, as 
> you suggest.
> 

Or use source filters:

package Filter::Any2Unix;
use Filter::Util::Call;
sub import {
if ($^O ne 'MacOS') {
filter_add(sub {
   my($status) = filter_read();
   if ($status > 0) {
   s/\015\012|\015|\012/\012/g;
   }
   }
  );
}
}

and then call the script with 

   perl -MFilter::Any2Unix script.pl

or embed "use Filter::Any2Unix" into the script.

Regards,
Slaven

-- 
Slaven Rezic - [EMAIL PROTECTED]

Tk-AppMaster: a perl/Tk module launcher designed for handhelds
http://tk-appmaster.sf.net

Re: unix or mac-style text files?

[Charles Albrecht]

On Monday, November 25, 2002, at 07:34  AM, Heather Madrone wrote:

Administrivia question:  I'm getting a lot of duplicate responsese
because the Reply-to on the list is set to sender.  On moderated
lists, this can be a good idea because the approval cycle causes
a lag between posting and mail reflection.

Is the Reply-to merely a hint that we should consider taking topics
offline, or is there some reason I should be leaving redundant addresses
in the headers?

More to the point, this list doesn't set Reply-To at all. There's a great 
deal of discussion at large about whether this is a good idea or not, but 
by-and-large, the From, To and Cc that come through are the same ones the 
Sender originally used.

At 12:21 PM +1100 11/25/2002, Ken Williams replied:

The extra copies are more for your convenience - I appreciate when people send them to 
me, because one copy goes to my list mailbox and the other goes to my inbox.  The one 
in my inbox will be read faster.

I wish there were a standard way to indicate in your own mail headers "I do/don't wish 
to receive a direct copy of replies to this message."  This can be done on usenet 
pretty effectively, but not really in email lists.

Well, on lists like this one that don't munge the Reply-To header, if you 
designate a Reply-To on the outgoing mail, it should remain intact all 
the way to the end recipients.

-Charles
 Euonymic Solutions
 [EMAIL PROTECTED]

Re: unix or mac-style text files?

[Ronald J Kimball]

On Mon, Nov 25, 2002 at 02:43:46AM +0900, Dan Kogai wrote:
> On Monday, Nov 25, 2002, at 01:05 Asia/Tokyo, Chris Nandor wrote:
> >The bottom line was that it'd be nice to have a PerlIO filter for perl
> >5.8.x, so that MacPerl can execute Unix and Windows text files, and 
> >Mac OS X
> >perl can execute Mac OS text files, etc.  Patches are surely welcome!  
> >:-)
> 
> One good question may be how to handle newlines in heretext, the only 
> part that really matters because that's the only exception to the fact 
> that newlines are nothing but whitespace from perl compiler's point of 
> view -- oops, shebang is another.

Newlines also serve as comment terminators; the perl compiler must
recognize either \012 or \015 as the end of a comment.

(I recall struggling to demonstrate some code during a Perl Mongers
meeting.  The script ran, but it didn't produce any output, nor did it
produce any error messages!  I finally figured out that perl on the OS X
machine was seeing the whole script as one long comment, starting with
#!/usr/bin/perl ...  :)

Ronald

Re: unix or mac-style text files?

[Michael Maibaum]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1


On Sunday, November 24, 2002, at 05:21 PM, Ken Williams wrote:



On Monday, November 25, 2002, at 07:34  AM, Heather Madrone wrote:


Administrivia question:  I'm getting a lot of duplicate responsese
because the Reply-to on the list is set to sender.  On moderated
lists, this can be a good idea because the approval cycle causes
a lag between posting and mail reflection.

Is the Reply-to merely a hint that we should consider taking topics
offline, or is there some reason I should be leaving redundant 
addresses
in the headers?

The extra copies are more for your convenience - I appreciate when 
people send them to me, because one copy goes to my list mailbox and 
the other goes to my inbox.  The one in my inbox will be read faster.

I wish there were a standard way to indicate in your own mail headers 
"I do/don't wish to receive a direct copy of replies to this message." 
 This can be done on usenet pretty effectively, but not really in 
email lists.



There is the Mail-Follow-Up-To header, unfortunately AFAIK mutt [1] is 
the only client to respect it, or provide methods to set it according 
to your preference.


FWIW, I object to reply to munging [2]

Michael

[1] http://www.mutt.org/doc/manual/manual-6.html#followup_to
[2] http://www.unicom.com/pw/reply-to-harmful.html
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.7 (Darwin)

iD8DBQE94Xxjilk3LUlIL0MRAvJ+AJ4iP8wsBGQL85PopAyF81kfT9S2HQCgvKdg
7ayC3QS0+aKFlFYOX0LcCkk=
=nqEg
-END PGP SIGNATURE-