Re: libapreq-1.1 Release Candidate 1

[David Wheeler]

Ken Williams <[EMAIL PROTECTED]> writes:


Promising, but several errors ensue:

[pe-242:~/Downloads/perl/httpd-apreq] ken% ./BUILD.sh
../BUILD.sh: command not found: libtoolize [4]
../BUILD.sh: command not found: aclocal [5]
FATAL ERROR: Autoconf version 2.52 or higher is required for this 
script
../BUILD.sh: command not found: automake [7]
[pe-242:~/Downloads/perl/httpd-apreq] ken% which autoconf
/usr/bin/autoconf
[pe-242:~/Downloads/perl/httpd-apreq] ken% autoconf --version
Autoconf version 2.13

Is it possible to backport the process to older autoconfs, or
are new features required?

I just successfully built it on Mac OS X 10.2.2 without problem. I 
first compiled and installed a clean Apache/mod_perl/mod_ssl build 
without the old apreq patch. Then I followed the instructions on 
http://www.apache.org/~joes/, and all went well. Bricolage (which 
requires libapreq) fired up and ran perfectly.

Now I have to go back and update my MacDevCenter article. Speaking of 
which -- Joe, can you put the apreq 1.0 patch and special release back 
on your server, at least until 1.1 is in final release? Quite a few 
people are reading my article and making use of it now. Here's my 
article:

  http://www.macdevcenter.com/pub/a/mac/2002/11/05/apache_osx.html


When do you expect final release?

Thanks,

David

--
David Wheeler AIM: dwTheory
[EMAIL PROTECTED] ICQ: 15726394
http://david.wheeler.net/  Yahoo!: dew7e
   Jabber: [EMAIL PROTECTED]

Re: Using perl to change the loginwindow.plist

[brian d foy]

In article , Greg Kapp
<[EMAIL PROTECTED]> wrote:

> Does anyone have any information about writing plists in general or 
> the loginwindow.plist specifically. I haven't seen anything that 
> makes the XML format clear, indicating which fields are required and 
> which are not.

Mac::PropertyList should be able to give you a Perl data structure
which represents this plist.

the only limitation with the module at the moment is that it cannot
handle more than two levels of nesting (although i want to change
that by using PropertyList Services when i get back to looking at
Carbon).

if you have any problems, let me know and i'll fix the module :)

Gtk broken on darwin

[Randal L. Schwartz]

Apparently, the Makefile expects that

  cc -c  -I/sw/include/gtk-1.2 -I/sw/include/glib-1.2 -I/sw/lib/glib/include 
-I/usr/X11R6/include  -I. -I./build -I/sw/include -pipe -fno-common -no-cpp-precomp 
-fno-strict-aliasing-DVERSION=\"0.7008\" -DXS_VERSION=\"0.7008\"  
"-I/opt/perl/snap/lib/5.8.0/darwin/CORE"  -DLAZY_LOAD -DPERL_POLLUTE 
-DGTK_HVER=0x01020a xs/GtkInvisible.c

will create "xs/GtkInvisible.o", but on darwin, it creates
"GtkInvisible.o", in the same directory as the cc command.

You should rewrite the Makefiles so that they either specify a -o
explictly, or so that they expect the .o in the current directory
(which breaks it for non-darwin, I suspect :).

I'm cc'ing the Perl-on-OSX list so that others can be aware as things
are being tested on and ported to OSX.

-- 
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<[EMAIL PROTECTED]> http://www.stonehenge.com/merlyn/>
Perl/Unix/security consulting, Technical writing, Comedy, etc. etc.
See PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!

Re: Using perl to change the loginwindow.plist

[Ken Williams]

Hi Greg,

Have a look at Mac::PropertyList :
   http://search.cpan.org/author/BDFOY/Mac-PropertyList-0.07/

I haven't used it yet myself, but I think I intend to for some 
OmniGraffle generation.  I might even get so ambitious as to 
create an as_graffle() method for GraphViz, but that's going to 
take some time. =)

 -Ken

On Thursday, December 12, 2002, at 10:20  AM, Greg Kapp wrote:


I'm trying to use perl to change plist files. My goal is to 
change the loginwindow.plist file of every user on the machine 
I administer. I want to change the plist to add a text file 
that will be opened apon login (this will serve as a sort-of 
message of the day file).

Does anyone have any information about writing plists in 
general or the loginwindow.plist specifically. I haven't seen 
anything that makes the XML format clear, indicating which 
fields are required and which are not.

Thanks-
Greg

Using perl to change the loginwindow.plist

[Greg Kapp]

I'm trying to use perl to change plist files. My goal is to change 
the loginwindow.plist file of every user on the machine I administer. 
I want to change the plist to add a text file that will be opened 
apon login (this will serve as a sort-of message of the day file).

Does anyone have any information about writing plists in general or 
the loginwindow.plist specifically. I haven't seen anything that 
makes the XML format clear, indicating which fields are required and 
which are not.

Thanks-
Greg

Re: closing and opening a browser

[Phil Dobbin]

On 11/12/02 14:58, "Chris Nandor" <[EMAIL PROTECTED]> wrote:

> In article <[EMAIL PROTECTED]>,
> [EMAIL PROTECTED] (Phil Dobbin) wrote:
> 
>> On 11/12/02 14:06, "Chris Nandor" <[EMAIL PROTECTED]> wrote:
>> 
>>> Mac::Carbon 0.02 is available on the CPAN, and on
>>> http://sf.net/projects/macperl/ (where there is also a binary installer, for
>>> those of you who have trouble building it, such as those on 10.1.x systems).
>> 
>> This is excellent news as I was having a torrid time trying to build
>> Mac::Carbon on 10.1.5/5.6.1.
> 
> Oh, I should note this will only work with perl 5.6, and installs into
> /Library/Perl/.  It should be fine with 5.6.1, since they are binary
> compatible, though you might need to move the extensions if you have a
> different location.  It probably won't work with 5.8.0.  In the end, if this
> is still necessary (hopefully not), we can get a more intelligent installer,
> with selectable location, with binaries for 5.8.0 too, etc.  For now it
> should suffice for most needs.

I ran the binary installer (10.1.5/5.6.1) and then used your script to kill
Mozilla and every thing was hunky-dory :-)

I should note that all my stuff for Perl is in the regular place:

/System/Library/Perl/darwin
/System/Library/Perl
/Library/Perl/darwin
/Library/Perl
/Library/Perl
/Network/Library/Perl/darwin
/Network/Library/Perl
/Network/Library/Perl

Good stuff...

Regards,

Phil.

Re: Apple Perl directory layout

[Sherm Pendley]

On Wednesday, December 11, 2002, at 08:56 AM, Chris Nandor wrote:


works well for me, and I find no significant maintenance issues as 
outlined
by Sherm.

I wasn't my intent to point out problems in the traditional layout; I 
was simply pointing out that the most common complaint about Apple's 
layout - the need to reinstall CPAN XS modules after an upgrade - isn't 
addressed by the traditional layout either. Using Apple's layout, you 
get incompatible CPAN modules in the common directory; using the 
traditional layout, you wind up with CPAN modules missing from a 
version-specific directory. The cure for both problems is identical - 
reinstall the affected modules.

The biggest benefit the traditional layout has over Apple's is the 
ability to install multiple versions that share the same installation 
prefix; I would argue that a) If multiple Perl versions are needed, a 
simpler and cleaner way to accomplish that is to use a different prefix 
for each, and that b) The vast majority of Apple's user base won't need 
multiple Perls anyway, leading Apple to choose to simplify the directory 
structure for the most common case.

It's trivially simple for an experienced admin to install multiple Perls 
under different prefixes - something that worked well even with older 
5.x versions that didn't use the current layout, and even with 4.x and 
earlier versions. With that in mind, it appears to me that the 
traditional layout is intended to solve a social engineering problem, 
not a technical one. It would seem that the *real* question that's 
addressed by the default layout is how to minimize the damage that's 
done when a less experienced admin simply types "./Configure; make; make 
install". The result, while sub-optimal, will at least allow both the 
old and new installations to continue functioning. It follows the Perl 
tradition of making the easy, default install even easier, without 
making the advanced multiple-prefix install any more difficult.

sherm--

If you listen to a UNIX shell, can you hear the C?

Re: closing and opening a browser

[Chris Nandor]

In article <[EMAIL PROTECTED]>,
 [EMAIL PROTECTED] (Phil Dobbin) wrote:

> On 11/12/02 14:06, "Chris Nandor" <[EMAIL PROTECTED]> wrote:
> 
> > Mac::Carbon 0.02 is available on the CPAN, and on
> > http://sf.net/projects/macperl/ (where there is also a binary installer, for
> > those of you who have trouble building it, such as those on 10.1.x systems).
> 
> This is excellent news as I was having a torrid time trying to build
> Mac::Carbon on 10.1.5/5.6.1.

Oh, I should note this will only work with perl 5.6, and installs into 
/Library/Perl/.  It should be fine with 5.6.1, since they are binary 
compatible, though you might need to move the extensions if you have a 
different location.  It probably won't work with 5.8.0.  In the end, if this 
is still necessary (hopefully not), we can get a more intelligent installer, 
with selectable location, with binaries for 5.8.0 too, etc.  For now it 
should suffice for most needs.

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

Re: closing and opening a browser

[Phil Dobbin]

On 11/12/02 14:06, "Chris Nandor" <[EMAIL PROTECTED]> wrote:

[big snip]

> Mac::Carbon 0.02 is available on the CPAN, and on
> http://sf.net/projects/macperl/ (where there is also a binary installer, for
> those of you who have trouble building it, such as those on 10.1.x systems).

This is excellent news as I was having a torrid time trying to build
Mac::Carbon on 10.1.5/5.6.1.

Many thanks,

Regards,

Phil.

Re: closing and opening a browser

[Chris Nandor]

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

> i like to know how to close a program like Internet Explorer from perl.
> the little script below seem to work for me, but i guess there must be
> a cleaner and more correct way.

Many have suggested AppleScript.  A pox upon their houses!  Use Mac::Carbon.  
I don't use MSIE, so I do it here with Mozilla.

   #!perl -wl
   use POSIX 'SIGTERM';
   use Mac::Processes;
   while (my($psn, $psi) = each %Process) {
  next unless $psi->processName eq 'Mozilla'; # 'Internet Explorer' ?
  kill SIGTERM, GetProcessPID($psn);
  last;
   }

$psn (and $psi->processNumber) contain the Mac OS "process serial number".  
GetProcessPID, new to Mac::Carbon 0.02, maps that to a POSIX PID.  Then kill 
SIGTERM, well, kills it.


Mac::Carbon 0.02 is available on the CPAN, and on 
http://sf.net/projects/macperl/ (where there is also a binary installer, for 
those of you who have trouble building it, such as those on 10.1.x systems).

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

Re: Apple Perl directory layout

[Chris Nandor]

In article ,
 [EMAIL PROTECTED] (Dan Sugalski) wrote:

> At 1:42 AM -0500 12/10/02, Sherm Pendley wrote:
> >What's more, unless "100% pure Perl" modules were stored in a 
> >version-agnostic location, they would then need to be reinstalled as 
> >well, whereas under the current layout, they can continue to be used 
> >as-is.
> 
> FWIW, they generally are.

I don't believe this is true.  Usually they are installed in an 
*architecture*-agnostic location.

   [pudge@yaz pudge]$ perl -e 'printf "%s, %vd\n", $^O, $^V'
   linux, 5.8.0

   [pudge@yaz pudge]$ pmpath MP3::Info
   /usr/local/lib/perl5/site_perl/5.6.1/MP3/Info.pm

Then when you configure perl, you can choose to add older version 
directories:

   [pudge@yaz pudge]$ perl -MConfig -le 'print $Config{inc_version_list}'
   5.6.1 5.6.0 5.005

But this won't use the architecture-specific extensions under 
site_perl/$version/$arch, only the pure-perl ones found in 
site_perl/$version.

   [pudge@yaz pudge]$ perl -le 'print join "\n", @INC'
   /usr/local/lib/perl5/5.8.0/i686-linux
   /usr/local/lib/perl5/5.8.0
   /usr/local/lib/perl5/site_perl/5.8.0/i686-linux
   /usr/local/lib/perl5/site_perl/5.8.0
   /usr/local/lib/perl5/site_perl/5.6.1
   /usr/local/lib/perl5/site_perl/5.6.0
   /usr/local/lib/perl5/site_perl/5.005
   /usr/local/lib/perl5/site_perl
   .

So I still have access to my old pure perl modules with perl 5.8.0, and my 
old versions of perl still have access to their architecture-specific 
extensions, and I need to install new versions of those for perl 5.8.0.  The 
only problem I encounter here is if an old version of perl needs a new 
version of a module (architecture-specific or not) that has already been 
installed for perl 5.8.0; I need to install it back for each old version 
that needs it.  But since I rarely use the old versions, this is not a 
significant problem.

Everyone's entitiled to their opinion, especially when something is so tied 
to personal preference as this is.  But the default system as shown above 
works well for me, and I find no significant maintenance issues as outlined 
by Sherm.

However, I do find little fault with how Apple handles it, as I just prefer 
to install my own perl.  This is what I've learned to do on Debian Linux 
too, as installing your own perl over the system perl can cause havoc with 
apt-get etc.  There are certainly ways around it, but it's easier just to 
install into /usr/local/.

I think the biggest problem with how Apple does it is that it is 
nonstandard.  Every other platform does it with versions, that I am aware of 
(well, except for maybe MacPerl ).

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