Re: locale in carbon emacs (was: OS X Installed numbers)
On Tuesday, November 19, 2002, at 01:17 AM, Heather Madrone wrote: I also got the developer tools unpacked, so the Darwin shell is starting to look a bit more like home. One thing about the Shells under OS X -- you have neither csh nor sh! csh is a link to tcsh and sh a link to bash. zsh is also available if you like the Korn shell. emacs is gnu 21.1.1. There is also a copy of xemacs that runs if you like that version of emacs. And you can use the `C-x RET f' (`set-buffer-file-coding-system') to flip back and forth between Mac endings and unix endings for your scripts, if you want to edit them with text exit or something else. And if you are a real emacs fan... visti: From: http://beebo.org/fluff/macstuff/ Want emacs-like keybindings in all Cocoa apps? Put DefaultKeyBinding.dict in ~/Library/KeyBindings. It provides a lot of the missing Alt key bindings, as well as re-binding Ctrl-a, etc. 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]
mod_ssl and libdbm
Hi All, I've been using mod_ssl with Apache 1.3.x on Mac OS X for a while now, and it works great. I've had to use gdbm to get it to compile, but that was okay with me. Now, however, I'm writing an article about this, and want to try to eliminate the gdbm dependency in the name of simplicity. I know it can be done, because Apple includes mod_ssl with their Apache. Furthermore, via their bug report system, they tell me that libdm is in the Mac OS X system library, libSystem. But mod_ssl's configure has never been able to find it. -lm and -ldbm both fail. So I tried --enable-rule=SSL_SDBM, and that got Apache/mod_ssl to compile nicely. Yay! But then, when I tried to connect to the SSL port, Apache segfaulted! [Fri Nov 15 12:29:03 2002] [notice] child pid 26629 exit signal Segmentation fault (11) So I'm stuck and could use some help from those more experienced with compiling on Mac OS X. Does anyone know how to a) get Apache's configure to find libdbm in libSystem and use it? Or b) have any idea why Apache/mod_ssl might be segfaulting when using SDBM? TIA! David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: mod_ssl and libdbm
David [macjerry:/usr/lib]$ otool -vM libSystem.dylib | grep module_name | grep db module_name = ndbm.So module_name = db.So module_name = aliasdb.o module_name = printerdb.o Looks like something is there :) Regrettably I don't understand shared library syntax. Ie how to specify it on the link line. --Jerry [ Hi All, I've been using mod_ssl with Apache 1.3.x on Mac OS X for a while now, and it works great. I've had to use gdbm to get it to compile, but that was okay with me. Now, however, I'm writing an article about this, and want to try to eliminate the gdbm dependency in the name of simplicity. I know it can be done, because Apple includes mod_ssl with their Apache. Furthermore, via their bug report system, they tell me that libdm is in the Mac OS X system library, libSystem. But mod_ssl's configure has never been able to find it. -lm and -ldbm both fail. So I tried --enable-rule=SSL_SDBM, and that got Apache/mod_ssl to compile nicely. Yay! But then, when I tried to connect to the SSL port, Apache segfaulted! [Fri Nov 15 12:29:03 2002] [notice] child pid 26629 exit signal Segmentation fault (11) So I'm stuck and could use some help from those more experienced with compiling on Mac OS X. Does anyone know how to a) get Apache's configure to find libdbm in libSystem and use it? Or b) have any idea why Apache/mod_ssl might be segfaulting when using SDBM? TIA! David
Re: mod_ssl and libdbm
On Wednesday, November 20, 2002, at 08:06 AM, David Wheeler wrote: Hi All, I've been using mod_ssl with Apache 1.3.x on Mac OS X for a while now, and it works great. I've had to use gdbm to get it to compile, but that was okay with me. Now, however, I'm writing an article about this, and want to try to eliminate the gdbm dependency in the name of simplicity. I know it can be done, because Apple includes mod_ssl with their Apache. Furthermore, via their bug report system, they tell me that libdm is in the Mac OS X system library, libSystem. But mod_ssl's configure has never been able to find it. -lm and -ldbm both fail. Maybe what's required is just to keep mod_ssl from complaining about -ldbm (i.e. not search for it), and link against libSystem? -lm is always supposed to be a no-op when linking - see the bottom of http://fink.sourceforge.net/doc/porting/basics.php for the reason. -Ken
Re: mod_ssl and libdbm
On Tuesday, November 19, 2002, at 04:06 PM, Ken Williams wrote: Maybe what's required is just to keep mod_ssl from complaining about -ldbm (i.e. not search for it), and link against libSystem? According to this document from Apple (entitled ]Inside Mac OS X: UNIX Porting Guide), libSystem is *always* linked in. So I *really* don't understand why mod_ssl doesn't see it when its configure calls cc. http://developer.apple.com/techpubs/macosx/Darwin/PortingUNIX/ PortingUNIXToOSX.pdf -lm is always supposed to be a no-op when linking - see the bottom of http://fink.sourceforge.net/doc/porting/basics.php for the reason. Yes, the Apple porting guide says that, too, although it can't hurt. Regards, Dvid -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: mod_ssl and libdbm
On Tuesday, November 19, 2002, at 03:35 PM, Jerry LeVan wrote: [macjerry:/usr/lib]$ otool -vM libSystem.dylib | grep module_name | grep db module_name = ndbm.So module_name = db.So module_name = aliasdb.o module_name = printerdb.o Looks like something is there :) Regrettably I don't understand shared library syntax. Ie how to specify it on the link line. It should just be there...but it's not. I'm sure I must be missing something simple... Thanks, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://david.wheeler.net/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED]
Re: mod_ssl and libdbm
On Wednesday, November 20, 2002, at 10:50 AM, David Wheeler wrote: On Tuesday, November 19, 2002, at 04:06 PM, Ken Williams wrote: Maybe what's required is just to keep mod_ssl from complaining about -ldbm (i.e. not search for it), and link against libSystem? According to this document from Apple (entitled ]Inside Mac OS X: UNIX Porting Guide), libSystem is *always* linked in. So I *really* don't understand why mod_ssl doesn't see it when its configure calls cc. Probably because it's actually trying to use a flag '-ldbm', and no matching files are found in /usr/lib/ (or anywhere else). One workaround would probably be to make a symlink: % cd /usr/lib % ln -s libSystem.dylib libdbm.dylib Or you could do the same thing in a private directory and add that directory to the search path. That's why '-lm' works as a no-op, anyway. -Ken
unix or mac-style text files?
I've already encountered a few text file anomalies on OS X. Most GUI applications seem to default to Mac-style text files (linefeeds only), but shell programs such as vi do not handle Mac-style text files gracefully. Is perl on the Mac going to care whether source files are Mac-style or Unix-style? Is it going to have difficulty reading and operating on either kind of file? What kind of text files will it write? Thanks in advance for any illumination. -hmm [EMAIL PROTECTED]
Re: unix or mac-style text files?
There is some discussion of this issue in the docs, check out: perldoc perlport And page through to a section called Newlines... I guess the real question I have is does Perl on OS X qualify as MacPerl or Unix perl ... I defer to the mac os x experts, but would guess Unix perl. http://danconia.org Heather Madrone wrote: I've already encountered a few text file anomalies on OS X. Most GUI applications seem to default to Mac-style text files (linefeeds only), but shell programs such as vi do not handle Mac-style text files gracefully. Is perl on the Mac going to care whether source files are Mac-style or Unix-style? Is it going to have difficulty reading and operating on either kind of file? What kind of text files will it write? Thanks in advance for any illumination. -hmm [EMAIL PROTECTED]
Re: unix or mac-style text files?
On Wednesday, November 20, 2002, at 01:45 AM, Wiggins d'Anconia wrote: Heather Madrone wrote: I've already encountered a few text file anomalies on OS X. Most GUI applications seem to default to Mac-style text files (linefeeds only), but shell programs such as vi do not handle Mac-style text files gracefully. Is perl on the Mac going to care whether source files are Mac-style or Unix-style? Is it going to have difficulty reading and operating on either kind of file? What kind of text files will it write? Thanks in advance for any illumination. -hmm [EMAIL PROTECTED] There is some discussion of this issue in the docs, check out: perldoc perlport And page through to a section called Newlines... I guess the real question I have is does Perl on OS X qualify as MacPerl or Unix perl ... I defer to the mac os x experts, but would guess Unix perl. Yes, Unix perl. Of course, perl of any sort can read or write text (or non-text) files of any sort. It's just that the default line endings differ on different platforms, in the interest of convenience. -Ken
Re: mod_ssl and libdbm
Hmm - none of those are 'dbm', though. David, can you show/quote the page that claimed that dbm was a part of libSystem? -Ken On Wednesday, November 20, 2002, at 10:35 AM, Jerry LeVan wrote: David [macjerry:/usr/lib]$ otool -vM libSystem.dylib | grep module_name | grep db module_name = ndbm.So module_name = db.So module_name = aliasdb.o module_name = printerdb.o Looks like something is there :) Regrettably I don't understand shared library syntax. Ie how to specify it on the link line. --Jerry [ Hi All, I've been using mod_ssl with Apache 1.3.x on Mac OS X for a while now, and it works great. I've had to use gdbm to get it to compile, but that was okay with me. Now, however, I'm writing an article about this, and want to try to eliminate the gdbm dependency in the name of simplicity. I know it can be done, because Apple includes mod_ssl with their Apache. Furthermore, via their bug report system, they tell me that libdm is in the Mac OS X system library, libSystem. But mod_ssl's configure has never been able to find it. -lm and -ldbm both fail. So I tried --enable-rule=SSL_SDBM, and that got Apache/mod_ssl to compile nicely. Yay! But then, when I tried to connect to the SSL port, Apache segfaulted! [Fri Nov 15 12:29:03 2002] [notice] child pid 26629 exit signal Segmentation fault (11) So I'm stuck and could use some help from those more experienced with compiling on Mac OS X. Does anyone know how to a) get Apache's configure to find libdbm in libSystem and use it? Or b) have any idea why Apache/mod_ssl might be segfaulting when using SDBM? TIA! David
Re: mod_ssl and libdbm
On Wednesday, November 20, 2002, at 10:50 AM, David Wheeler wrote: On Tuesday, November 19, 2002, at 04:06 PM, Ken Williams wrote: Maybe what's required is just to keep mod_ssl from complaining about -ldbm (i.e. not search for it), and link against libSystem? According to this document from Apple (entitled ]Inside Mac OS X: UNIX Porting Guide), libSystem is *always* linked in. So I *really* don't understand why mod_ssl doesn't see it when its configure calls cc. Another option: update src/Configure (in the apache distribution) to give a better hint for darwin platform, something like: DBM_LIB=-lSystem This is supposing that the dbm library is indeed part of libSystem, which Jerry's message makes me doubt. -Ken
Re: unix or mac-style text files?
At 16:30 -0800 11/19/02, Heather Madrone wrote: I've already encountered a few text file anomalies on OS X. Most GUI applications seem to default to Mac-style text files (linefeeds only), I think that's returns only for Mac style. Don't be fooled by MPW's and perhaps MacPerl's redefinition of \n and \r in the reverse sense from the rest of the world. I recommend use of linefeed only - ASCII 10 - for all future work in perl. BBEdit has no trouble with that. If you're even a little bit involved with moving perl scripts to some UNIX server where your web pages are based you'll find that your scripts move effortlessly with any kind of file transfer. OT The internet norm is a linefeed-return pair which is really strange because in the days of teletype one sent the return first because it took longer than the linefeed and one needed a few null characters to be sure the operation completed at 100 baud. Of course you had the option of sending the return only and repeating the line to get a bold appearance. If you don't believe that look at a UNIX man page with repeated characters and backspaces. /OT -- -- There are 10 kinds of people: those who understand binary, and those who don't --
Re: unix or mac-style text files?
At 05:55 PM 11/19/2002 -0700, Doug McNutt wrote: At 16:30 -0800 11/19/02, Heather Madrone wrote: I've already encountered a few text file anomalies on OS X. Most GUI applications seem to default to Mac-style text files (linefeeds only), I think that's returns only for Mac style. Don't be fooled by MPW's and perhaps MacPerl's redefinition of \n and \r in the reverse sense from the rest of the world. Yes. ASCII 13. \015. ^M. I recommend use of linefeed only - ASCII 10 - for all future work in perl. BBEdit has no trouble with that. If you're even a little bit involved with moving perl scripts to some UNIX server where your web pages are based you'll find that your scripts move effortlessly with any kind of file transfer. Makes sense to me. The input files are more problematic. I don't necessarily know whether they will be created on the Mac side of the house or the Unix side of the house. It sounds like I'm going to have to replace $FileHandle-getline with something that can handle either kind of line break. -- There are 10 kinds of people: those who understand binary, and those who don't -- This is one of my favorite jokes. Heather Madrone ([EMAIL PROTECTED]) http://www.madrone.com Reality: deeper than I dreamed.
Re: unix or mac-style text files?
At 16:30 -0800 19/11/02, Heather Madrone wrote:
I've already encountered a few text file anomalies on OS X. Most GUI
applications seem to default to Mac-style text files (linefeeds
only), but shell programs such as vi do not handle Mac-style text
files gracefully.
Is perl on the Mac going to care whether source files are Mac-style
or Unix-style?
Is it going to have difficulty reading and operating on either kind
of file? What kind of text files will it write?
Thanks in advance for any illumination.
Definitely read the perlport section of the documentation at:
http://www.perldoc.com/perl5.6.1/pod/perlport.html
Traditionally on Mac OS, line endings have been carriage return (cr) only.
Unix uses just linefeed line (lf) endings.
DOS/Windows uses carriage-linefeed (crlf) line endings.
Under Mac OS X, it is quite schizophrenic - some applications with
handle only Mac line endings, some applications handle only Unix line
endings, some applications will handle Unix or Mac (or even DOS) line
endings.
Ignoring MacPerl (running under Mac OS X), and looking only at Mac OS
X's /usr/bin/perl (or wherever you've installed perl), which is a
Unix perl, not a Mac perl, we have:
Perl source files must have Unix line endings (lf only). If the
source file has Mac line endings, then it will usually run and do
absolutely nothing (if you run it as perl script.pl, or it will
complain script.pl: Command not found. if you run it as
../script.pl. This is because the first line is #!/usr/bin/perl - but
after that the cr is not a line ending and so the entire source file
appears as a single line. If you run it with perl, then it will
ignore the entire file as a comment. If you run it yourself, then it
will try to use the entire file as a command and wont be able to find
/usr/bin/perlcrcruse (for example) as a command to run.
By default, Perl will read and write unix line ending files. You can
change the input separator with $/ = \r for Mac line endings,
\r\n for DOS line ending (and back to \n for Unix, although
saving and restoring is better practice) . You can change the output
by just printing the appropriate line ending. In this case, a nice
practice might be to do:
our $eol = \015\012; # Windows line ending
print First Line$eol;
My suggestion for Mac OS X users is to switch to using Unix line
endings as soon as possible, and wherever possible support reading
files with any line ending. One simple thing I almost always do is:
while () {
s/\015?\012$//; # instead of chomp
}
Yes, chomp is probably faster, but most of the time it makes no
difference. Not that the above code will not help you with Mac files
because the will read the entire file in one go :-(
It's really unfortunate that there is no special case value for $/
(like perhaps) that handles \015\012|\015|\012 as a line ending.
There is talk of making $/ a regex which would allow that, but that's
huge overkill just to handle this one particular very special case.
An alternative is to read the entire file in (undef $/) and then split it:
local( $/ ) = undef;
my $file = ; # read in entire file
my @lines = split( /\015\012|\015|\012/, $file );
foreach my $line (@lines) {
print '$line'\n;
}
Which is ok, but not great for big files.
Enjoy,
Peter.
--
http://www.interarchy.com/ http://download.interarchy.com/
Re: unix or mac-style text files?
An alternative is to read the entire file in (undef $/) and then split
it:
My suggestion is to put some code like this in your script:
local $/ = get_line_ending($fh);
sub get_line_ending {
my $fh = shift;
my $char;
while (read $fh, $char, 1) {
if ($char eq \n) {
seek $fh, 0, 0;
return \n;
} elsif ($char eq \r) {
if (read $fh, $char, 1 and $char eq \n) {
seek $fh, 0, 0;
return \r\n;
} else {
seek $fh, 0, 0;
return \r;
}
}
}
## what, no line ending?
## return a reasonable default
seek $fh, 0, 0;
return \n;
}
This, of course assumes that you don't have some oddball case
where you have \r's in a unix file or something like that, but
if you're dealing with text files (which is the only place where
line endings should matter), that's unlikely.
Suggestions for the above code:
Move the sub into a module.
Put a byte counter in, so that you're not reading through a 5 Gig
file looking for a line ending.
I assume it's more efficient to read small chunks of bytes rather
than byte by byte. For most text files this shouldn't matter, but
you may want to alter the reads and also the comparisons if you care.
Re: unix or mac-style text files?
At 19:01 -0800 19/11/02, gene wrote:
An alternative is to read the entire file in (undef $/) and then split it:
My suggestion is to put some code like this in your script:
It's a good solution. Probably for files less than a few hundred k
it makes no difference (since you'll need to read the entire file
anyway, until the memory usage of storing the whole thing becomes an
issue it wont affect anything).
For portability, you should use \012 and \015 explicitly, except for
the final default value which should be \n. Here is the code, with
the fail counter added to avoid it reading forever in a file with no
line endings (not that it is likely to help anyway since you'll
presumably follow this up with reading a line...)
# Usage: local $/ = get_line_ending($fh);
# By gene
sub get_line_ending {
my ($fh) = @_;
my $failcount = 33000;
my $char;
while (read $fh, $char, 1 and $failcount-- 0) {
if ($char eq \012) {
seek $fh, 0, 0;
return \012;
} elsif ($char eq \015) {
if (read $fh, $char, 1 and $char eq \012) {
seek $fh, 0, 0;
return \015\012;
} else {
seek $fh, 0, 0;
return \015;
}
}
}
## what, no line ending?
## return a reasonable default
seek $fh, 0, 0;
return \n;
}
Suggestions for the above code:
Move the sub into a module.
I have ;-). whether it's worth publishing a CPAN module, I don't
know. Perhaps adding it to some existing module?
I assume it's more efficient to read small chunks of bytes rather
than byte by byte. For most text files this shouldn't matter, but
you may want to alter the reads and also the comparisons if you care.
It would require some timing to figure out if reading a block of
characters would be better, possibly something like:
read 256 characters, look for the first \012 or \015 and see what's
up (being careful not to accept a \015 as the 256th character as an
answer), then try again with a larger read
would be more efficient, but then again, possibly not. It would
depend on a lot of things and might vary from OS to OS, so it's
probably not worth worrying too much about.
Enjoy,
Peter.
--
http://www.interarchy.com/ http://download.interarchy.com/
BOT: Installers
All, What is the best method you use to install modules not hosted on CPAN but need to be available to a group of people who are not too familiar with Perl per se. I have some distributions that I want to be able for the user to basically type 'installer.pl' or 2x-click on it and it use CPAN to install all the requisite modules. Some of these modules will be from the CPAN respos, otherwise will be included at tar.gz files. I looked at CPAN::DistroBuilder...and it seems like a good idea. However, I have not figured out to force CPAN to look at file URLs. Ideally, I would like to keep a local copy of the CPAN modules and just use this for the people. We are behind a firewall, and i want to avoid anything like configuring CPAN for themI just wanna dumb it down to the point that they gotta think zippo (or as near as possible) for installation. Yes, I have read the docs and googled. But I can only find allusions to what I want to do, no concrete examples Thanks in advance, Ward
