Re: Darwin darwin or darwin6.0
Peter == Peter N Lewis [EMAIL PROTECTED] writes: Peter which in turn is stored in Config.pm, typically somewhere like Peter /Library/Perl/darwin/Config.pm or System/Library/Perl/darwin/Config.pm Peter this can be handy if you need to correct any settings (such as Peter library or include paths). Danger danger danger! You can't just *edit* that file, since those are *reflections* of how things were noted at compile time. Many things have those values *locked in*. The purpose of Config.pm is just to give you after-market observations of the data. DO NOT EDIT Config.pm Rebuild Perl instead. It's Free. It's Easy. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 [EMAIL PROTECTED] URL: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!
/usr/bin or /sw/bin?
I've been happily using Fink to install some of my software, and I'm considering whether I'd be better off putting Perl in /sw/bin instead of /usr/bin. Any thoughts, pro or con? Thanks, John A see me fulminate at http://www.jzip.org/
Re: /usr/bin or /sw/bin?
At 11:43 AM -0500 11/18/02, John Adams wrote: I've been happily using Fink to install some of my software, and I'm considering whether I'd be better off putting Perl in /sw/bin instead of /usr/bin. Any thoughts, pro or con? I wouldn't do either. Leave /sw for fink stuff, and /usr/bin for the system perl. Put the one you're building into /usr/local/bin instead, so it doesn't conflict with anything. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: /usr/bin or /sw/bin?
I leave all fink stuff in /sw/bin I put all my other installed stuff under /usr/local whenever possible I always try and leave /usr/bin alone. My path is set to something like ... /usr/local/bin:/sw/bin:/usr/bin The principle being to avoid any possibility of collisions between my stuff, fink's stuff, and system stuff ... On Monday, November 18, 2002, at 04:43 PM, John Adams wrote: I've been happily using Fink to install some of my software, and I'm considering whether I'd be better off putting Perl in /sw/bin instead of /usr/bin. Any thoughts, pro or con? Thanks, John A see me fulminate at http://www.jzip.org/
Re: Perl Package Problem
On Sunday, Nov 17, 2002, at 11:20 US/Pacific, Vic Norton wrote: [..] The VTN::Utilities and VTN::Sppd packages are here /Library/Perl/darwin/VTN% ls -l total 56 -rwxr--r-- 1 vicnorto admin 5427 Nov 2 16:26 Sorts.pm* -rwxr--r-- 1 vicnorto admin 2116 Nov 17 12:28 Sppd.pm* -rwxr--r-- 1 vicnorto admin 2886 Nov 7 07:13 Utilities.pm* along with another package called VTN::Sorts. Utilities and Sorts work. Sppd does not. I can't figure out why not. [..] I think the first part is so how DID you install this VTN::* section? since it appears that you have those parts in the 'architecture dependent' section - without apparenetly building any actual 'architecturally dependent parts'. allow me to illustrate if I can. we find the MD5.pm module in /Library/Perl/darwin/Digest because over in /Library/Perl/darwin/auto/Digest/MD5 we find the 'bundle' files: [jeeves: 27:] ls -ltra total 168 -r-xr-xr-x 1 root admin 78844 May 18 2002 MD5.bundle -r--r--r-- 1 root admin 0 May 18 2002 MD5.bs -rw-r--r-- 1 root admin161 May 18 2002 .packlist drwxr-xr-x 3 root admin102 May 18 2002 .. drwxr-xr-x 5 root admin170 May 18 2002 . [jeeves: 28:] file *.bundle MD5.bundle: Mach-O bundle ppc [jeeves: 30:] But Pure Perl Modules belong over the wall treed down /Library/Perl/ in your case /Library/Perl/VTN/ That way Perl does not try to resolve for the 'bundle' that would need to be loaded You will most likely want to take a look at perldoc h2xs as a good place to start the how to build installable Modules since it is HIGHLY RECOMMENDED in perldoc perlmod etc, etc, etc... HTH ciao drieux
Re: Darwin darwin or darwin6.0
On Sunday, Nov 17, 2002, at 20:22 US/Pacific, Peter N Lewis wrote:
At 11:39 -0800 16/11/02, drieux wrote:
[jeeves: 1:] perl -MConfig -e 'print $Config{osname} \n; '
As for how this gets set - it gets set when your version of perl
is built for that specific OS.
which in turn is stored in Config.pm, typically somewhere like
/Library/Perl/darwin/Config.pm or System/Library/Perl/darwin/Config.pm
this can be handy if you need to correct any settings (such as
library or include paths).
Randell has already done the PANIC MOMENT about not
dwiddling the Config.pm file directly.
Remember that the token $^O - the 'osname' that this version
of perl is built with can be directly accessed IN perl itself
without the need for the Config.pm that is dynamically built
when you build perl itself... so dithering the Config.pm will
have the grotesque ugly of 'psycho-version-skew' with the
Config.pm handing out one set of values and perl itself living
in a different world.
YOU DO NOT WANT THAT EXPERIENCE. { unless you are way bored... 8-)}
there are three perfectly SANE ways to manage 'correct library settings'
a) use lib $ENV{HOME}/lib/perl;
b) PERL5LIB - the environmental variable
c) rebuild your perl code itself to include the appropriate additional
paths
the later seems 'odd' to some - but if you are doing things like
wanting to allow the vendor to supply their updates to perl stuff
in their 'happy place' - yet want to be 'old fashion' about always
installing the CPAN stuff, et al, in /usr/local, then you wind up
opting in for things like:
{ from the perl -V output }
Characteristics of this binary (from libperl):
Compile-time options: USE_64_BIT_INT USE_LARGE_FILES
Built under solaris
Compiled at Aug 25 2002 12:19:33
@INC:
/usr/local/lib/perl5/5.6.1/sun4-solaris-64int
/usr/local/lib/perl5/5.6.1
/usr/local/lib/perl5/site_perl/5.6.1/sun4-solaris-64int
/usr/local/lib/perl5/site_perl/5.6.1
/usr/local/lib/perl5/site_perl
/usr/local/lib/perl5/vendor_perl/5.6.1/sun4-solaris-64int
/usr/local/lib/perl5/vendor_perl/5.6.1
/usr/local/lib/perl5/vendor_perl
/usr/perl5/5.6.1/lib/sun4-solaris-64int
/usr/perl5/5.6.1/lib
/usr/perl5/site_perl/5.6.1/sun4-solaris-64int
/usr/perl5/site_perl/5.6.1
/usr/perl5/site_perl
/usr/perl5/vendor_perl/5.6.1/sun4-solaris-64int
/usr/perl5/vendor_perl/5.6.1
/usr/perl5/vendor_perl
.
because you needed to rebuild it anyway to throw the 'USE_LARGE_FILES'
flag any way unlike say the darwin version that apple provided that
just did the Right Thing the first time anyway...
The above pattern also allows one to differenciate in their Makefile.PL
whether they can detect the sitelib is the only option or if set, can
we install into installvendorlib . as well as where to put the
architecture dependent components, et al
ciao
drieux
---
Re: /usr/bin or /sw/bin?
On Monday, Nov 18, 2002, at 08:43 US/Pacific, John Adams wrote:
I've been happily using Fink to install some of my software, and I'm
considering whether I'd be better off putting Perl in /sw/bin instead
of
/usr/bin.
Any thoughts, pro or con?
there are several basic arguments here that need to be addressed.
martin has pointed towards a 'name space solution' by having
your PATH environmental set to include the three basic sets
/usr/local/bin:/sw/bin:/usr/bin
which addresses a part of keeping the three possiblely different
'perl executables' - and their associated 'configurations' in three
different name spaces. This strategy forgets that PATH is a first
come first served solution. So if your scripts/code call out a
specific perl
#!/usr/bin/perl
#!/usr/local/bin/perl
#!/sw/bin
you are mostly sorta safe, since they will pick 'the right one'
for you - sorta, kinda Remember that it is not only the 'perl
executable' itself that gets delivered, there are things like 'perldoc'
and other applications that have a 'sense of presence'. Nothing more
fun that typing
perldoc something
and finding that the version of perldoc in /usr/local/bin is not
the same as in /sw/bin from /usr/bin ... Which allows one to see
things related to the 'perl' that was built in each...
The most aggressive solution I have seen in this space has been to
expressly define which perl you REALLY MEANT.
#!/usr/bin/perl5.6.0
#!/usr/perl/perl5.8.0
since /usr/bin/perl and /usr/local/bin/perl are really only links
to the 'executable' /usr/bin/perl.vers - At one time I had
implementations of perl back to perl4.??? - since when you
build a new perl - it installs the new 'numbered' version and
then links to it as /usr/.../perl
All of this avoids the problem of where did you actually go and
stuff which sets of libraries for what
To understand a part of why the Fink Folks have gone to /sw as
their name space - it helps to understand the 'build time linkage
problem'.
{ WARNING: this gets a bit technical for those accustom to pure perl
modules,
but bear with me... }
The reason that there is an 'architecture dependent' section of the @INC
is for those modules that have 'bundles' { aka: dynamically loadable
libraries,
shared objects, etc... } created from non-perl code ( C, C++,
assembler, ... )
that is actually compiled into a run time linkable library that the pure
perl section knows how to access . ( cf perldoc perlxs, et al )
This is simple enough when you build your 'dynamically loadable library'
with everything that it needs already resolved internally. But gets to
be more complex IF your code expects that some of it will be resolved
at run time from other 'dynamically loadable libraries'. Allow me
to illustrate: my Dtk::Happy perl module will rest on top of some
c-code that has open symbols since it expects to find lib_dtk_smile.$EXT
and lib_dtk_mania.$EXT at run time.
EITHER
a) I have to contaminate the system LD_LIBRARY_PATH so
that all dynamically loadable modules will get to see my
two libraries as well.
b) put my libraries some place special
b1: oblige the user to update their LD_LIBRARY_PATH/LD_RUN_PATH
environmental variables to find that happy place
b2: build my perl module with the '-R' flag that inserts that
it will search say /sw/lib/dtk as the first place
at run time.
It's this 'b2' option that makes things simpler since the installer
now just WHACKS in the two external bundles into /sw/lib/dtk and
the Happy.bundle down in
/Library/System/darwin/Dtk
or say:
/sw/lib/perl5/darwin/Dtk
will be content to resolve all open symbols at run time...
This way I can ship out the actually compiled stuff for folks,
and they can get it put into place where it will all belong and
work and play well. The end user does not have to actually install
a compiler on their machine from the Developer Toolkit, and all
is wonderful with the world.
{ except of course that I have to have the source code for
lib_dtk_smile.$EXT and lib_dtk_mania.$EXT with all of the fun
filled
#ifdef _MAC_OS_STUFF
.
#
#endif
for all the bits and bobs uniq to each OS... but I need only
maintain the dynamically loadable library and NOT have to change
any of the 'perl code' }
I take us down this side of the 'software maintenance side' of the
problem - since if folks understand this part of the problem - they
will perchance better understand why it may be simpler to 'rebuild
their perl' to include the /sw perl sections as a default part of
the @INC ... or not...
So the 'correct' answer is
how much time do you have to do which types of maintenance?
ciao
drieux
---
Re: /usr/bin or /sw/bin?
On Monday, November 18, 2002, at 07:56 PM, drieux wrote: there are several basic arguments here that need to be addressed. martin has pointed towards a 'name space solution' by having your PATH environmental set to include the three basic sets /usr/local/bin:/sw/bin:/usr/bin I should add, in justification of the PATH approach, that there is a rationale behind the above ordering. If I've installed my own (i.e. I built it, usually), or fink's version something, then it was because I definitely wanted to use that version of, e.g. perl, and I'll install any libraries where that version can locate them. I might not hate the stock perl enough to blow it away, but having it obscured by the PATH variable is exactly what I want. Of course, there is an issue with the instinctive #!/usr/bin/perl, with this approache, and I've been bitten by that once or twice. If this really niggles you, move /usr/bin/perl aside (e.g. to /usr/bin/perl.stock or /usr/bin/perl.orig), and put in a synlink to your preferred binary.
Re: /usr/bin or /sw/bin?
On Monday, Nov 18, 2002, at 12:22 US/Pacific, Martin Redington wrote:
[..]
I might not hate the stock perl enough to blow it away, but having it
obscured by the PATH variable is exactly what I want.
Of course, there is an issue with the instinctive #!/usr/bin/perl,
with this approache, and I've been bitten by that once or twice.
[..]
p0: oh we do so agree, on both
a) that 'build and install our own' and do not always want to blow the
others away
{ I have the Sun version of their perl built stuff as is where they
installed it,
I just do not look for it, or really care - but I do include the
places
where they add to the @INC - so that I can use their OS specific
tricks.
this I fixed by rebuilding my version of perl...
note:
vladimir: 518:] head `which kstat`
#!/usr/perl5/bin/perl
#
# Copyright (c) 1999, 2001 by Sun Microsystems, Inc.
# All rights reserved.
#
#ident @(#)kstat.pl 1.3 01/11/09 SMI
require 5.6.1;
use strict;
use warnings;
vladimir: 519:]
They at least did their installation out of the way and call out
for themselves what they expect... a strategy some may want to adopt,
avoid, improve upon }
b) as well as the usual number of times that things were 'feature
rich'...
{ nothing against Old Guys - but some folks 'do not get perl' - and
so after myFascistHouseMate bollocked the process of how to build
and install it, I got tagged with 'defining the process' - in a way
that makes it easy for him to 'just rebuild as needed' - but it's on
my head to do the CPAN builds and installs... Some folks all believe
in the CPAN.pm - and I'll back that for anyone who does not want to
become a perlMonk - and just wants it to work But I will argue
that if you want to grow your perl skills -
download the tarball from the CPAN/source-forge/place/otherPlace
build it
rip it apart
understand those comment bars where it says
# wish we had
avoid all of those in your new cooler module, application, .
}
p1: I'll confess that I have not had the time to play with fink, that I
would prefer - but I so understand the underlying 'name space
management problem'
coming as one who has to deal with developing across the vagaries of
*nix.
Nothing like a 'unix standard'
8-)
p2: The challenge of course is where John A. will feel at home...
ciao
drieux
---
Re: hard links on HFS+ (now even further off topic...)
On Monday, November 18, 2002, at 03:33 PM, Peter N Lewis wrote: For example, the system I want for mail is a mail server and pop server that run as the mail account and all mailboxes are private files, so there is no need for any special privs at all - except you need root access to open the smtp and pop ports! Net result is less security, not more. In that case, if you want regular users to be able to open low-numbered ports, you should write a very small setuid program that does that and only that. Then your otherwise unprivileged servers can call that, and you've got the safeness you're looking for with the features you need. The last thing in the world I want with root access is network servers! Agreed. -Ken
Re: hard links on HFS+ (now even further off topic...)
On Monday, November 18, 2002, at 06:13 AM, Wiggins d'Anconia wrote: Heather Madrone wrote: Most of my career was spent as a C/C++ systems programmer. The damage I can do with a command line as root is nothing compared to the damage I can do with a C compiler. This makes no sense? Compiling as a non-root user can cause more damage than a root enabled user? She's saying that she's writing systems programs, which (when run) can cause a great deal of damage if they contain errors or malicious code. -Ken
Re: hard links on HFS+ (now even further off topic...)
Ken Williams wrote: On Monday, November 18, 2002, at 06:13 AM, Wiggins d'Anconia wrote: Heather Madrone wrote: Most of my career was spent as a C/C++ systems programmer. The damage I can do with a command line as root is nothing compared to the damage I can do with a C compiler. This makes no sense? Compiling as a non-root user can cause more damage than a root enabled user? She's saying that she's writing systems programs, which (when run) can cause a great deal of damage if they contain errors or malicious code. But then are we to assume that the programs are getting written in the production environment, and put into place for execution without testing or code audits? again the discussion was about running as a privileged user for every day activities (granted we are way off the original topic which didn't start out as this, but that is where it had been taken), and naturally a program can cause damage when run in a privileged manner, but that damage should be prevented several phases before being put into a place where damage can be caused. http://danconia.org
Re: /usr/bin or /sw/bin?
Yes, /usr/bin is traditional. If it's not a full-blow release, you might even consider /usr/bin/local Cheers, Bohdan On Monday, Nov 18, 2002, at 11:45 America/New_York, Dan Sugalski wrote: At 11:43 AM -0500 11/18/02, John Adams wrote: I've been happily using Fink to install some of my software, and I'm considering whether I'd be better off putting Perl in /sw/bin instead of /usr/bin. Any thoughts, pro or con? I wouldn't do either. Leave /sw for fink stuff, and /usr/bin for the system perl. Put the one you're building into /usr/local/bin instead, so it doesn't conflict with anything. -- Dan --it's like this--- Dan Sugalski even samurai [EMAIL PROTECTED] have teddy bears and even teddy bears get drunk
Re: hard links on HFS+ (now even further off topic...)
At 11:29 AM 11/19/2002 +1100, Ken Williams wrote: On Monday, November 18, 2002, at 06:13 AM, Wiggins d'Anconia wrote: Heather Madrone wrote: Most of my career was spent as a C/C++ systems programmer. The damage I can do with a command line as root is nothing compared to the damage I can do with a C compiler. This makes no sense? Compiling as a non-root user can cause more damage than a root enabled user? She's saying that she's writing systems programs, which (when run) can cause a great deal of damage if they contain errors or malicious code. Or, say, when I happen to be patching the machine code on a live production system. (I don't recommend this, but there are times when my employers considered it necessary.) Anyone who uses the rf flags on rm had better check his typing three times before hitting enter, no matter what his userid. I think we've been talking apples and oranges here. Different systems have different security needs, and different people assess risks differently. Oh, and btw, although I have Windows systems at home, I've mostly worked on BSD and Sun systems, with various stretches on other brands of Unix as well as other operating systems. But let's get back to perl. Heather Madrone ([EMAIL PROTECTED]) http://www.madrone.com Reality: deeper than I dreamed.
Re: hard links on HFS+
On Sat, 16 Nov 2002, Joseph Kruskal wrote: On 11/1/02 3:47 AM, William H. Magill at [EMAIL PROTECTED] wrote: ... journaled file system ... What is a journaled file system? This has been answered already, but just to expand a bit: one very nice feature of the late lamented BeOS was it's filesystem, BFS. Among other neat properties was the fact that it was journalled, meaning that before performing operations on the disc itself, the system would make a note of what it was about to attempt to a special log area first. The benefit of this design is that if anything goes wrong later on, you can quickly roll back to a stable system state. Along similar lines, most modern transactional database systems do something similar -- for example, they'll record your SQL queries to a transaction log, then attempt to do those queries. That way, if a query fails -- you get a disk full error or power outage, for example -- you can leave the database unharmed. (Going back a bit further, IIRC accountants record day to day activity to their own transaction log -- the general ledger -- before using that information to prepare various financial documents. If the documents are found to have errors (arithmatic errors, Enron fraud, etc) then if nothing else auditors can still go back to the original ledgers for comparison. Anyway, the guy that designed BFS, Dominic Giampalo, previously worked for SGI, where he gave Irix supercomputer systems their own journaling layer. For BFS, this allowed average PCs to boot in 15 seconds instead of 5 minutes, but for the big SGI machines it was the difference between 5 minutes and 5 hours, so really it was a critical improvement to a legacy system. Now, Dominic has come to Apple, where he's repeated that trick for HFS+. As others said, this will generally slow down your system a little bit on an ongoing basis, because when writing to disc you have to do a new step of also writing to the system journal first. On the other hand, this should make boot times quicker, particularly for large drives after system crashes, and it should give much better data integrity as well. This now brings OSX one big step closer to where BeOS was five years ago, and where Irix was a decade ago ;) -- Chris Devers[EMAIL PROTECTED]
Re: locale in carbon emacs (was: OS X Installed numbers)
On Thu, 14 Nov 2002, Heather Madrone wrote: At 12:46 PM 11/15/2002 +1100, Ken Williams wrote: On Friday, November 15, 2002, at 11:17 AM, Heather Madrone wrote: However, these past few days have been so discouraging that I have considered selling the Powerbook and surrendering to the evil of Microsoft. As everyone keeps saying, install the Developer's Tools. Among a great many other things -- it's distributed as a 200mb or so package and is something like 1gb installed -- this gives you all the software that any good Unix nerd needs to be content fulfilled (make, gcc, etc etc) along with the high level GUI building tools copious documentation. Actually, I'm a bit curious how you managed to install Perl 5.8.0 without first installing the Tools. Maybe I missed some detail... Those Apple switch ads currently make steam come out my ears. Kill Your Television. Problem goes away abruptly :) No, I don't have any. I have had compatibility problems in the past with different versions of make, so I thought I'd save myself a headache from the start by asking y'all which version you use. Devtools. I understand that you can also get a copy of BSD's make from the GNU/Darwin project, but you shouldn't need this. By default you should get something like this anyway: % ls -l /usr/bin/*make -rwxr-xr-x 2 root wheel 234621 Jul 14 07:25 /usr/bin/automake -r-xr-xr-x 1 root wheel 119636 Nov 11 18:00 /usr/bin/bsdmake -rwxr-xr-x 1 root wheel 152220 Nov 11 18:00 /usr/bin/gnumake lrwxr-xr-x 1 root wheel 7 Nov 11 18:10 /usr/bin/make - gnumake So unless you're a staunch *BSD user, I personally don't see the point of using GNU/Darwin's tools. Rather, for simplified package management, I suggest taking a look at Fink, which make's Debian's apt/dpkg/dselect suite available, wrapping them all behind the Fink command: % sudo fink install uw-imapd-ssl Or % sudo fink selfupdate-cvs sudo fink update-all Couldn't be easier. :) unfortunately, to [not] answer your majordomo question, I don't see it or any other mailing list applications among Fink's current catalog... Most of the mac-specific perl docs that I have seen refer to OS 9. I'm not sure how much of them apply to OS X, so I've been relying on more generic perl docs. This generally seems like the way to go. -- Chris Devers[EMAIL PROTECTED]
Re: locale in carbon emacs (was: OS X Installed numbers)
At 12:49 AM 11/19/2002 -0500, Chris Devers wrote: Actually, I'm a bit curious how you managed to install Perl 5.8.0 without first installing the Tools. Maybe I missed some detail... I downloaded a binary. Those Apple switch ads currently make steam come out my ears. Kill Your Television. Problem goes away abruptly :) I don't have a tv, but Apple runs ads on billboards, in all the geekly magazines, and, of course, on their web site. ...unfortunately, to [not] answer your majordomo question, I don't see it or any other mailing list applications among Fink's current catalog... Majordomo ought to run with only minor tweaking. Porting it to Windows would be a major hassle because it's stuffed to the gills with Unixisms. It didn't run on OS9, but it is reputed to build with no trouble on OSX. (One of my pet peeves is that it's so *easy* for perl and python programmers to write portable code, but they so seldom bother. Everyone who's anyone runs on Unix, anyway) Most of the mac-specific perl docs that I have seen refer to OS 9. I'm not sure how much of them apply to OS X, so I've been relying on more generic perl docs. This generally seems like the way to go. Which is why I joined this list so I could get the Mac specifics. Things are looking up. I figured out why my Eudora mailboxes weren't migrating, and my Powerbook hasn't crashed for 2 or 3 days. I also got the developer tools unpacked, so the Darwin shell is starting to look a bit more like home. Thanks for the pointer to fink. Heather Madrone ([EMAIL PROTECTED]) http://www.madrone.com Reality: deeper than I dreamed.
