Re: Undefined Subroutine Error Message
Did you do any updating of your perl modules before taking the security update? cf http://www.theregister.co.uk/2009/02/16/apple_update_perl_breakage/ and http://www.theregister.co.uk/2009/03/23/apple_perl_breakage_apology/ the simple solution is to download and re-install the the modules that appear to be broken. In this case Compress::Zlib - do this until you have a working CPAN, and at that point you can work with cpan again to re-install any of the modules that you have added. On May 4, 2009, at 6:03 AM, Lola J. Lee Beno wrote: I'm guessing that issue is related to something in Apple's security update that broke the default Perl configuration. What's the solution to getting around this? Going to read /Users/lolajl/.cpan/sources/modules/02packages.details.txt.gz Catching error: 'Undefined subroutine Compress::Zlib::gzopen called at /System/Library/Perl/5.8.8/CPAN/Tarzip.pm line 103. ' at /System/Library/Perl/5.8.8/CPAN.pm line 281 CPAN::shell() called at /usr/bin/cpan line 198 Going to read /Users/lolajl/.cpan/sources/authors/01mailrc.txt.gz Lockfile removed. Undefined subroutine Compress::Zlib::gzopen called at /System/Library/Perl/5.8.8/CPAN/Tarzip.pm line 103. -- Lola J. Lee Beno LinkedIn: http://www.linkedin.com/in/lolajleebeno Facebook: http://www.facebook.com/profile.php?id=714355583 Blog: http://www.lolajl.net/blog/ ciao drieux
Re: Life expectancy
On Dec 21, 2005, at 5:03 PM, James Harvard wrote: Don't worry - this isn't some sort of spam for an elixir of youth! Is there any sort of timeout on Perl scripts? Will they just run until they return or are killed? there is no internal timer that will stop the process. This is why perl is used as a daemon in various instances. Sorry if this seems a daft question, but the language I am used to (Lasso - web application middleware) will kill any thread that runs for more than x amount of time, unless it's told not to. Also, how about DBI connections - any timeout there? Basically I want to leave a Perl script supervising a non-trivial import process into a MySQL db. (There are many GB of data to go in, which needs to be put into a intermediary table then have joins done to split it into related tables with all the correct foreign keys etc.) The only time out that you would need to worry about would be the usual network time outs. Some of them will detach connections if they believe that they are not active... so go for it. ciao drieux
Re: 5.8.7 on Tiger
On Nov 27, 2005, at 7:42 AM, Robert wrote: I only have a couple of questions... #1 It asked about doing a threaded version that was new but stable and a wee bit slower. Should I just take the default of n? yes. Unless you have a really good reason to do threaded perl code. #2 I have gone through one configure just to see what it would ask and except for changing my email address I took the defaults on everything. Is that pretty normal? Yup. Basically If you don't have a good reason to do a special build of it, then don't. ciao drieux ---
perl-5.8.6 for Darwin Kernel Version 7.8.0
volks, yes, I know that Tiger is suppose to deliver perl-5.8.6 - but I am not in a position to upgrade to Tiger this weekend - but would like to build perl-5.8.6 and install it the way that it would be installed. So what I need is a 'policy.sh' or the config parameters for building it. I ran the standard ./configure that I downloaded from the CPAN and it's default was to install everything in /usr/local - where as the current version 5.8.1-RC3 is installed in /System/Library/Perl/5.8.1 does this change in Tiger? ciao drieux ---
Re: LWP problems
On Apr 30, 2005, at 6:27 PM, [EMAIL PROTECTED] wrote: Im sure there is a fairly simple answer to my problems using the LWP notation but I cant seem to work it out. Im trying to send (1) input i.e. a list of genes and (2) effectively press the START button on a website - http://fatigo.bioinfo.cnio.es/ - remotely using the LWP notation. My problem is that unlike my previous experience with screen scraping the URL of this website doesnt change with a particular request containing the query within it. - any help would be appreciated thanks Anthony Have you started with actually looking at the 'html' that is being generated for that URL? A part of the trick here is that you will need to work out all of the variables that will need to be checked in the piece of javascript used to validate before submitting. I presume that since you are talking about the 'query string' not changing that you mean that the 'submit' is a 'post' rather than a 'get' event - since one needs to submit the query to the in the proper form back to the server. There is at least one hidden value that I noticed, and that will need to be a part of your post information. HTH. ciao drieux ---
Re: Trying to understand signals and restartable system calls
On Mar 21, 2004, at 8:55 AM, Mark Alldritt wrote: [..] I take if from your responses that Perl doesn't automatically restart system calls after a signal is processed as Programming Perl and the Perl Cookbook suggest it does. I don't actually own the code that is doing the read, so its not easy for me to modify it. [..] Actually, not really. It is more a case of the version of Perl that was shipped with Mac OSX. I ran into that problem while demonstrating some code that formerly worked under perl 5.6, and will still work on verions of perl 5.8.X greater than the verision that apple shipped: http://www.wetware.com/drieux/pbl/Sys/gen_sym_big_dog.txt So the real question is 'how defensive' does one want to write their code when stepping into Signal Handling - and the issues with possible cross platform in compatability issues... ciao drieux ---
B/C - Re: Trying to understand signals and restartable system calls
On Mar 19, 2004, at 1:31 PM, Joel wrote:
I'll toss in my two cents here, since I've done something like this
before in a production-type environment.
IMHO, The best thing to do would be to have your signal handler set a
flag (in the manner described by drieux) and have your loop react to
that
flag when it changes. This is a slight difference from what drieux did.
[..]
$SIG{USR2} = sub { $sig_flag++};
[..]
You know, that's one of those 'religious' issues that
I still don't feel that I have a 'solid' answer on one
way or the other... I think as a general rule of thumb
I'd probably tilt more towards this strategy but...
ciao
drieux
Re: Trying to understand signals and restartable system calls
On Mar 19, 2004, at 9:34 AM, Mark Alldritt wrote:
Hello,
I'm trying to understand how signals and restartable system calls
interact.
Take this example:
#!/usr/bin/perl
$SIG{USR2} = sub { print Here I Am\n; };
print Starting...\n;
my $abc;
while (read STDIN, $abc, 20) {
print $abc\n;
}
print Done\n;
[..]
There are two basic options here, one of which is
to build the next version of perl 5.8.3(???) or
our $sig_flag=0;
$SIG{USR2} = sub { print Here I Am\n; $sig_flag++;};
print Starting...\n;
my $abc;
while( read(STDIN,$abc,20) || $sig_flag )
{
$sig_flag=0 if $sig_flag;
}
or something to that effect.
ciao
drieux
---
star, OSX, and perl wrapper for dumping
volks, I have a project that may use 'star' ( pronounced 'eestar' ) that will need to work on a Solaris, BSD, Linux, and maybe Mac OSX, so of course I want to solve the problem on my Mac first and then take that back to linux, et al. So my questions are a. has anyone built 'star' on OSX? the star-1.4.3 tar has notes but they are talking about OSX 10.1 and I am running 10.3.2 b. is anyone useing any of the 'alpha' star-1.5.X versions? on mac OSX? c. has anyone used the star 'dump' features that are experimental, and if so, any advice? d. does anyone know of any pre-existing 'dump tools' that would allow for a simple sub-stitution of the underlying 'dump' with star? Or should I just re-hack my old perl code which works mostly well enough? Or is there a specifica 'dump/backup' and Mac OSX mailing list/web-site that this should be addressed to? My core hope is that since this is not a part of the core 'money making' proprietary portion of the Project that it will be 'open sourceable' as soon as it is stable enough to be presentable in polite society. ciao drieux ---
Re: Debugger in OS X10.3.2; also dumpValues
On Jan 17, 2004, at 2:31 PM, dennis Geller wrote: I'm working with Perl for the first time under OS X and having some difficulties. Some I've found answered in the archives, but ... First, I don't seem to have mastered dumpValue. My call to it looks like this: @departments= keys %all; sort @departments; dumpValue([EMAIL PROTECTED]); @departments is not empty, but nothing is printed from dumpValue Did you mean to use Dumpvalue vice the older Data::Dumper? What exactly were you looking for? [..] I'm accessing the file with a full pathname: $WDir= Volumes/Lore/AHSmaildirectory/; $InputFile=TestData2.txt; open(NAMEFILE, . $WDir . $InputFile) || die Can't open input file; [..] actually you need to start a Fully Qualified pathname from / hence your $WDir would need to be $WDir= /Volumes/Lore/AHSmaildirectory/; to start with the top / in the path. are you using 'use strict' and 'use warnings'??? ciao drieux ---
Re: Perls of taking a vacation...
On Dec 22, 2003, at 7:52 AM, Nathan Torkington wrote: On Dec 22, 2003, at 8:50 AM, Jerry LeVan wrote: print (5.0/9.0)*($ARGV[0]-32.0), Centigrade\n ; I had to grab the Perl book and found If it looks like a function it is a function. Y'all ever been bit by this type of misdirection? All the time. This seems to be tied to how 'print' does it's machinations, and is true on non-mac machines running 5.6.1 et all whereas the following skips along happily. printf(%.2f Centigrade\n, (5.0/9.0)*($ARGV[0]-32.0)); since that is doing the print sprintf(%.2f Centigrade\n, (5.0/9.0)*($ARGV[0]-32.0)); and hence it appears to view (5.0/9.0)*($ARGV[0]-32.0) as a resolvable calculation vice a possible function... alternatively if one does print STDOUT (5.0/9.0)*($ARGV[0]-32.0) , Centigrade\n; one has expressly called out the FILEHANDLE and so the compiler does not have to try and 'work it out' whether that first expression is suppose to be. alternatively print . (5.0/9.0)*($ARGV[0]-32.0) . Centigrade\n; or why I generally TRY to avoid doing anything 'complex' in a simple 'print statement' unless I really need it that way. ciao drieux ---
Re: Problems installing modules on OS X Panther
please forgive my top posting here, Stephan raised this on the beginner's mailing list and may not be aware that there is a a [EMAIL PROTECTED] list that may be better able to handle the detailed level of specifics. On Dec 9, 2003, at 1:37 AM, Stephan Hochhaus wrote: Hello list! I am starting to dig deeper into Perl, after having successfully written my first working script :-) I am trying to install modules on my Mac OS X 10.3 Server machine, but I usually end up getting errors like this for the GD package (1) or this for the Bundle::LWP (2). I did install gdlib2 via fink and libwww as well, but I keep getting the errors nevertheless. I tried installing as an admin user, root, even through webmin, but I always ended up unsuccessful. There are even more modules I cannot install, like DBD::Pg, Bundle::DBI worked fine though (via webmin). Bundle::CPAN did install partly with an error (3). I am using OS X' pre-installed Perl 5.8.1-RC3 Do I need to install certain things first? Is that my or my machines fault? Any help is greatly appreciated! Stephan (1) Error produced by perl -MCPAN -e 'install GD' /private/var/root/.cpan/build/GD-2.11/blib/arch/auto/GD/GD.bundle undefined reference to _gdImagePngPtrEx expected to be defined in a dynamic image t/Polylinedubious Test returned status 0 (wstat 5, 0x5) DIED. FAILED test 1 Failed 1/1 tests, 0.00% okay Failed Test Stat Wstat Total Fail Failed List of Failed --- t/GD.t 0 510 20 200.00% 1-10 t/Polyline.t0 5 12 200.00% 1 Failed 2/2 test scripts, 0.00% okay. 11/11 subtests failed, 0.00% okay. make: *** [test_dynamic] Error 2 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force (2) Error produced by perl -MCPAN -e 'install GD' Failed 4/28 test scripts, 85.71% okay. 47/388 subtests failed, 87.89% okay. make: *** [test] Error 2 /usr/bin/make test -- NOT OK Running make install make test had returned bad status, won't install without force Bundle summary: The following items in bundle Bundle::LWP had installation problems: Net::FTP LWP (3) Error produced by perl -MCPAN -e 'install Bundle::CPAN' Running make install Files found in blib/arch: installing files in blib/lib into architecture dependent library tree Writing ///Library/Perl/5.8.1/darwin-thread-multi-2level/auto/Data/Dumper/ .packlist Appending installation info to ///System/Library/Perl/5.8.1/darwin-thread-multi-2level/perllocal.pod /usr/bin/make install -- OK Net::Telnet is up to date. Net::Cmd is up to date. Bundle summary: The following items in bundle Bundle::libnet had installation problems: Data::Dumper Term::ReadKey is up to date. Term::ReadLine::Perl is up to date. CPAN is up to date. Bundle summary: The following items in bundle Bundle::CPAN had installation problems: Bundle::libnet and the following items had problems during recursive bundle calls: Data::Dumper -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] http://learn.perl.org/ http://learn.perl.org/first-response ciao drieux ---
Re: Executing an Xwindows app from perl on OSX
On Dec 4, 2003, at 5:54 PM, Ari Kahn wrote: I have an Xwindows program (consed) that I would like to execute from perl. Of course OSX is not Xwindows so executing it outside of an xwindows terminal will not work because I get Error: Can't open display: I need to find a way to somehow tell consed to run in an Xwindows environment if the Xwindows server is running. The first part of the problem is figuring out IF there is an Xwindows server up and running so that you can have the output sent there. IF the Xwindow Server is not running, then you will want to start it. You might want to peek at the Open Office Folks, since they have a 'launcher application' that will start the Xwindows Server and then launch OpenOffice... This of course means updating your installer to make sure that Xwindows is installed, and then having the person doing the installation make a commitment to which Xwindows to start then caching that information into a configuration file that your perl wrapper code will use. HTH. ciao drieux ---
holy ravenous bugblatter beast of traal!
volks, has anyone else bumped heads with the 5.8.1 perlio layer where the old school tie chomp(my $line = STDIN); now pops out if a sig handler is called on a signal, such as SIG_CHLD??? I just did the upgrade and got bitten with that silly demo code about doing command line arguments. Since right before the upgrade the code did what I expected it to do under 5.6.1 and then afterwards it was popping out of it and whining about a chomp on an un-initialized variable, yada-yada-yada... So that command line demo code has come around to be usefuler than merely the expected intellectual amusement. http://www.wetware.com/drieux/pbl/Sys/gen_sym_big_dog.txt ciao drieux --- cf: http://www.wetware.com/drieux/PR/blog2/Code/200311.html#id3152907788
Re: Looking for old laptop/notebook
On Tuesday, Nov 11, 2003, at 18:48 US/Pacific, Joel Rees wrote: [..] One other thing to look into if he finds himself getting into porting (besides Perl, of course) -- [..] my complements to Joel, et al, for the advice. But Scott is not likely to become a coder in this life time. It is why he 'got a mac'. I think that the KillJoy here is some application that would make sure that what he wrote complied with things like the NY Times Style Guide, et al. ciao drieux ---
Fwd: Looking for old laptop/notebook
Begin forwarded message: does anybody know how to make Hypercard run on System 9 or X? Scott volks, does anyone here have a good pointer on how to get old style Hypercard stuff running on OSX? a friend of mine in the UK was wondering. The stuff works under the older Apple 8.5 but apparently not in 9 or OSX. ciao drieux ---
Re: Reading preferences
On Thursday, Oct 23, 2003, at 11:15 US/Pacific, James Reynolds wrote:
In BASH, it is really easy to read preferences.
[..]
My question is, can something similar be done in perl?
Or do I have to open, read, parse, then close the preference file?
I'm not sure quite what bash is offering you for the 'read'
but it will still need to
open
read
parse
close
a preference file.
you really merely need a sub like:
which given a config_file name will return a reference to the hash
of stuff in that config file.
#
#
sub apple_config_file_parser
{
my ($file_name) = @_;
open(FD, $file_name) or die unable to open $file_name: $!;
my $ref;
while(FD)
{
chomp;
s/#.*//;
if( /(.*)=(.*)/)
{
$ref-{$1} = $2;
}
}
close(FD);
$ref;
} # end of apple_config_file_parser
ciao
drieux
---
Re: What is going on?
On Wednesday, Oct 22, 2003, at 15:25 US/Pacific, Vic Norton wrote:
[..]
my $headdir = $ENV{HOME}/Perl/MyPerl/Virus/New Viruses/Headers;
# my $headdir = $ENV{HOME}/Desktop;
open EXTRACTED, $headdir/ extractedFiles
or die cannot open extractedFiles: $!;
print EXTRACTED Extracting head from somefile\n;
close EXTRACTED;
[..]
I modified your script to run with
my $headdir = $ENV{HOME}/lib/some folder/Headers;
#my $headdir = $ENV{HOME}/lib/bob/some folder/Headers;
and then used the Finder to create the some folder and Headers
below that. And have been able to 'update' the extractedFiles
each time I ran it. I used the commented out line to point at
a directory that I knew did not exist. As expected it causes the
die line
[jeeves: 12:] ./test*
cannot open extractedFiles: No such file or directory at ./test.plx
line 11.
[jeeves: 13:]
rather than updating the file:
[jeeves: 14:] ls -ltr ; cat *ex*
total 16
-rw-r--r-- 1 drieux house 90 Oct 22 16:40 extractedFiles
-rwxr-xr-x 1 drieux house 496 Oct 22 16:41 test.plx
Extracting head from somefile
Extracting head from somefile
Extracting head from somefile
[jeeves: 15:]
I am running 10.2.8 and the default perl build.
How are you checking that the the time stamp changes
but the contect does not?
ciao
drieux
---
iTunes and RMP
ok, here is the basic problem. myFascistHouseMate finally broke down and installed a CD-Rom burner on his PC box, so that he could have things like Mercedes Benz mixed down with other Janis, CCR, et al music that he could load up in his Merdeces 400 Series. He has also installed the iTunes for his PC. But the CD rom he burned does not have 'the play list' 'on it' to keep track of the details about which track is from which artist from the days of Governor Ronald Reagan. He just sent me the RMP file that is an xml document but there appears to be no simple and easy way to co-locate that information with the tracks once I import them off the CD. Is there an easy way to fix this? ciao drieux ---
Re: BBEdit-Perl confusion
On Thursday, Oct 16, 2003, at 06:56 US/Pacific, Vic Norton wrote: I have recently installed Perl 5.8.0 on my iMac via PortsManager from DarwinPorts http://www.opendarwin.org/projects/darwinports/. Perl 5.8.0 resides in the /opt/local/bin directory, and this directory is at the beginning of $PATH. Everything works well except that BBEdit seems rather confused. Any suggestions as to how to rectify this confusion would be appreciated. p0: have you set up a $HOME/.MaxOSX/environment.plist that would contain say: ?xml version=1.0 encoding=UTF-8? !DOCTYPE plist SYSTEM file://localhost/System/Library/DTDs/PropertyList.dtd plist version=0.9 dict keyPATH/key string /opt/local/bin:/home/drieux/bin:/usr/local/bin:/usr/bin:/bin:/usr/ local/sbin:/usr/sbin:/sbin:/usr/X11R6/bin/string keyMANPATH/key string/home/drieux/man:/usr/local/share/man:/usr/share/man/string /dict /plist This way the Aqua GUI would be launched knowing about your alternative directory structure. bbedit is probably picking up a 'default' path from the GUI when you launch it, hence would most likely be running the 'default' perl from /usr/bin/perl. p1: it is interesting that the 'run in terminal' option would be invoking an alternative version of perl... DUH! hold on, IF bbedit started with what it thought was the definition, then it would have invoked perl on the file perl your_file_here hence it would have been the /usr/bin/perl (???) version vice the 'first in the path found' version of perl. ciao drieux ---
Re: Mac::Glue and aliases
On Tuesday, Sep 16, 2003, at 13:48 US/Pacific, Jeff Lowrey wrote: [..] use Mac::Glue my $iTunes=Mac::Glue-new(iTunes); my $temp = $iTunes-prop(location=file_tracks,library_playlist='Library'); my @alias = $temp-get(); print scalar(@alias); gives me the right number. so if one didn't want the $temp why not try: my @alias = $iTunes-prop(location=file_tracks,library_playlist='Library')- get(); and perl would invoke the 'get()' on the proper prop() ??? Or am I missing something here? ciao drieux ---
Re: problem installing DBI and gcc
On Monday, Sep 1, 2003, at 03:54 US/Pacific, xweb wrote: Hi, i tried to install cpan module (dbi) but the gcc compiler makes an strange error /Local/Library/Frameworks: Not a directory. I have tried to compile a very simple c source but it' s the same error! can someone help me? [..] first off there appears to be no /Local/Library/Frameworks directory by 'default' on the standard OSX distribution. So what you will want to check for is why the 'Makefile' that you are using to build what ever it is you are trying to build has an include for that directory. ciao drieux ---
Re: OT: Mac OS X's built-in URL architecture
On Monday, Jul 14, 2003, at 19:18 US/Pacific, Peter N Lewis wrote: At 10:25 AM +0900 15/7/03, Thilo Planz wrote: sherlock://com.apple.flights?new_windowtoolbar=hidden itms://phobos.apple.com/WebObjects/MZSearch.woa/wa/ advancedSearchResults?songTerm=Bohemian I am amazed by these sherlock:// and itms:// URLs. Does anyone know how this works, if everyone can register protocols for their own apps (or if it is closed to Apple's) and where I can find some documentation about this architecture? [..] Anyone can register to be a helper for any protocol with Internet Config. Of course, a proper URL protocol would need to go through the standards process, etc, but that's for standards weenes right? For example, we register interarchy: protocol handler for Interarchy to do various things (many of the menu commands can be got through an interarchy: URL). We also support various others for looking up DNS names and such. [..] am I being 'fussy' here - in that RFC 2396, which updates RFC 2732 - cf: perldoc URI refers to this as scheme eg: scheme:scheme-specific-part#fragment scheme://authoritypath?query#fragment path?query#fragment and that what we are seeing here is a way to DO that process? 'sherlock' is an application, and not a 'protocol' That in fact it is time to get beyond merely 'the protocol droid' models of 'ftp|http|nntp' and that file:// was always a 'scheme' and not a protocol to begin with?? ciao drieux ---
the exit with 0 issueRe: Learning Perl book, Chapter 1 example: open MAIL, |mail email_address doesn't work
On Sunday, Jun 8, 2003, at 08:58 US/Pacific, Robin wrote: On Thursday, June 5, 2003, at 03:36 am, Dan Mills wrote: [..] It's unfortunate that mail exits with 0, however. I was burned by this not very long ago (ran M-x mail in emacs for a quick mail, no error, never got there. Eventually I ran mailq and realized sendmail wasn't setup properly). It isn't mail's fault, though. sendmail returns with 0 as well. I've come accross this before, it's a UNIX C-ism which return 0 instead - historically any other return value would be an error code, see quotes below for clarifiaction [..] close but not quite the issue. mail, mailx, et al 'ran successfully' - and hence should exit with '0' - because they ran successfully. The problem is that mail is not required to know if sendmail, smail, procmail, WhatEver MTA, works appropriately. It might have been nice, but it is not required in the original spec. Nor is there a requirement for mail, mailx, et al, to know what happens on the other side of the sendmail process at the remote host, etc, etc, etc ciao drieux ---
Re: Learning Perl book, Chapter 1 example: open MAIL, |mail email_address doesn't work
On Wednesday, Jun 4, 2003, at 00:44 US/Pacific, David Cantrell wrote: On Tuesday, June 3, 2003 20:24 -0700 Richard E. Adams [EMAIL PROTECTED] wrote: I am working through the exercises in Chapter 1 of Learning Perl, Second Edition, O'Reilly publishers. I am using MacOS X (10.1.5), and Perl, v.5.6.0. An excerpt from one of the author's programs shows the following three lines: open MAIL, |mail YOUR_ADDRESS_HERE; print MAIL bad news: $someone guessed $someguess\n; close MAIL; [..] To send mail, you need two components. A mail client (aka a mail user agent or MUA) and an SMTP program (aka a mail transport agent or MTA). The 'mail' program is an MUA. It passes messages to a local MTA for delivery. IIRC on OS X the MTA (sendmail) is installed, but not configured, so 'mail' successfully hands the message over to sendmail, which then neither knows what to do with it, nor knows how to warn you of the fact. I know that Richard is working two sets of questions: a. how do I do this specific thing from learning perl b. how do I do email with perl May I highly recommend http://search.cpan.org/author/MARKOV/MailTools-1.58/ as an alternative for doing the specifics of emailing from perl. Sorting out sendmail is better these days but can be more complex than merely learning perl. I have some illustrations of email tricks in perl up at http://www.wetware.com/drieux/pbl/Other/email/ which I did on my little OSX box. As for the learning perl part, if he understands that the code in the book was essentially demonstrating invoking an external command, eg: '/usr/bin/mail' from perl, then he has the basics for doing one of the basic 'popen()' style solutions. But as we notice, the book presumes that everyone understands MTA/MTU and that by default 'sendmail' is an available service on the local host. ciao drieux ---
der quine with use strict
p0: thanks chris for more 'academic' views of the quine idea
{ I will confess as an approach it just seems silly }
p1: the q^...^ trick is not one I have used, it looks way
too much like bad ascii art... 8-)
p2: I likewise have not used the 'eval' in this context but
in the more traditional eval { }
On Tuesday, Mar 18, 2003, at 05:08 US/Pacific, Ken Williams wrote:
[..]
Variables $c and $t are undeclared, so the eval fails when they're
encountered.
-Ken
OOF! why didn't I see that!
I could see that the $s was coming down from above
but had not paused to think about the $t and $c not
be declared, and hence getting neither a run time error
and obviously no compile time error
It was dying silently inside of the 'eval'
hence
#!/usr/bin/perl -w
use strict;
our $s='our $c = chr(39);
our $t = q^#!/usr/bin/perl -w
use strict;
our $s=^.$c.$s.$c.
q^;eval $s;^.\n;print $t
### execute-me
###
';
eval $s;
self replicates as a quine...
But will not work with trying to have
#!/usr/bin/perl -w
$s='$c = chr(39);
use strict;
since the ' there will break up the assignment
for $t
So while clearly still a 'silly problem' it at least
does illustrate a few tricks I might not have considered.
ciao
drieux
---
Minor Recomendation
for those interested in the origins of beyond the pale http://www.quinion.com/words/qa/qa-pal2.htm I can appreciate that for those for whom this is their first 'major international crisis' that it is clearly times for jitters. But a part of the way that many handle these sorts of things is to focus on what can and needs to be done and in which context. As such it would be helpful for both my 'hippies' and my 'vets' if we can isolate macosx to being about issues related to perl and OSX - as a neutral topic that does not complicate 'their stressors'. If people need to find forums in which to deal with their 'emotional stressors' - feel free to contact me off list, and I will try to assist them in finding 'safe havens' where they can deal with which ever position they believe is imperative. ciao drieux ---
Re: war.pl
On Monday, Mar 17, 2003, at 14:15 US/Pacific, W. Blake wrote: [..] #! /usr/bin/perl $s='$c = chr(39);$t = q^#! /usr/bin/perl $s=^.$c.$s.$c.q^;eval $s;^.\n;print $t ### execute-me [..] ';eval $s; I just noticed one of those things I don't normally take the time out to 'check for' - but I ran the orignal code, and got a perl script printed out. Rather than just the 'ascii art'. but if I do the sort of thing I would normally do #!/usr/bin/perl -w use strict; our $s='$c = chr(39); $t = q^#!/usr/bin/perl $s=^.$c.$s.$c.q^;eval $s;^.\n;print $t ### execute-me ### ';eval $s; I get no output I'm running the apple default 5.6 version of perl, was this the expected behaviors ciao drieux --- or is that a part of the subliminal message
Re: Where is site_perl?
On Sunday, Mar 9, 2003, at 19:53 US/Pacific, Vicki Brown wrote:
OK, where is site_perl? ... or the moral equivalent thereof?
[jeeves: 94:] perl -MConfig -e 'print site lib:
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib: /Library/Perl
Vendor Lib: /Network/Library/Perl
[jeeves: 95:]
This works for both perl on apple, and on *nix boxes.
Given Apple's unusual installation directories, if I have a set of
.pm's I
need to install (no bundle, no Makefile, I just need to put them in the
right place)... do I put them in /Library/Perl/darwin?
/Library/Perl/darwin/auto?
The real question here is if they are 'pure perl'
without any actual XS stuff, then they are by definition
'architecture independent' and should path from
/Library/Perl
eg: if I have a package that is
Foo::Bar::Baz
then I want to make sure that I have constructed the paths
/Library/Perl/Foo/Bar/
and put that Baz.pm there.
At which point you may wish to correct the core defect here,
which is that your collection of 'perl modules' would be simpler
to manage had you started with say h2xs to simplify the process
of building out your 'source tree' - and generating the requisite
Makefile.PL files.
I have some information at:
http://www.wetware.com/drieux/CS/lang/Perl/PM/
The Good Enough Case Study is at:
http://www.wetware.com/drieux/CS/Proj/PID/
This way one starts out from a safe beginning and does not
have to concern one's self with the vagaries of how both
the Vendor Did things with 'where is site_perl' as well
as how the FreakingPerlFascistSystemAdmin[1] did things:
eg:
[jeeves: 6:] rlogin vladimir
Last login: Sat Mar 8 12:55:33 from jeeves
Sun Microsystems Inc. SunOS 5.9 Generic May 2002
vladimir: 52:] perl -MConfig -e 'print site lib:
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib: /usr/local/lib/perl5/site_perl/5.6.1
Vendor Lib: /usr/local/lib/perl5/vendor_perl/5.6.1
vladimir: 53:] rlogin xlotl
Last login: Tue Feb 25 15:57:11 from jeeves
Copyright (c) 1980, 1983, 1986, 1988, 1990, 1991, 1993, 1994
The Regents of the University of California. All rights
reserved.
FreeBSD 4.6-RELEASE (GENERIC) #0: Tue Jun 11 06:14:12 GMT 2002
Welcome to FreeBSD!
xlotl: 52:] perl -MConfig -e 'print site lib:
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib: /usr/local/lib/perl5/site_perl/5.6.1
Vendor Lib:
xlotl: 53:] rlogin xanana
Last login: Sat Mar 8 11:10:12 from jeeves
xanana: 52:] uname -a
Linux xanana 2.4.18-10smp #1 SMP Wed Aug 7 11:17:48 EDT 2002 i686
unknown
xanana: 53:] perl -MConfig -e 'print site lib:
$Config{installsitelib} \nVendor Lib: $Config{installvendorlib}\n'
site lib: /usr/lib/perl5/site_perl/5.6.1
Vendor Lib: /usr/lib/perl5/vendor_perl/5.6.1
xanana: 54:]
Since you leave those niggling details to be worked out when
the installer types
perl Makefile.PL
make test
make install
And IF you opt to pull your POD out of the Baz.pm into Baz.pod
then it will get parked appropriately as well Since of course
there is nothing more important than being able to go
perldoc Foo::Bar::Baz
and there in the synopsis section you have all the cut and
paste solutions to simplify the process of generating the
code that will use your Foo::Bar::Baz module...
Then assuming that you shift into creating perl modules which
actually do have architecturally dependent components you will
again not have to worry about that part...
And at that point you will also have found a seamless way
to park all of this in which ever source code control system
you find useful. In Apple you should be very familiar with CVS,
old sun freaks like SCCS, die hard BSD heads are still soldiering
on with RCS, others come up with compromises such as perforce and ...
This way as bug reports come in from the field, you can keep
upgrading the product appropriately and re-distributing the tarball
ciao
drieux
---
[1] technically I am the site's FreakingPerlFascistSystemAdmin
but I have to do it in a way that conforms to the Proprieter's
penchance for deeply unresolved issues about BSD v. SYS V stuff
that goes back to system 7 issues But we think that the
medication is starting to help some
8-)
Re: Where is site_perl?
On Monday, Mar 10, 2003, at 09:21 US/Pacific, Ken Williams wrote:
[..]
perl -V:installsitelib -V:installvendorlib
first off thanks for the tip, somewhere I remember reading
that it should work that way, but I will confess a complete
blithe naivete about what I believe someone called 'perl golfing'
but clearly this is a most excellent trick worth having!
On a Default OSX box I note:
[jeeves: 96:] perl -V:installsitelib -V:installvendorlib
installsitelib='/Library/Perl';
installvendorlib='/Network/Library/Perl';
[jeeves: 97:] uname -a
Darwin jeeves.wetware.com 6.3 Darwin Kernel Version 6.3: Sat Dec 14
03:11:25 PST 2002; root:xnu/xnu-344.23.obj~4/RELEASE_PPC Power
Macintosh powerpc
[jeeves: 98:]
In the for what it is worth catagory - I do not have
an actual /Network/Library/Perl directory on Jeeves,
so it is possible that while the default apple build
has the installvendorlib defined, they may not yet
have actually worked out what they are planning to do with it.
In much the same way that the solaris version of perl has
the installvendorlib defined, and the directory exists, but is empty.
{ eg:
vladimir: 65:] /usr/perl5/bin/perl -V:installsitelib -V:installvendorlib
installsitelib='/usr/perl5/site_perl/5.6.1';
installvendorlib='/usr/perl5/vendor_perl/5.6.1';
vladimir: 66:] perl -V:installsitelib -V:installvendorlib
installsitelib='/usr/local/lib/perl5/site_perl/5.6.1';
installvendorlib='/usr/local/lib/perl5/vendor_perl/5.6.1';
vladimir: 67:]
}
you might want to check if you have an 'open issue'
caused by installing one of the fink modules that
may bite you either that or you skipped a
step when building your version of perl.
IMMHO it is important to 'support' the installvendorlib for
those folks who would find it a useful way to
deliver vendor supplied, vendor supported perl modules.
ciao
drieux
---
Re: use lib missing architecture specific directory
On Friday, Mar 7, 2003, at 15:41 US/Pacific, Nathan Herring wrote:
[..]
All of our perl scripts have the following
line:
use lib $ENV{HOME}/Library/Perl/lib;
However, it doesn't seem to be adding
/Users/nathanh/Library/Perl/lib/darwin to @INC like it should and so a
bunch of modules don't work. Does it not like going through a soft
link?
Anyone else have this issue or pointers on what I'm doing wrong?
[..]
I just tested your basic idea on my Solaris machine to
verify that this is the expected behavior. { same for redhat 7.X }
I just noticed that it is NOT doing that on the OSX box.
The work around would seem to be to expressly add an additional
use lib line...
The only differences, beside the OS - is that I am running
Apple's Stock perl 5.6.0 - whereas I am running 5.6.1 on the Solaris
Machine.
The apple side:
[jeeves: 18:] perl test.plx
/home/drieux/lib/perl /System/Library/Perl/darwin /System/Library/Perl
/Library/Perl/darwin /Library/Perl /Network/Library/Perl/darwin
/Network/Library/Perl .
[jeeves: 19:] cat test.plx
#!/usr/bin/perl -w
use strict;
use lib $ENV{HOME}/lib/perl;
print @INC \n;
[jeeves: 20:] ls -laR /home/drieux/lib/perl
total 0
drwxr-xr-x 3 drieux house 102 Mar 8 11:00 .
drwxrwxrwx 4 drieux house 136 Mar 8 11:02 ..
drwxr-xr-x 3 drieux house 102 Mar 8 11:00 darwin
/home/drieux/lib/perl/darwin:
total 0
drwxr-xr-x 3 drieux house 102 Mar 8 11:00 .
drwxr-xr-x 3 drieux house 102 Mar 8 11:00 ..
drwxr-xr-x 2 drieux house 68 Mar 8 11:00 auto
/home/drieux/lib/perl/darwin/auto:
total 0
drwxr-xr-x 2 drieux house 68 Mar 8 11:00 .
drwxr-xr-x 3 drieux house 102 Mar 8 11:00 ..
[jeeves: 29:]
The Solaris Side:
libex: 185:] perl test.plx
/home/drieux/lib/perl/sun4-solaris-64int /home/drieux/lib/perl
/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 .
libex: 186:] !ls
ls -laR /home/drieux/lib/perl
/home/drieux/lib/perl:
total 24
drwxr-xr-x 3 drieux house 4096 Nov 3 18:23 .
drwxr-xr-x 11 drieux house 4096 Jan 15 22:25 ..
drwxrwxr-x 3 drieux house 4096 Mar 8 11:03 sun4-solaris-64int
/home/drieux/lib/perl/sun4-solaris-64int:
total 32
drwxrwxr-x 3 drieux house 4096 Mar 8 11:03 .
drwxr-xr-x 3 drieux house 4096 Nov 3 18:23 ..
drwxr-xr-x 2 drieux house 4096 Mar 8 11:03 auto
-rw-rw-r-- 1 drieux house482 Mar 8 10:49 perllocal.pod
/home/drieux/lib/perl/sun4-solaris-64int/auto:
total 16
drwxr-xr-x 2 drieux house 4096 Mar 8 11:03 .
drwxrwxr-x 3 drieux house 4096 Mar 8 11:03 ..
libex: 187:]
ciao
drieux
---
Re: use lib missing architecture specific directory
On Saturday, Mar 8, 2003, at 11:13 US/Pacific, drieux wrote:
On Friday, Mar 7, 2003, at 15:41 US/Pacific, Nathan Herring wrote:
[..]
All of our perl scripts have the following
line:
use lib $ENV{HOME}/Library/Perl/lib;
[..]
the bug is in lib.pm
the stock apple version has, around line 35
# Put a corresponding archlib directory infront of $_ if it
# looks like $_ has an archlib directory below it.
unshift(@INC, $_/$ver) if -d $_/$ver;
unshift(@INC, $_/$ver/$archname) if -d $_/$ver/$archname;
whereas the version I have with 5.6.1 has
# Put a corresponding archlib directory infront of $_ if it
# looks like $_ has an archlib directory below it.
unshift(@INC, $_/$archname) if -d $_/$archname/auto;
unshift(@INC, $_/$ver) if -d $_/$ver;
unshift(@INC, $_/$ver/$archname) if -d $_/$ver/$archname;
It is the first of these lines that YOU want to see 'fixed' in
your version of lib.pm in /System/Library/Perl
unfortunately the version number of the module is the same
in both the 5.6.0 and 5.6.1 lib.pm so this is a skew problem.
HTH...
ciao
drieux
-
enginnering is engineering,
but software engineering is SciFi
without the Plot Development or Characters
Re: CGI -upload(file) Script Question
On Saturday, Mar 8, 2003, at 11:59 US/Pacific, Jim wrote: Anybody know off the top of their head when the -upload(file) function of CGI.pm came into play? [..] p0: from perldoc CGI you will noted: $CGI::DISABLE_UPLOADS If set to a non-zero value, this will disable file uploads completely. Other fill-out form values will work as usual. So you might want to have a simple piece of CGI code that returns that information to you. It may well be that earthlink has that disabled. p1: you might want to also look at perldoc Config so that you can get the configuration information about the perl that is being run on earthlink host. p2: it is possible that they have 'uploading' turned off at the webserver itself... ciao drieux ---
Re: 2 /Library/Perl in @INC
On Thursday, Feb 27, 2003, at 08:22 US/Pacific, Riccardo Perotti wrote:
I just did a
perl -e 'print $_\n for @INC'
in Terminal and both /Library/Perl and /Network/Library/Perl are
listed
twice. Why?
about the only reasonablish reason I can think of would
be that they did not do a 'version' based solution for the site_lib
hence you would have expected to see something like
/Library/Perl/darwin
/Library/Perl/5.6.0
/Library/Perl
If you check the Config.pm you will note these things.
eg:
[jeeves: 69:] perl -MConfig -e 'print $Config{sitelib_stem} \n'
/Library/Perl
[jeeves: 70:] perl -MConfig -e 'print $Config{sitelibexp} \n'
/Library/Perl
[jeeves: 71:]
vice say:
vladimir: 53:] perl -MConfig -e 'print $Config{sitelib_stem} \n'
/usr/local/lib/perl5/site_perl
vladimir: 54:] perl -MConfig -e 'print $Config{sitelibexp} \n'
/usr/local/lib/perl5/site_perl/5.6.1
vladimir: 55:]
you can then also test the vendorlib side of the process.
[jeeves: 71:] perl -MConfig -e 'print $Config{installvendorlib} \n'
/Network/Library/Perl
[jeeves: 72:]
HTH.
ciao
drieux
---
Re: Help with dl_install_.al error please
On Friday, Feb 28, 2003, at 14:18 US/Pacific, Warren Pollans wrote:
[..]
I'm trying to work through recipe 9.16 in the cookbook - using
Apache::DB - although I'm not trying to use Apache::DB yet - just
trying to see how my stuff works when I start apache with httpd -X -f
path-to-configfile. This is on an ibook (OSX 10.1.5, apache 1.3.26,
mod_perl 1.26 - the apple versions)
When I try to run one of my cgi scripts - that works fine under
mod_perl without '-X' - I get the following in the error_log:
POSIX.pm: Can't locate auto/DynaLoader/dl_install_.al in @INC (@INC
contains: /Users/warren/include /System/Library/Perl/darwin
/System/Library/Perl /Library/Perl/darwin /Library/Perl
/Network/Library/Perl/darwin /Network/Library/Perl /usr/
/usr/lib/perl) at /System/Library/Perl/darwin/XSLoader.pm line 90
What am I missing? where/what is auto/DynaLoader/dl_install_.al?
[..]
I think there are more than a few problems going on here.
so let's try to unwrap them slowly.
the error occurs in the XSLoader.pm file at line 90,
which if you look at the file is
my $xs = dl_install_xsub(${module}::bootstrap, $boot_symbol_ref,
$file);
it should be noted that this could be a part of your problem,
that the XSLoader.pm file itself is kaput and garbled.
the other problem could well be as noted in the comment line:
# Many dynamic extension loading problems will appear to come from
# this section of code: XYZ failed at line 123 of DynaLoader.pm.
# Often these errors are actually occurring in the initialisation
# C code of the extension XS file. Perl reports the error as being
# in this perl code simply because this was the last perl code
# it executed.
because the 'autolaoder' file that it is looking for
dl_install_.al
makes no sense at all.
if you run nm on your copy of the DynaLoader.a
you will of course find
07fc T _XS_DynaLoader_dl_install_xsub
which is what it should have been calling for, but having
failed to find that, in the available library, perl of
course then rolls out to try and find it as an autoloadable
file of the form
dl_install_xsub.al
expecting that it is actually perl and not library code.
You may also want to look at what is going on with your POSIX.pm,
and do you have a version skew problem driven by some variation
being in /Users/warren/include which has some of the POSIX.pm file
but has gone off strangely?
Other places where all of this can get wonky is if you have say
perl 5.8.0 as your perl but have the mod_perl from the 5.6.0 version.
ciao
drieux
---
Re: Non-Perl but baffling question
On Tuesday, Feb 25, 2003, at 15:48 US/Pacific, Chris Devers wrote: [..] That looks painful. Why not just use one of these? % sw_vers ProductName:Mac OS X ProductVersion: 10.2.4 BuildVersion: 6I32 this application appears to be only distributed with Mac OS X and not with other versions of BSD-isms. [..] % uname -a Darwin barney 6.4 Darwin Kernel Version 6.4: Wed Jan 29 18:50:42 PST 2003; root:xnu/xnu-344.26.obj~1/RELEASE_PPC Power Macintosh powerpc [..] I presume that the version of the Darwin Kernel is tied to the ProductVersion? In a way similar to the solaris style that SunOs 5.6.1 was Solaris 2.6.1 ??? uname -r would of course return the '6.4' value and if there is an offset algorithm ciao drieux ---
Re: Non-Perl but baffling question
On Tuesday, Feb 25, 2003, at 18:20 US/Pacific, Chris Devers wrote:
[..]
And, now that I try it, it also looks inaccurate:
% sw_vers | grep 'ProductVersion' | awk '{print $2}'
10.2.4
%
[..]
hence for moral purity we would do:
sub get_osx_version
{
open(VER, sw_vers |) or die uglie unhappy: $!\n;
my $ver_num;
while( VER )
{
if (/ProductVersion:\s(.*)/)
{
$ver_num = $1
}
else
{
next;
}
}
close(VER);
$ver_num;
}
ciao
drieux
---
It's NOT my Fault,
the Voices in My Head Make me do these things.
Re: Form feed
On Sunday, Feb 16, 2003, at 14:52 US/Pacific, Tom McDonough wrote: On 2/15/03 21:56, drieux [EMAIL PROTECTED] wrote: On Saturday, Feb 15, 2003, at 14:40 US/Pacific, Tom McDonough wrote: I'm trying to force a form feed using perl 5.6 and os x.2 without using the format command. LPR is the line printer and it is OPEN. My program is printing continuous lines and I want to control the page break. I presume that you are using a printer with a tractor feed? As opposed to the laser-printer style? yes? and that it is locally attached? Have you pulled out the manual for it, as to what it uses for 'control sequences'. you may want to read man printcap Since what you want to ship to the printer, if it is defined in the 'ff' argument, is what you will need to ship to the printer to make it follow instructions. I think what the '\f' is talking about is the 8-bit pattern 007 or the sixteen bit pattern 017... ciao drieux ---
Re: Form feed
On Saturday, Feb 15, 2003, at 14:40 US/Pacific, Tom McDonough wrote: I'm trying to force a form feed using perl 5.6 and os x.2 without using the format command. These don't work: print LPR \007; # form feed ? doesn't work $ff = v12; print LPR $ff; # Camel book Sec 2.6.7: doesn't work print LPR \f; # Camel book page 663: doesn't work I presume that you opened LPR with something like open(LPR, |lpr $args) and that you are trying to talk to the line printer??? the ascii value in octal of 007 is 'bel' - cf man ascii, so I am not at all sure why you went there... or are you trying to write to the terminal app? I know that ^L ( control L ) will do it at the command line, if you just type it, but not from a perl script so are you targetting a terminal app? or a printer? you will probably want to peek at man stty for the stty configuration issues if a terminal app... ciao drieux ---
Re: Creating Fat XS Modules
On Thursday, Feb 6, 2003, at 09:54 US/Pacific, Mark Alldritt wrote:
Hi Folks,
I have an XS Perl module that I need to distribute in binary form as
part of
a larger Mac OS X application. However, because I want to support
Perl 5.6
and 5.8 and these two versions are not binary compatible, I'm looking
for a
way to package 5.6 and 5.8 builds of my module. Can anyone offer any
suggestions on how to do this?
the simplest way is to have your source code build
under two different perl's - if you have the usual
Makefile.pl that would normally start with
perl Makefile.pl
make
then what you can do is generate your makefile with
/usr/bin/perl5.6.1 Makefile.pl
make
do the voodoo for pulling out your 'binary only' set
then make it again with
/usr/bin/perl5.8.0 Makefile.pl
{ repeat here for the make of the binary only set }
Since it is identifying the 'perl' that is used when
spinning out the Makefile that is the important part.
You can also look at a trick we use, which is that
we have all of the perl modules in a separate place
and a 'common' architeture specific arch file that
we include into an upper level makefile that defines
which perl we are using to make the makefiles.
HTH
ciao
drieux
---
dumb 802.11g question
since apple has announced it's new 802.11g initiative with it's 17 laptop - does this mean that they will not be working on any of the 802.11a options of going into the 5Ghz range so as to avoid the 2.4gHz spread spectrum first generation phones I like the idea of 54Mbps, but if I can't use it in conjunction with my telephone ciao drieux ---
Re: Phantom Line Numbers
On Monday, Jan 6, 2003, at 15:34 US/Pacific, Christopher D. Lewis wrote: I'm writing a little toy tool to teach myself more Perl than I have used before, and I am puzzled by error messages I get when trying to run and debug it: syntax error at ./nudice-01c line 187, near sub displayResults [..] The problem is, you see, that (according to two different text editors) nudice-01c has only 304 lines [..] I would start up around line 186 to begin with. Since that could be the start of the 'real issue' and hence that it is then finding stray carriage returns that would otherwise be parts of outgoing print statements and growing the offset. As such start with looking for where you have that first sub - and work out what in that area has gone wrong. ciao drieux ---
Re: Phantom Line Numbers
On Monday, Jan 6, 2003, at 18:01 US/Pacific, Ken Williams wrote:
On Monday, January 6, 2003, at 06:49 PM, Christopher D. Lewis wrote:
displayResults begins on 130 and goes to 187, though several intended
features are not actually implemented yet -- I just wanted to see
what I needed to do to get it running. I was able to eliminate
several compile errors, but got stuck when the errors stopped giving
me clues I knew how to follow. I will have to dedicate some more
time to hunting down whatever might be wrong in these subroutines ...
I may need to make a bunch of little test apps to try what I'm
doing and see, piecemeal, what breaks and what works.
It's often useful to bring up the file in emacs and cperl-mode, and
see what it thinks of the structure. If it can't tab through the file
properly, the place it breaks is probably the location of the error.
I'm betting on an extra/missing paren/brace/bracket.
I'm a bbedit-bigot for doing Perl Development, since it has
a 'check syntax' button that has been most useful That
coupled with the 'coloured syntax' also helps visually ID OOOPSIES
like forgettting to close a single or double quote ugly - turns
the rest of the code this garish pink tone... I think the cperl-mode
in emacs will offer the later
One of the things I do when building up new stuff that
I am not sure about the general perl syntax is to BASH THAT BIT
off on the side with a simple piece of perl. again, an advantage
of the 'bbedit as perl ide' approach, since I have a bunch of
basic code templates loaded for my usual problems.
Also when building up a new set of what are 50 line subs is
the idea of making sure that one is not starting down the
trail towards wanting them in Perl Modules to begin with -
which again drives us back to the idea of 'the test apps'
that christopher was concerned about...
#!/usr/bin/perl -w
use strict;
my @arglist = qw/./;
my $got_back = new_function(@arglist);
sub new_function
{
#we wanted to do What?
}
This way the code that one is trying to build up would
have just the sub's with stock safety
sub displayResults
{
my $p;
}
stubbing that will always return something - albeit meaningless -
but when one has proven that the 'new_function' is kosher, then
one just cuts and pastes it over where it is suppose to b
the last silly that could be in play here is the usual
Apple v. Unix
line ending problem.
ciao
drieux
http://www.wetware.com/drieux/pbl/
--
This space left intentionally blank.
Re: Apple Perl directory layout
On Monday, Dec 9, 2002, at 11:45 US/Pacific, [EMAIL PROTECTED] wrote: [..] Is it really broken or is it different? Lots of folks here just tend to install their version in the correct place and leave Apple's alone. [..] Volks, do people remember WHEN 'versioned' site_perl directories became the hip-hop buzz cool thing? Given that the cut over to 5.8.0 from 5.6 will require that the non-pure-perl modules will need to be rebuilt, I'm not at all sure what the 'issue' really is? A part of the reason this is so 'not a bug' is that other vendors, noteably Sun, also do an install into their own 'private place' for the 'vendor supplied' verion of perl, so that one can choose to either run with 'vendor supplied, vendor supported' - or build and install your own version. ciao drieux ---
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, 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
---
thinking off the edge
volks, At times I need to deal with WIN32::* stuff, and thought I would ask if anyone here has done any WIN32::* development in any of the possible virtual pc products that are suppose to work and play well with OSX. The MacWorld articles while discussing interesting 'issues' were not specific about dealing with this type of, well, alternative visioning... I mean I'm not sure it's a good idea to say install something like cygwin in a virtual PC on a Mac OSX - so I thought i would ask those who may have advice... ciao drieux ---
building perl 5.6.1 on 10.1.5
volks, here is where I have problems with trying to do a build of perl 5.6.1 on 10.1.5 - and see postscript about upgrading. when I am trying to do this on the disk local to my machine the end of configure is: Press return or use a shell escape to edit config.sh: Doing variable substitutions on .SH files... Extracting Makefile (with variable substitutions) Extracting Policy.sh (with variable substitutions) Extracting cflags (with variable substitutions) Extracting config.h (with variable substitutions) Extracting makeaperl (with variable substitutions) Extracting makedepend (with variable substitutions) Extracting makedir (with variable substitutions) Extracting myconfig (with variable substitutions) Extracting pod/Makefile (with variable substitutions) Extracting writemain (with variable substitutions) Extracting x2p/Makefile (with variable substitutions) Extracting x2p/cflags (with variable substitutions) Done. If you compile perl5 on a different machine or from a different object directory, copy the Policy.sh file from this object directory to the new one before you run Configure -- this will help you with most of the policy defaults. [jeeves:~/perl/perl-5.6.1] drieux% so first off the bat I have run run sh makedepend by hand... and then I get: . makedepend: no such file or directory: makefile [145] make: *** No rule to make target `shlist'. Stop. Searching for .SH files... Updating makefile... cp: makefile: No such file or directory [jeeves:~/perl/perl-5.6.1] drieux% what I have is a 'makefile' of the form: [jeeves:~/perl/perl-5.6.1] drieux% head makefile # If this runs make out of memory, delete /usr/include lines. av$(OBJ_EXT): /usr/include/arpa/inet.h av$(OBJ_EXT): /usr/include/ctype.h av$(OBJ_EXT): /usr/include/dirent.h av$(OBJ_EXT): /usr/include/errno.h av$(OBJ_EXT): /usr/include/gcc/darwin/2.95.2/g++/../float.h av$(OBJ_EXT): /usr/include/gcc/darwin/2.95.2/g++/../inttypes.h av$(OBJ_EXT): /usr/include/gcc/darwin/2.95.2/g++/../machine/limits.h av$(OBJ_EXT): /usr/include/gcc/darwin/2.95.2/g++/../stdarg.h av$(OBJ_EXT): /usr/include/gcc/darwin/2.95.2/g++/../stdint.h [jeeves:~/perl/perl-5.6.1] drieux% These are not problems when I am trying to build on the NFS mounted file system on jeeves... Which is where I have to be to build darwin for ppc - since it has the developers tools... ciao drieux --- yes, as soon as we can iron out the glitches so that we can integrate our mac's into the single sign on solution where they will let us login though NIS,LDAP,Active Directory, without having to have accounts created local on all of them - then yes, 10.2 and we do all this over with 5.8.0
the head problem in lwp - Re: new to modules
On Thursday, August 29, 2002, at 07:20 , Phil Dobbin wrote:
[..]
Once I hear back on this I plan to download some modules and use them.
The LWP module has tempted me from the very beginning.
Remember the issue with case insensitivity on Mac OS X when installing
LWP. For more details see:
http://david.wheeler.net/osx.html
Scroll down right to the bottom and the details are there.
My compliments on the documentation and
the work around...
my path was to download the ppt perl version of head
http://www.perl.com/language/ppt/src/head/index.html
and put the personal modification into it
# Get the options.
if ( $ARGV[0] =~ /-(\d+)/ ) {
#
# drieuxish hack to allow for the old school
# head -12 file
$ARGV[0] = -n$1;
}
this way I can still do
head -12 file
vice the standard bsd style:
SYNOPSIS
head [-n count | -c bytes] [file ...]
ciao
drieux
---
Fwd: new to modules
On Wednesday, August 28, 2002, at 07:52 , Erik Price wrote: Folks, I've used Perl here and there (on my OS X box) for basic stuff, but I haven't really played with modules. I feel like I'm really missing out on something cool here. Where do modules get stored by default in Darwin? What is a good way to see which ones I have installed? (I actually haven't installed any but I meant pre-installed on Darwin.) as an exercise with File::Find I put up http://www.wetware.com/drieux/pbl/misc/findModules.txt I hope it helps. ciao drieux --- -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
build perl on HPFS+ was Re: the head problem in lwp - Re: new to modules
On Thursday, August 29, 2002, at 09:22 , Phil Dobbin wrote: On 29/8/02 at 07:31, [EMAIL PROTECTED] (drieux) wrote: [..] My compliments on the documentation and the work around... All kudos to David Wheeler. I just followed his instructions and it worked for me ;-) allow me to restructure then... Once I thought that the usual suspects of linux,emac,perl was clear proof that space aliens were taking over now I do perl on OSX so there are all these interesting sites where things align more to 'main stream apple way' or 'bsd-open-source' and it's not always clear which are the 'true believers' So thank you for extending that list... The problem I did not see directly on the page, or am I missing something, but does he do his builds on a ufs partition Since I get weirdness when I am on my apple directory, rather than building stuff on the NFS mounts... granted, under our regime, we do that as a part of the tao - since we want to have a single file server for all the OS supporting stuff for all of the OS's... So it was not until I downloaded something onto my mac and tried to do the usual perl Makefile.PL make make test make install that I ran into issues - I think it was with the 5.6.1 release... ciao drieux ---
the -R flag for perl builds
volks,
we are having a bit of an argument in the house,
with regards to the CCDLFLAGS - the build we
do with gnu 3.1.1 on solaris generates the
default of
CCDLFLAGS = -R /usr/local/lib/perl5/5.6.1/sun4-solaris-64int/CORE
whereas in the OSX build, we of course take the path
that winds through
-install_name $(shrpdir)/$
and that this extends the system and/or
environmental variables
LD_LIBRARY_PATH/DYLD_LIBRARY_PATH
when we go to compile new modules that will need to
access dynamic libraries in the canonical library paths.
Hence this merely tells anything we build dynamically
with perl that they will find our libperl.dynamic_ext
in this 'non-traditional place' - and does
not Over Ride the default system paths and/or the
appropriate environmental variables...
this is my experience, but the language of the
documentation is not 'clear' that this is actually
what goes on here. Your assistance here will be
appreciated
{ can we say a slow sunday - when we are arguing
the text of build documentation? but your assistance
will be appreciated... }
ciao
drieux
---
there has got to be something peculiar about
using experience from an OSX box to argue
about what should be done on solaris boxes
Re: Definitive Mac OS X Perl 5.8/CPAN installation instructions? (Solved)
On Monday, August 19, 2002, at 09:10 , ellem wrote: On Monday, August 19, 2002, at 11:22 PM, Sky Lemon wrote: I guess I had some aversion to it since I remember reading somewhere in the Fink pages that it's not a good idea to install stuff in /usr/local. for fink stuff yes for things you install no, you should be installing there. From what I have been able to figure out to date - the fink folks come from the linux, hence more SYS V model of the world - and hence, like Solaris, believe in using the POSIX style model of optional code goes in /opt vice the traditionalist from the BSD school who believe that it should go into /usr/local - IF it is stuff we are planning to support. The problem here is whether or not one wants to allow the 'same name' to be used more than once. As we have noticed with the 'case insensitive' file system in darwin - it can not tell the difference between 'head' and 'HEAD' - so would not be able to tell if you wanted to get an arbitrary number of lines from a file - or the header block from a webpage... The same is equally true of the 'which do we use' problem of things that are in /usr/bin v. /usr/local/bin - which the fink folks hope to some how avoid by putting into /sw/bin and then hoping that folks sort out their PATH correctly so that you call the one you want Given that they will be delivering their perl modules into /sw, one either opts to use their auto installation methods - and hence should build your version of perl to have their /sw/lib/perl5 as a part of your default INC - or you will need to make sure that a) you have the PERL5LIB exported both in your shell .profile and in ~/.MacOSX/enrionment.plist so that both your shell and GUI are aware of it b) only access them indirectly though stuff that makes sure that the 'use lib' and/or PERL5LIB is set correctly So there are some options - one just sorta has to make a choice. ciao drieux --- if you want REAL PSYCHOTIC BEHAVIOR - watch a hard corp BSD freak work the 'issues' on being Solaris/POSIX compliant as to how to build and install the gcc world into /opt/gundev rather than letting it just default into /usr/local
Hard Coding Version Rev into shebang was enving perl
On Thursday, August 15, 2002, at 11:04 , Ken Williams wrote:
[..]
I could imagine if the scripts were 'verbose' in themselves
by doing the actual assertion
#!/usr/bin/perl5.6.1 -w
use strict;
Yeah, that's how I'd do it. The advantage is that you can see precisely
which scripts are using which versions.
p0: my compliments!
sick, twisted and disturbed.
{ all qualities I desire in IT professionals! }
I honestly do tip my hat to you - since if you have the
stones to make that commitment - then you have clearly
thought out your plays!
{ to be honest, I had been kidding since that
violates some 'cardinal' rule }
p1: Should I presume that you 'devolve' code to the
#!/usr/bin/perl
if and only if you know that it is generic enough
Or only go there if and when you plan to distribute
the code to others???
p2: My concern now moves to the 'problem' that if OSX 10.2
is going to ship with perl 5.8 by 'default' - then you have
the canonical 'upgrade' problem here - IF there isn't a
'backward build out' of the perl 5.6.1 on your new servers...
Or should we presume that you have the development team
working on 5.8 for 10.2 as soon as they are available to
the apple developers - hence doing your beta with beta???
p3: So while your argument can be misinterpreted
as opposed to 'total quality control' - with the usual
evolution of code
developer - qa - customer
that you have processes in place to deal with the 'time
to market' problem in a rational and replicatable manner?
ciao
drieux
---
sub_text - myFascistHouseMate blitzed all the 'old'
versions of perl off of vladimir - I mean I had an
original perl4.035 there - granted it was compiled for
a CPU architecture we no longer have... but... I could
have 'rolled back' in case this new perl5 stuff didn't take
8-)
Re: funky libwww-perl-5.65 CPAN install
On Friday, August 16, 2002, at 07:02 , Andy White wrote: [..] p0: given the default Config.pm that opted to put everything you install into /usr/bin - yes, it will stomp on /usr/bin/head /usr/bin/head - is normally a compiled binary that came with the system - but 'get' and 'post' are not - so all you need to do is recover /usr/bin/head itself... or remake it from source code get|GET|post|POST [..] I may be misinterpretting your command here, have you tried [jeeves:~] drieux% which get GET post POST /usr/bin/get /usr/bin/GET /usr/bin/post /usr/bin/POST [jeeves:~] drieux% I think the problem becomes more obvious with: [jeeves:~] drieux% which get GET post POST head HEAD | xargs ls -li | sort 328185 -r-xr-xr-x 1 root wheel 14361 May 18 15:42 /usr/bin/POST 328185 -r-xr-xr-x 1 root wheel 14361 May 18 15:42 /usr/bin/post 328186 -r-xr-xr-x 1 root wheel 14361 May 18 15:42 /usr/bin/GET 328186 -r-xr-xr-x 1 root wheel 14361 May 18 15:42 /usr/bin/get 328189 -r-xr-xr-x 1 root wheel 14361 May 18 15:42 /usr/bin/HEAD 328189 -r-xr-xr-x 1 root wheel 14361 May 18 15:42 /usr/bin/head [jeeves:~] drieux% darwin seems to be 'mostly case insensitive' in it's file name space. in that it views head HEAD Head as being the same file... but strangely enough does not 'get' heAD and HEad as being a similar player ciao drieux ---
Re: Tk and X
On Thursday, August 15, 2002, at 01:15 , Kristofer Wolff wrote: is it now possible to write Perl/Tk code on MacOSx :-)) I read about including a second wm - ... is that the way i have to go ? yes, there are several good Xserver's out there, my pet favorite is from www.tenon.com - so that would give you an Xwindow'd world to play in for the simple Perl/Tk solutions. there are also a couple of efforts afoot to get a more effective interface between Mac and Perl such as the Camel Bones project. you might try to search the archives here for more on those - as I seem to have lost my references ciao drieux ---
Re: Anyone know what Perl Jaguar is coming with?
] of /sw - the spawn of /opt - which was the posix way[3] - it would seem that we will need to rebuild perl to include their section as a part of the INC in perl - which can be done if you include their path section at the question Enter a colon-separated set of extra paths to include in perl's INC search path, or enter 'none' for no extra paths. which I did with the solaris build to include the /usr/perl5 stuff as noted above Just in case Sun opted to ship anything that would be targetted at their original notion, and/or, into the vendor_perl sub directory as occurred with the redhat 7.3 release of perl so all I really want to know is what is the canonical orthodox perl way as executed in the canonical orthodox apple way?[4] that I should be doing these builds of perl for darwin.[5] ciao drieux --- foot notes: [1] read as 'Spawn of Satan' [2] op cit supra 1 [3] op cit supra 2 [4] I am still working off enough bad kharma as it is... [5] God's One True, Holy and Divine Ordering of the Cosmos ps: Why does it not surprise me that PerlGeeks have 'religious wars' over whether or not the bumper sticker philosophies are truer than the pre bumper sticker philosophies but I guess it could be worse...
Fwd: Anyone know what Perl Jaguar is coming with?
On Thursday, August 15, 2002, at 06:55 , Kay Röpke wrote:
On Thursday, August 15, 2002, at 03:12 PM, drieux wrote:
so all I really want to know is
what is the canonical orthodox perl way
as executed in the canonical orthodox apple way?[4]
The orthodox perl way is laid down in the hints file for your favorite
(most
despised ... ) type of system.
I use to have prejudices, now I just hate them all
8-0
I had been trying to avoid becoming 'the perl guy' -
the keeper of the canons of what rev of perl is stable,
what modules we just have to have from the CPAN etc...
{ just as once I tried to avoid being the 'gcc guy' - but
you know how that goes - if it is a tool set you need, and
no one else steps up to the plate, one becomes the 'subject
matter expert' by default... }
So this is rather the 'good news and information' set that
comes with using open source solutions the good news
is that you have the source and can rebuild it - the
information is that you need to stay on top of the 'good news'
[..]
The darwin hints file says:
If prefix is empty use non-system directories, i.e.:
# Default install; use non-system directories
prefix='/usr/local'; # Built-in perl uses /usr
siteprefix='/usr/local';
vendorprefix='/usr/local'; usevendorprefix='define';
# Where to put modules.
privlib='/Library/Perl'; # Built-in perl uses /System/Library/Perl
sitelib='/Library/Perl';
vendorlib='/Network/Library/Perl';
If prefix is /usr replace the system perl.
THUNK! why didn't I think about the 'hints'
thank you! I hope the coffee kicks in...
If you don't trust automated software updates
I think its more a case of 'trust but verify'
the problem of course has been the 'transitional periods'.
various 'vendor supplied' versions of perl have come without
the USE_LARGE_FILES definition - which means that things like
if( -f $file ) {
}
'fail' if $file happens to be bigger than 2Gigs...
In like manner - on our linux boxes - red hat has been
upgrading with things in the 'i386' architecture - so
one can not just blindly take 'the defaults' if your machine
returns i686 - and hence your new build of perl will not,
by default have the right sets of paths in INC...
So one of the obligations is that 'all perl code will work'
hence IF the vendor supplied version is not built, as
the default darwin is built, with
Compile-time options: USE_LARGE_FILES
then we have to rebuild it...
So far the Mac side of the house seems to be reasonable enough.
That I have been able to avoid having to do any specific builds
of perl - but will most likely have to do so with the 5.8.1 release...
So i thought I would just start planning ahead.
[..]
ciao
drieux
---
Re: the enving perl issues - was Re: Anyone know what Perl Jaguar is coming with?
On Thursday, August 15, 2002, at 07:03 , Kay Röpke wrote:
[..]
As 'developers' are a degenerated bunch of animals, they normally
keep their pack close to them.
What I mean is: their home directory.
a useful strategy, and a reasonable assertion about
developers in general... 8-)
[..]
You don't develop on *production* servers, that's what development
systems are for.
[..]
I for my part wouldn't sport any development software on production
hosts, without being sure that 'users' (programmers?) can cope
with pathnames ;-)
[..]
This appears to be a part of the complication as folks
move into OSX without the 'traditional unix' background
and things are a bit different than the simpler 'apple way'
I think if we make a distinction between the two basic
types of perl developers:
a) who are working on the 'perl code' itself
eg perl5.X.Y XOR perl6
b) those working in the applications and Modules
It will help use sort out which group we are 'poking fun at'.
The former ABSOLUTELY need to have a safe play space - just
as the IT staff needs that 'safe place' to verify that it
is time to 'upgrade' to the next stable production release
of perl M.N.P Whereas many IT and Network Operations Center
staff at times do not have the luxury - and have to 'code on the fly',
pending the ECO that will 'fix' the issue.
but this should not change the simpler equivolency of
/usr/bin/perl == /usr/local/bin/perl
so that the #! will 'just work'. This prevents the need to deal with
'resolve what interpreter should
take this text file and make it execute'
types of tricks. When the 'code' goes to production. I think
most of us have 'development environments' - up to and including
a fully distinct %ENV stack of variables that do not point at
the canonical env...
given that some OS's solve all of this by not having
a #! internally defined reference to the interpreter, and do
all of that with 'suffix mapping' - hence one should use *.pl or *.plx
for those files that the #! is merely a 'comment' that is discarded,
I find it just 'simpler' to have the simple equivolencey.
{ both as the SysAddGuy, and as the CoderGuy...}
In the 'long run' - I think more of the 'traditional mac-hacking'
will need to adopt your vision of 'mac as production servers and
production release desk top units' - and go beyond the simpler
and easier days of
my box, my mistakes, Oopsie
I will confess that I have not kept up with the macPerl side - and
was concerned when I learned that it had stalled out at around
perl 5.4(???) - correct me if I am wrong. I will be pleased if
they are up to some 5.6.1 release - at least.
ciao
drieux
---
Re: Anyone know what Perl Jaguar is coming with?
On Wednesday, August 14, 2002, at 04:53 , Sherm Pendley wrote: On Wednesday, August 14, 2002, at 04:20 PM, ellem wrote: I wonder if an upgrade will bring my Perl to 5.6.0 again (which wouldn't be the worst thing that ever happened to my Perl install) That depends on where you installed your copy. If you overwrote the factory copy, then as upgrade will overwrite your copy. If you installed your copy elsewhere, such as /sw or /opt for example, the upgrade won't harm your copy. which leads me to the question about installing perl in the 'traditional' () /usr/local as I just noticed that the factory install of perl set up a config that seems to have allowed me to stomp on /usr/bin/head since it is installing into /usr/bin ciao drieux ---
Re: Launching a Perl file with Cron on OS X?
On Wednesday, August 7, 2002, at 07:15 , Ian Ragsdale wrote: On 8/7/02 8:06 PM, Noah Hoffman [EMAIL PROTECTED] wrote: Does anyone know how to do this? I've added my lines to the crontab file for root in /private/etc. They look something like this: 002 * * * root perl /Volumes/Builds/Development/build.pl My guess is that perl is not in your path when cron runs the script. Try changing that to '/usr/bin/perl' and see if it works. alternatively one could change the permission bits chmod 755 /Volumes/Builds/Development/build.pl and just 'execute' it in the form 00 2 * * * /Volumes/Builds/Development/build.pl I would highly recommend that you do NOT try to have it pop up a window. Letting things run in crontab means that they will send you email - assuming that you have sendmail running - and you can read the 'output' in the morning, when you are sane and sober. alternatively you can just have it dump off to a log file and check that logfile when you have the time and inclination. recommendations would include /usr/local/etc/project_name in due regards for the old BSD's or into /var/logs/project_name or . ciao drieux ---
Re: Launching a Perl file with Cron on OS X?
On Thursday, August 8, 2002, at 12:37 , Noah Hoffman wrote: In crontab, I have [EMAIL PROTECTED] but I'm not getting email either. Do you know what I'm missing? I thought I was getting the 'cannot create temp file' error because I wasn't root, but the crontab line is as follows: 16 12 * * * root open Volumes/Builds/Development/perl.pl.command Any thoughts? p0: set your cronjob up as just a cronjob - and not an open .command style - this way it will 'just run' p1: have it chdir /tmp - where it should be allowed to get away with almost anything - better there than to have it sitting on / or in some unknown place ciao drieux ---
AFP modules in Perl
volks, it is not clear to me from a quick search of the CPAN that there is a simple set of AFP modules that I can use to demonstrate interoperating between Mac OSX and older versions of the Mac OS. any recommendations will be appreciated. ciao drieux ---
Re: about .command and .term
On Monday, July 15, 2002, at 07:36 , Randal L. Schwartz wrote:
[..]
Oooh. S3kr3t Mag1c instructions! Where is this documented?
That's part of what frustrates me the most about OSX. It's like
OS9... people pass around folklore instead of being able to just say
man foo as on real unix to read the whole story.
[..]
you need to have friends who will keep you abreast of
where the majik hides:
http://www.macdevcenter.com/pub/a/mac/2002/03/26/terminal_four.html
bob sent me that as the 'clue fairy' since we have been working
on the question of how to play in this space - as well as whether
there will be an alternative to the cultural myopia of Perl/Tk
that will be sub-classed appropriately to talk natively to the
Aqua interface...
The irony was that I had the 'coffee break moment' that these
*.term
files were merely XML 'plists' - and hence that one could build
an XML_parser/configer that would generate them Or simply
adopt the 'template' solution of setting the 'EXECUTE_ME' target
and the perl equivolent of the sed for
sed 's/EXECUTE_ME/'${CMD}'/' $template_file $new_file
as we did in the dark days of /bin/sh scripting
ciao
drieux
---
about .command and .term
volks, I just found out that I can reset some of my perl scripts to run as 'double clickables' into a terminal window if I set them up as foo.command which is mostly OK, since they appear to run with command ; exit but there are times when I would like to have something that runs as command without the 'auto' exit is there a way to do this with foo.term which seems to have a way to save a 'terminal session' () What I am trying to work around here is an extension to our dump2disk solution so that we can start dumping our OS X boxes over the net to the dumpHost like all the rest of the unix boxes - since there appears to be some limitations in Retrospect 5.0 with this type of 'network' solution We normally run our dumps on the other machines from cron - but we have the 'work around' for 'dump now' and I want a quick improve for that which is MacIsh while I sort out the camel-bones v. MacApp solutions. ciao drieux ---
Re: Dumb Bunny Future Time Problem
On Wednesday, June 26, 2002, at 11:40 , _brian_d_foy wrote: In article R01050300-1015-570E291E893611D6B5E3000A2794A806@[192.168.1.100], Bruce Van Allen [EMAIL PROTECTED] wrote: Just a thought: what time zone are you in? Is 7 hours the differential between your local time and GMT? Might be something to poke into... when i had the problem, the Makefile had a mod-time about 4 hours in the future. i'm using the US/Central time zone, so that doesn't explain it for me at least, as far as i can see. being in Pacific - I should have been only Six hours into the future - and I would at least have been consistent with brian's position... so yes - the GMT offset was an idea... ciao drieux ---
Re: Dumb Bunny Future Time Problem
On Wednesday, June 26, 2002, at 09:17 , _brian_d_foy wrote: [..] if i let Stuffit uncompress the tar ball, then look at the mod times everything looks fine. I'm not 'intervening' in any way that I know of - so. how do I 'let Stuffit uncompress' ? All I do is click on the URL in OmniWeb - and it downloads the tarball and alladin does its two step pass through it - leaving me the original foo.tar.gz foo.tar foo (as a folder) so somehow it went away, but not because i knew how to fix it. *shrug* Well here is the problem in more unpleasantry. I do the make dist load the *.gz it up to the server then download it - and let the StuffIt unwrap it - and i have a folder on my desktop - I use a terminal to go in and check the date stamps - they are - on average about 7 hours into the future from when the date stamps are on the folder I would generate by hand from the tarball with zcat *.gz | tar -xf - This is only a problem when we are doing 'hot turn arounds' where I code up a fix - and hurl it It really does not matter today that the time stamps will be off on yesterday's tarball but today's tarball will unwrap with the same problem. ciao drieux ---
About Updating the CPAN about darwin testing?
volks, Ok, so I am new to all of this, and blithely naive - but I saw a trick on the beginner's mailing list with use Inline::Files; had to do some hunting to get the Filter::Util::Call and would like to point out that - yes, they build, and run on darwin so that we can start getting people aware that Yes, that TOO builds and runs on darwin ciao drieux ---
an alternative for reading news was Re: Things I hate about my Mac
On Thursday, April 18, 2002, at 06:35 , ellem wrote: How would _you_ do it Perl? What Modules? That sort of thing. (PS all suggestions are welcome -- but I'd sort of like a project to do) have you thought about the simpler idea of running webnews on your webServer and playing 'skip past the reader on the host'? from the top of webnews.cgi: #! /usr/bin/perl ## # # Load configuration from this file: do '/home/webnews/webnews.conf'; # ALL OTHER CONFIGURATION CHANGES SHOULD BE MADE IN THE ABOVE-NAMED FILE. ## # ciao drieux ---
Why this list is the Appropriate Form for what is best in perl
volks,
let's step back and look and the common ground between
two reasonably diverse groups -
The sterotypical MacHead comes to the party with a
'user friendly, programmer hard' Graphical User Interfaced
approach to products
{ ourResidentMacHead whined back in pre-OSX, 'but I could fix
the code if I had the source' and has since fallen
under the spell of 'artistic' webStuff with cool GUI
front ends that do all the heavy lifting to create
cool webStuff so hasn't a clue any more what the html looks
like if it has to be debugged by hand }
The sterotypical UnixGeek comes to the party with the
general quizical look at GUI's - since they would prefer
to have daemons do it all - since why would one want to
have to 'interact' with the computer?
{ myJackBootedFasicstHouseMate will give up his sun
open desk top when you pry it from his dead cold hands
even IF it is now merely the xServer layer. These are not
xterms - these are cmdTools ok, so we have to remind
him that there are more than 3 verbs in ftp}
As such OS X offers the native place for these two divergent groups
to get together and work out what is best in life.
One of the core structural problems with perl, like 'c' before it,
is that it doesn't come with the 'training wheels' of being a
'strongly typed' language - and unfortunately, leaves the beginners
without the protection of being prevented from doing folly. As such
the FNG's are left to their own devices to develop their own experience
about how to discipline themselves.
Those of us who started in god's true computer languages[tm]
/bin/sh, sed, 'c', lex, yacc#heathen may debate this point elsewhere
and were never sure about 'awk' - that new language - have the luxury
of knowing why we opted into perl when it came of age, but have not
always been as clear about 'the real lessons learned' under the
tutelage of life in the wilderness
Much of the early apple work was done in 'pascal' - in part because it
helped protect coders and we still see the callbacks through
both the carbon and cocoa foundations to those earlier roots. While
at the same time the whole 'marketed culture' of Apple has been about
'do your own thing' - especially if as a coder, 'your own thing' fully
complied with all of Apple's Rules
If anything - what better place to work out the process of what is
best in life? Given a GUI system far in advance of anything else out
there, on top of a core OS that remains the principle guts of the
whole of the internet And all of this in the context of the
'complete glue language from hell' - perl can be a script, a library,
OO or proceduralist, interfaced to 'RealCodingLanguages[tm]' or as
a stand alone It does webStuff, Internet Stuff, database stuff,
parser stuff, system stuff, daemon stuff, Stuff Stuff!
{ ok, it still can not make coffee }
As the p5ee project is pointing out - the ubiquity of perl makes it
a much more reasonable candidate to do what java wants to do - but
without the call to be a 'strongly typed' language...
The problem of course then becomes - if the OS is not going to
provide the discipline, and the Computer Language is not going to
provide the discipline - then it is left to the coders to pass
along the wisdom of the tribe - not merely in the 'hairey ape'
approach of 'me big, you small' - but the 'h, that would hurt'
levels of clarifying what we have learned
Those who ask questions have already admitted that there exists
that which they do not know - we should complain at them for not knowing?
That someone else may have an alternative path to a solution
should come as a surpise to anyone here? If it is better, EVOLVE.
Perchance the most interesting part of the process is the person
who has NOT become so 'ingrained' in why this is the only way to
solve FOO and who's innocent question breeds - well - the
correct implementation of Perl
ciao
drieux
---
For those of you new to the 'milSpech' token 'ROE' - there are
really two in the tribe:
a) those promulgated downward by the chain of command
{ outside of larry wall, who can generate these? }
b) those passed along by 'the names' to 'the cherries' so that
the 'cherries' have half a chance to live long enough to
become 'names' and get to 'di-di' back to the world at
the end of the tour.
or as we say, any war story that survives to the second generation
carries with it survival knowledge, respect it, and survive
Re: Problem Sovled Re: Problem running perl cgi scripts
On Sunday, April 14, 2002, at 07:21 , John Buono wrote: [..] When I created my scripts I used BBEdit, but did not set the type of file to Unix, I let it remain the default of Macintosh (well I was on a Mac). I discovered that if the scripts are in Mac test format, they will not run, and you get an internal server error, that says the file can not be found (real good error message). thanks! I opted to save all of them to 'unix style' which is to have the EOL as '\n' vice the traditional mac style '\r' or the canonical dos two byte '\r\n' - since that way they are good to go either way at least in OS X and *nix boxen. rule of thumb: target the target server ciao drieux ---
scribble and it will be a production release - was Re: [Way OT] mod_perl stopped working...
On Sunday, April 14, 2002, at 06:21 , Bill -Sx- Jones wrote:
--boring, cautious, obvious over commented code--
Nothing wrong with being OVERLY cautious, especially if YOU expect to
understand why you did what you did months or years later.
I wrote a quick hack once to fix a short term problem - three years later
that code is STILL in use :( I can still hear them mumbling, late at
night, when the moon is full...
the good news - it was written in perl
{ have you ever tried to provide name space integrity with say
a /bin/sh library of functions with more than 8 coders? }
the information - management underestimated the duration of the project.
general rule of thumb,
If you scribble it,
It will be in the next release
hence
code like you will have to maintain it at Oh-Dark-Hundred
on a vt52 dial up with only sed as your editor
ciao
drieux
---
Re: scribble and it will be a production release
On Monday, April 15, 2002, at 07:43 , Bill -Sx- Jones wrote:
On 4/15/02 10:34 AM, drieux [EMAIL PROTECTED] wrote:
on a vt52 dial up with only sed as your editor
Yes - and THAT is why I only use a Mac :)
So I don't have use vt52 OR sed;
my complements to your good fortune!
But given that at times I have scrambled Jeeves, my MacOSX
box - and had to scramble back through the ssh connection
from some other box - and have a polite 'chat' with code
that should have worked, honest,
it shouldn't have done that.
you will forgive me for retaining 'the fear'
Don't get me wrong - GUI's are Great, they are Cool, they
have their place in the inventory I was happy to do
my 'intro to assembler' on the mac... even if janisch
thought I might not be taking it as seriously when I
turned in homework assignments in High Gothic Font ...
{ ok, so I blame that on the fact that in the eighties
it was fun to have something other than line printers...}
But since folks are using OSX boxes as web servers and
not merely as the upgrade for their desk top - there are
gooder habits to collect that come from a 'leave it alone
on the serve' that most 'mac' point and clickers are just
coming to get their head around...
ciao
drieux
---
Re: scribble and it will be a production release
On Monday, April 15, 2002, at 08:59 , Kee Hinckley wrote: At 8:36 AM -0700 4/15/02, drieux wrote: If anything the fact that they opted to go for the plain jane vt100 mode is the 'warm fuzzy' - no need to worry about esoteric and arcane 'termCap/termInfo' settings for remote hosts Actually the terminal setting lies. It is definitely not a vt100. It does color and it appears to do vt102 sequences as well. Looks more like an ansi emulator (although if you set it to that, it has some problems clearing the full screen). interesting - I have never thought about trying for any colour in them. In the preferences under options I have only the Translate newlines ticked. I never went to set any of the Text and Colour Stuff... so I shall defer to your experience... but I do get some stuff in colour on the linux boxes but that can be turned off by disabling ansi colouring which may help your 'full screen' issue ciao drieux ---
Re: Documentation Issues - was Re: [Way OT] mod_perl stopped working...
On Monday, April 15, 2002, at 10:54 , Randal L. Schwartz wrote: [..] Now, the next step would be to write a book that is how to spend your *second* 40 hours with Perl :) while that sorta sounds like a joke - it might help some of the folks I know - sober as a judge may I request an official volume or N on: How to recover from having adopted peculiar coding habits you picked up on the net and should never have thought were a reasonable approach to solving the problem. Also, say something on the line of: Socially acceptable things to do while not perl hacking around. I think if some of my Freaks read it in a book, it might look a bit more official ciao drieux ---
Re: good practice subroutine coding in web context
On Monday, April 15, 2002, at 02:40 , Ryan wrote:
--At 4/15/02 4:25 PM -0500, PK Eidesis wrote:
sub makeCalendar {
$type = _;
if($type eq month) {
print all the code for a monthly calendar;
elsif($type eq week) {
print all the code for a weekly calendar;
elsif($type eq year) {
print all the code for a yearly calendar;
}
}
Personally, I'd change all those prints to returns -
We agree that they should be 'returns' but why not
the usual sort of predef approach
sub makeCalendar {
my ($type) = _;
my $retString = ''; # safety set
if($type eq month) { $retString = all the code for a monthly calendar
;
} elsif($type eq week) { $retString = all the code for a weekly
calendar;
} elsif($type eq year) { $retString = all the code for a yearly
calendar; }
$retString ; # the default value would be returned on error case
}
Assuming that the branch tree is built in the order of
expected usage - or one might go with the fact that the
hash is the core of the perl reality space - and one should
have a reasonable expectation that it will be kosher:
sub doCal {
my ($type) = _;
my %retHash = (
'month' = 'all the code for a monthly calendar',
'week' = 'all the code for a weekly calendar',
'year' = 'all the code for a yearly calendar',
);
$retHash{ $type }; # defaults to empty if not used
} # end doCal
Since this is when the player starts thinking in terms of:
sub doMon { my $string = all Your Months Be Mine; }
sub doWeek {my $string = all Your Weeks Be Mine;}
sub doYear { my $string = this is the year line;}
sub doCal {
my ($type) = _;
my %retHash = (
'month' = \doMon,
'week' = \doWeek ,
'year' = \doYear ,
);
no strict 'refs'; # must skank around the ref indirection here
my $retString = $retHash{ $type }-()
if ( $retHash{$type } ); # if we have it
$retString ; # return what ever the function passed
} # end doCal
cf:
http://www.wetware.com/drieux/CS/lang/Perl/Beginners/HashSwitch.txt
ciao
drieux
---
Value of Orthodoxy: was Re: mod_perl stopped working...
On Sunday, April 14, 2002, at 04:34 , Ken Williams wrote:
On Monday, April 15, 2002, at 03:49 AM, BeardedDragon.org wrote:
Should it matter what language a person programs primarily in? When
dealing with corporate coding standards, you should try and make it easy
to read.
[..]
I should have been more clear. I think you're supposing that there's
some lingua franca in which people can program and all be understood by
each other. I'm proposing that no such thing exists. Furthermore, there
is code such that:
[..]
Code A:
my $i;
my $n = scalar array;
for ($i = 0; $i $n; $i++) {
$array[$i]++;
}
Code B:
foreach (array) { $_++ }
if all you are doing is a one liner, why not simply
$_++ foreach(array); # increment all elements of array
it clearly saves on the spare 'code typing' of the curly braces and
reminds me what I was doing
eg:
lineswords bytes file_name
5 17 78 /tmp/f1 - c style
1 8 56 /tmp/f2 - my flat line w/documentation.
1 2 22 /tmp/f2 - my flat line without
1 5 27 /tmp/f2 - your 'Code B' with required ';'
Person X: a C programmer with no Perl experience
Person Y: an experienced Perl programmer
It would seem that if one were trying to pass along wisdom and
experience, you might have a demo of why the 'traditional, mainstream
Orthodox'
perl method would be that much simpler to do, hence save the coder the
time of typing out all the 'additional stuff'...
And since of course they are working in the mainstream OSX world,
then they of course natively understand the value of 'thinking orthodox'
and the beauty of elegance already
You might also want to talk in terms of performance costs. If this
or that 'old style c code' model 'cost'. As was politely pointed out
to me about my habit of frame out in 'subs' even if the sub is not
likely to be called more than once in the 'main loop' since I
am of course expecting the 'c' compiler to 'inline' where possible.
But then again, the reason that the Parris Island Boot Campers
learn the immortal
This is My Rifle,
This is My Gun,
One is for fighting,
and one is for fun
is to help the young understand which is the tool of their profession,
and which is what they can deal with on liberty call OR as I tried
to port that to software developers,
This is my Compiler,
there are many like it,
without me, my compiler is useless
without my compiler, I am useless
but they never got the part about 'deal with on liberty call'. strange
people software folks
ciao
drieux
---
sekret sub_text:
lou - thanks for the URL - sorry you had a project lead who
had so little life experience as to not understand leadership.
canonical perl IDE for Mac OSX
On Sunday, April 14, 2002, at 05:59 , Bill -Sx- Jones wrote: dealing with corporate coding standards, you should try and make it easy to read. No exceptions or special cases, if it can be avoided. You want I had thought the x operator strange the first couple of times I ran over it... -Sx- :] ok, so we had to learn the hard way that OSX really wanted to be installed on an apple file system and not on a unix one So everyone has transitional moments. Fortunately for me, my UnterStumpenFumbler was ok with the fact that for me, I have to know what the 'Orthodox Perl' way of doing foo would be I taught him about how to do things the fleet way, and how to understand Orthodox v. Conservative v. Reform, and what to do in classic /bin/sh init scriptology when there is no perl yet loaded on the machineand he offered me WACKO PERL tricks... So the obligatory silly: Is there an Orthodox Perl IDE for OS X? in unix I feel safe with vi. but I use bbedit and have found that it is leaking towards being almost a full bore IDE but I thought I should check with the canonical list. ciao drieux ---
About testing cgi at command line
volks,
when I run
perl Skank.pl
on the command line on my solaris and/or unix boxes it takes
the default path through the code and dumps out what the html
would be - but when I run the same code on my OSX box it dumps
out a weird case:
[jeeves:/tmp/drieux/perl] drieux% perl Crap.pl
(offline mode: enter name=value pairs on standard input)
^C
[jeeves:/tmp/drieux/perl] drieux%
and I have to pass it a ^D to get it to woof out the page
[jeeves:/tmp/drieux/perl] drieux% perl Crap.pl
(offline mode: enter name=value pairs on standard input)
^D ---this is not 'visible' but what had to happen
Content-Type: text/html
!DOCTYPE HTML PUBLIC -//IETF//DTD HTML//EN
HTMLHEADTITLEUntitled Document/TITLE
/HEADBODYFORM METHOD=POST
ENCTYPE=application/x-www-form-urlencoded
INPUT TYPE=hidden NAME=crap VALUE=here is a quote quot;this Quote
quot;.INPUT TYPE=submit NAME=.submit
/FORM/BODY/HTML
[jeeves:/tmp/drieux/perl]
is this a feature or a bug?
I have not turned on the apache web server, running plain jane
OS X, 10.1.2 and what ever the default perl 5.6.1 load came off
the CD Rom...
ciao
drieux
---
[jeeves:/tmp/drieux/perl] drieux% sed 's/^/### /' Crap.pl
### #!perl
### use strict;
### use warnings;
### use CGI qw(:standard);
###
### my $page_o_html = '';
###
### $page_o_html .= header();
### if(param()){
### $page_o_html .= param('crap'), p();
### } else {
### $page_o_html .= start_html;
### $page_o_html .= start_form();
### my $crap = 'here is a quote this Quote.';
### # $page_o_html .= Hidden file: $crap;
### $page_o_html .= hidden(-name ='crap',
### -value = $crap);
###
### $page_o_html .= submit(), p();
### $page_o_html .= end_form();
### $page_o_html .= end_html;
### }
###
### print $page_o_html \n;
[jeeves:/tmp/drieux/perl] drieux%
Re: About testing cgi at command line
On Friday, April 12, 2002, at 11:27 , Timothy A. Canon wrote: Use the -no_debug pragma: use CGI qw( -no_debug ); For more info, check out: http://stein.cshl.org/WWW/software/CGI/#import #- On Friday, April 12, 2002, at 11:25 , Bill Stephenson wrote: on 4/12/02 12:59 PM, Alex S at [EMAIL PROTECTED] wrote: I believe there's a way to disable the prompting. The book says to pass empty parameters. Something like perl Skank.pl '' My complements to both for two paths that both add value. the strange part is that this only showed upon the OSX side, but not on the other boxes - is OSX more 'perl compliant' Also a special thanks to Bruce - now I 'get it' about using the command line 'debug mode' testing [jeeves:/tmp/drieux/perl] drieux% perl !$ perl Crap* (offline mode: enter name=value pairs on standard input) crap='here is a quote this Quote.' ^D Content-Type: text/html here is a quote this Quote. [jeeves:/tmp/drieux/perl] drieux% ciao drieux ---
Upgrade to cgi 2.57 or beyond?
On Friday, April 12, 2002, at 11:29 , Rick Frankel wrote: [..] It's related to the installed version of CGI.pm, from the changelog: Version 2.57 1. Added -debug pragma and turned off auto reading of STDIN. is the issue. Just found out that the webServer and the OSX box are running 2.56 while my linux and solaris boxes I thwacked over to 2.752 so should I just pull the source over and do the make *.PL make make test make install or. ciao drieux ---
flock on shared file systems.
On Saturday, April 6, 2002, at 07:18 , Ken Williams wrote:
On Saturday, April 6, 2002, at 01:23 PM, Nathaniel Irons wrote:
I just noticed that my mail scripts' exclusive locks don't command any
respect when the files to which they're writing live on an HFS+
AppleShare volume, in /Volumes/. Should I be surprised by this?
Probably not - it doesn't work over NFS on most other Unix environments
either. I'm not too familiar with AppleShare, though.
Network file locking strategies are best implemented in a way
that only those applications/daemons which are going to be
accessing files on the shared file system all agree to whether
it is an advisory lock or not.
Under SunOS we had the fun that the x86 variant machine had no problem
recognizing that a 'file lock' had been put down by the sparc machine
- it just never felt that it was anything more than 'advisory' - and
would go ahead and grab the house phone line and call up its UUNET
neighbors { this was the same code base compiled once for sparc
and once for x86... }
So if you are trying to 'exclusively lock' files from other
daemons/applications - you have to find out what they consider
to be full on 'exclusive locks' first - otherwise code around
the problem as best you can.
ciao
drieux
---
about perl modules on Mac OS X
I just tried this and got the strange error: make: *** Warning: File `llyrisWeb.pm' has modification time in the future (2002-03-31 19:37:50 2002-03-31 11:40:45) I am using the default StuffitExpander ciao drieux ---
Re: about perl modules on Mac OS X
On Sunday, March 31, 2002, at 12:29 , Phil Dobbin wrote: On 31/3/02 at 12:11, [EMAIL PROTECTED] (drieux) wrote: I just tried this and got the strange error: make: *** Warning: File `llyrisWeb.pm' has modification time in the future (2002-03-31 19:37:50 2002-03-31 11:40:45) I am using the default StuffitExpander Your timezone isn't set to GMT by any chance? the command line gets me: [jeeves:~] drieux% date Sun Mar 31 12:43:14 PST 2002 [jeeves:~] drieux% [..] the silly part is that I had just made the tarball with make dist on a solaris box - pushed it to my webpage - downloaded it with OmniWeb - which invoked the plain jane StuffitExpander - but when I copied the tarball back over to the solaris box and do zcat tarball | tar -xf - the same is true for the linux box... the only one to get it weird was the OS X box. Must be an issue in stuffItExpander - since I had the dopy thought, hey, why not repeat it at the commadline and it comes out with the expect results. Sorry ciao drieux ---
