Re: The Agony of GMP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dennis those who suffer the same prob, If you are on Intel Macs, try recompiling reinstalling GMP as follows: tar jxvf gmp-4.2.1.tar.bz2 cd gmp-4.2.1/mpn/x86 rm *dive_1* */*dive_1* */*/*dive_1* */*mode1o* */*/*mode1o* cd ../.. sh configure --build=i686-apple-darwin --enable-cxx make make check sudo make install I also blogged this issue as follows (it's in Japanese, though) http://blog.livedoor.jp/dankogai/archives/50712932.html Hope it helps. Dan the Frequent User of BigNum On Dec 19, 2007, at 23:32 , Dennis Putnam wrote: I am trying to install Net::SFTP and it has been a major trial of patience. I finally get it working on one of my servers and now am trying to get it on another. Unfortunately I have run into a brick wall on the 2nd server (both are running 10.4.10) with no clue why they are different. The crux of the problem is that I cannot install Math::BigInt::GMP on this server. It appears there is a problem with the installer but yet this did not happen on the other server. They key on the other server was to install GMP using macports 'port' command. I did the same on this server and all seemed to go well until I tried to install BigInt. I am getting the following: Running make for C/CH/CHIPT/Math-GMP-2.04.tar.gz Has already been unwrapped into directory /Users/admin/.cpan/ build/Math-GMP-2.04-nSlAjY Has already been made Running make test PERL_DL_NONLAZY=1 /usr/bin/perl -MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/arch') t/*.t t/gmppm..Can't load '/Users/admin/.cpan/build/Math-GMP-2.04- nSlAjY/blib/arch/auto/Math/GMP/GMP.bundle' for module Math::GMP: dlopen(/Users/admin/.cpan/build/Math-GMP-2.04-nSlAjY/blib/arch/auto/ Math/GMP/GMP.bundle, 2): Symbol not found: ___gmpz_mul_2exp Referenced from: /Users/admin/.cpan/build/Math-GMP-2.04-nSlAjY/ blib/arch/auto/Math/GMP/GMP.bundle Expected in: dynamic lookup at t/gmppm.t line 7 Compilation failed in require at t/gmppm.t line 7. BEGIN failed--compilation aborted at t/gmppm.t line 7. t/gmppm.. Dubious, test returned 255 (wstat 65280, 0xff00) No subtests run Can someone help me out with this? TIA. -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (Darwin) iD8DBQFHaS1eErJia/WXtBsRAnDCAJ9YBwhGxvfWewPEJIeC6DXouJOoxACfeDdo okzCKgH5aVbdmBxlDnVG69g= =yDP5 -END PGP SIGNATURE-
MacOSX::File 0.71 released!
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Iyanaga-san,
On Aug 19, 2005, at 14:54 , Iyanaga Nobumi wrote:
Hello,
I downloaded and installed MacOS::File 0.70, but was unable to run
psync.
[snip]
I could run psync which came with the version 0.69. The first
lines are different:
0.69:
#!/usr/bin/perl
eval 'exec /usr/bin/perl -S $0 ${1+$@}'
if 0; # not running under some shell
#
# $Id: psync,v 0.67 2004/05/03 14:53:30 dankogai Exp $
#
[snip]
0.70:
#
# $Id: psync,v 0.70 2005/08/09 15:47:00 dankogai Exp dankogai $
#
Mia culpa. make test does not check to see if shebang is rewritten.
I have just released MacOSX::File 0.71 as follows:
=pod
=head1 NAME
MacOSX::File - A collection of modules to manipulate files on MacOS X
=head1 AVAILABILITY
http://www.dan.co.jp/~dankogai/cpan/MacOSX-File-0.71.tar.gz
and CPAN near You
=head1 CHANGES
$Revision: 0.71 $ $Date: 2005/08/19 06:11:26 $
! bin/psync
Addressed: #!/usr/local/bin/perl missing, causing unsuable
script being installed. Ouch!
Message-Id: [EMAIL PROTECTED]
! bin/psync
POD fixes by Jean-Louis Fuchs
Message-Id: [EMAIL PROTECTED]
=head1 AUTHOR
Dan Kogai [EMAIL PROTECTED]
=cut
Dan the Maintainer of MacOSX::File
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (Darwin)
iD8DBQFDBXqzErJia/WXtBsRAu3FAJ97/g2lTfbwTC/2bf6OJLZ8syhwIQCffqB3
+yGZe4UuOMp+dY5UHF7hBYI=
=eI6r
-END PGP SIGNATURE-
MacOSX::File 0.70 released
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Folks, Sorry for those who waited, especially Tiger users, for MacOSX::File which did not make test fine. Now it does, with version 0.70. (I ought to have done so at OSCON but the connection there was sporadic and I barely released Encode-2.11 :) =head1 AVAILABILITY http://www.dan.co.jp/cases/macosx/MacOSX-File-0.70.tar.gz and CPAN near you as it propagates =head1 CHANGES $Revision: 0.70 $ $Date: 2005/08/09 15:47:00 $ + t/AskGetFileInfo.pm ! t/catalog.t t/info.t Modified so it passes under Tiger. ! File.pm bin/* tiger's utilities are now mentioned in pod ! bin/psync is now replaced with that of Jean-Louis Fuchs [EMAIL PROTECTED] Message-Id: [EMAIL PROTECTED] =head1 Signature Dan the Maintainer Thereof, with Round Tuit :) -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Darwin) iD8DBQFC+NSCErJia/WXtBsRAol7AJ9kSNZs5f9HeP5vLn0AjrHPnxYdHQCgiOTw WqPtSW5XynvEA2ZAt0yqo5I= =JSm1 -END PGP SIGNATURE-
Re: psync and MacOSX::File installing with cpan
Folks, On Jul 09, 2005, at 12:56 , Chris Devers wrote: The first failed test is: use MacOSX::File::Catalog; ... my $asked = askgetfileinfo(dummy); $asked eq avbstcLinmed ? ok(1) : ok(0); The second failed test is nearly identical: use MacOSX::File; use MacOSX::File::Info; ... my $asked = askgetfileinfo(dummy); ok($asked eq avbstcLinmed); So... something wrong with askgetfileinfo() on Tiger maybe ? Looks like on Tiger there appeared one more attribute 'z', man GetFileInfo zBusy (allowed on folders) I will come up w/ a workaround so please wait for a while... Dan the Maintainer Thereof
Universal Binary vs. Perl5
Porters, So it happened. I am surprisingly unsurprised at the news. These days I hardly care CPUs. I am as CPU-blind ad Color-blind (in a politically correct sense). But as a Perl5 porter I found at least a couple of issues we have to care. What's gonna happen to XS? -- It already uses .bundle so in theory it can handle multiple architectures but in practice? And Archname? - Hmm This one may not be an issue. Usually it is CPU-OS-misc (i.e. i386-freebsd-64int) but It is simply darwin. Any thoughts? Dan the (Perl5 Porter|Mac User Since 1989)
Re: Mac OS X POD viewer app
On Nov 14, 2004, at 01:29, John Siracusa wrote: Is there an OS X equivalent of the old Shuck POD viewer app that came with MacPerl? I know I can convert the POD to HTML and view that, but I'd rather just have something like Shuck for quick rich text views of POD in OS X. Terminal.app :) Well, I'm quite happy w/ it. Or you can try pod2html that comes w/ perl itself. Just pod2html the document you want and put it under ~/Sites/, run httpd via Preferences and view via http://localhost/. These don't quite replace good old Shuck but once again I'm quite happy w/ them. Dan the BSD Chauvinist
Re: pSync/Panther how?
Fellow users of MacOSX::File (and psync) Hi Ingo, I am using psync on Panther and I like it very much. No trouble, it just works. Here is my version info. Joe. [Abba:~] josephal% perl -v This is perl, v5.8.1-RC3 built for darwin-thread-multi-2level (with 1 registered patch, see perl -V for more detail) [snip] I have recently found that gcc2, which is required to build MacOSX::File on Panther's pre-installed version of perl, is not installed when you choose easy install on Xcode. I have updated the document http://www.dan.co.jp/cases/macosx/psync.html to reflect the changes. Dan the Maintainer Thereof
Re: pSync/Panther how?
On Aug 05, 2004, at 02:27, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Dan Kogai) wrote: I have recently found that gcc2, which is required to build MacOSX::File on Panther's pre-installed version of perl, is not I build MacOSX::File just fine with gcc3 on Panther. In fact, I *cannot* build with gcc2. You need gcc2 if and only if your perl is pre-installed /usr/bin/perl (5.8.1-RC3). Otherwise gcc3 is used. Here is the exact code that is used in Makefile.PL WriteMakefile ( # ($] = 5.008001 ? (CC = 'gcc2') : ()), ); Dan the Maintainer Thereof
MacOSX::File 0.69 released
In response to recent thread on psync/panther, I have checked the case and found that on Panther + preinstalled perl, make test passes fine but noisy w/ v-string warnings. Version 0.69 just corrects that. There are no other changes so existing users don't have to update. Availability http://www.dan.co.jp/cases/macosx/MacOSX-File-0.69.tar.gz or CPAN near you. Changes --- $Revision: 0.69 $ $Date: 2004/08/05 03:18:15 $ ! File.pm Catalog/Catalog.pm Spec/Spec.pm Copy/Copy.pm Info/Info.pm s/use 5.6.0;/use 5.006;/ so v-string warning on 5.8.1-RC3 is quiet. This version is tested on: -- * Jaguar + /usr/bin/perl (5.6.0) + /usr/local/bin/perl (5.8.5) * Panther + /usr/bin/perl (5.8.1-RC3) + /usr/local/bin/perl (5.8.5) Dan the Maintainer Thereof
Re: Sort by Mod Date
On May 14, 2004, at 11:53, Ken Williams wrote:
Instead of using string-munging, you can use a real data structure:
How come no one here is using hash?
#!/usr/bin/perl -Tw
use strict;
my $dir = shift || '.';
my %mtime;
opendir my $dh = $dir or die $dir:$!;
foreach my $f (grep !/^\./, readdir($dh)){
my $path = $dir/$f;
# next unless -f $path and -r $path; # commented out
$mtime{$path} = (stat($path))[9];
}
closedir $dh;
foreach my $f (sort {$mtime{$b} = $mtime{$a}} keys %mtime){
# print $f\n
printf %s $f\n, scalar(localtime($mtime{$f})); # prettier print
}
__END__
Dan the Camel (?:ab)user
P.S. FYI ls command has -t option that does just this
Re: MacOSX::File on Panther
On Friday, Oct 24, 2003, at 14:58 Asia/Tokyo, [EMAIL PROTECTED] wrote: No, it doesn't work for me. I had tried something similar, but it seems that -U only affects a corresponding -D, but not #define in files. Hmm Right. Okay. It seems like I have to work it out which I will start right now. But I have to begin w/ downloading the latest seed, burning the CD and install it. It will take half a day, at least, to fix my testbed. Since Panther release is so close I would like to use your patch for last-minute insurance; Can I post your patch in my web? Dan the Maitainer of MacOSX::File
Re: MacOSX::File on Panther
Panther users, On Friday, Oct 24, 2003, at 13:41 Asia/Tokyo, Dan Kogai wrote: On Friday, Oct 24, 2003, at 02:42 Asia/Tokyo, [EMAIL PROTECTED] wrote: Yes, this seems to be another case of a Perl define (I_POLL) colliding with a Mac OS X one (in OpenTransportProtocol.h). Panther now has poll() (an emulation actually), so that is why I_POLL is now defined. A quick workaround is to apply the following patch: Thank you! If such is a deal, would somebody try make CC='gcc2 -UI_POLL' and see if it works? Currently I do not have an access to the latest Panther and it will take a while before my Panther environment gets ready enough to test an official Panther-ready, Jaguar-compatible version. FYI, the command line above is at least Jaguar-compatible. Thanks in advance. Dan the Maintainer of MacOSX::File
Re: Psync, small pseudo-bug
On Thursday, Aug 7, 2003, at 03:33 Asia/Tokyo, alex black wrote: However, I have a small problem with it that is not your fault (or necessarily even your responsibility with psync) but the fault of the finder: Say I have a directory on the source volume: Blah/ stuff.txt pic.jpg moo.sit And I delete that directory. I expect that Blah/ will disappear on the target (backup) volume once I run psync. It does not. I looked at my logs and realized that psync was doing a normal rm on the directory and failing because the finder *curse it* dumps a .DS_Store file in the directory. Therefore the directory is not empty and psync won't delete it. Yikes. I could have used rmtree() of File::Path to make sure it is empty (the obvious drawback is that it is slow). One easy workaround is apply; find /Volumes/Backup -type f -name .DS_Store -delete -print before committing psync. That ensures that .DS_Store does not exist. So - because you are not recursively forcing an rm on the directory, and because the finder litters the filesystem with trash (I have a special alias called cleancrap which searches my cvs-controlled directories for .DS_stores and deletes them)... My backups are littered with empty old folders that I have long since thrown away. There's no problem of disk space, .DS_Stores are never more than 8k... But it bites at me :) Is there a psync flag I'm missing to force recursive removal of directories? If not, would you consider adding one? Yes, I will but I can't make promises as to when to release the next version of MacOSX::File. Unfortunately I am thrashing recently. Dan the Man with Too Many Projects to Proceed
Re: psynch and Panther
On Monday, August 4, 2003, at 7:39 AM, Bill Henry wrote: Dan I am using Panther b21 and it does not seem to work with the psync in CCC from Mike Bombich, or even your stand alone psync 2.0 product Any updates in the works? I have finally got Panther Preview and acknowledged the problem. % make cp File/Constants.pm blib/lib/MacOSX/File/Constants.pm AutoSplitting blib/lib/MacOSX/File/Constants.pm (blib/lib/auto/MacOSX/File/Constants) cp File.pm blib/lib/MacOSX/File.pm cp Catalog.pm ../blib/lib/MacOSX/File/Catalog.pm AutoSplitting ../blib/lib/MacOSX/File/Catalog.pm (../blib/lib/auto/MacOSX/File/Catalog) /usr/local/bin/perl /usr/local/lib/perl5/5.8.1/ExtUtils/xsubpp -typemap /usr/local/lib/perl5/5.8.1/ExtUtils/typemap Catalog.xs Catalog.xsc mv Catalog.xsc Catalog.c cc -c -I../ -I/Developer/Headers/FlatCarbon -pipe -fno-common -DDARWIN -no-cpp-precomp -fno-strict-aliasing -Os -DVERSION=\0.64\ -DXS_VERSION=\0.64\ -I/usr/local/lib/perl5/5.8.1/darwin-thread-multi-64int-2level/CORE Catalog.c In file included from /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/CarbonCore.h:113, from /System/Library/Frameworks/CoreServices.framework/Headers/ CoreServices.h:21, from /Developer/Headers/FlatCarbon/Files.h:1, from ../common/util.c:9, from Catalog.xs:16: /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/Debugging.h:285:2: #else without #if /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/Debugging.h:287:2: #endif without #if /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/Debugging.h:301:1: missing binary operator before token enum Catalog.c:313:1: unterminated #if make[1]: *** [Catalog.o] Error 1 make: *** [subdirs] Error 2 As you see, the error occurs on Carbon headers so it must have something to do with new gcc or dev tool. Very fortunately I have found a very simple workaround. Instead of simple 'make', type 'make CC=gcc2' and it builds fine. See the log right after my signature. As you see 'make test' is noisy because we--perl5 porters have decided to depreciate v-string and MacOSX::File as of 0.66 does use that. That will be addressed in the next release but I would like you people to wait until perl 5.8.1 ships (very soon, at least sooner than Panther). If you have other wishlist (such as minor bug(s) in psync), please post here at [EMAIL PROTECTED] so we can share. Oh, one more thing. Please note that I only maintain MacOSX::File. CCC and PsyncX do use the psync script that comes with MacOSX::File but they are not works of mine. Dan the Man with Too Many Platforms to Support % /usr/bin/perl Makefile.PL Checking if your kit is complete... Looks good Writing Makefile for MacOSX::File::Catalog Writing Makefile for MacOSX::File::Copy Writing Makefile for MacOSX::File::Info Writing Makefile for MacOSX::File::Spec Writing Makefile for MacOSX::File [EMAIL PROTECTED]:~/work/MacOSX-File-0.66% make CC=gcc2 cp File.pm blib/lib/MacOSX/File.pm cp File/Constants.pm blib/lib/MacOSX/File/Constants.pm AutoSplitting blib/lib/MacOSX/File/Constants.pm (blib/lib/auto/MacOSX/File/Constants) cp Catalog.pm ../blib/lib/MacOSX/File/Catalog.pm AutoSplitting ../blib/lib/MacOSX/File/Catalog.pm (../blib/lib/auto/MacOSX/File/Catalog) /usr/bin/perl /System/Library/Perl/5.8.1/ExtUtils/xsubpp -typemap /System/Library/Perl/5.8.1/ExtUtils/typemap Catalog.xs Catalog.xsc mv Catalog.xsc Catalog.c gcc2 -c -I../ -I/Developer/Headers/FlatCarbon -g -pipe -pipe -fno-common -no-cpp-precomp -fno-strict-aliasing -Os -DVERSION=\0.64\ -DXS_VERSION=\0.64\ -I/System/Library/Perl/5.8.1/darwin-thread-multi-2level/CORE Catalog.c In file included from /System/Library/Frameworks/CoreFoundation.framework/Headers/CFBase.h: 13, from /System/Library/Frameworks/CoreFoundation.framework/Headers/ CoreFoundation.h:8, from /System/Library/Frameworks/CoreServices.framework/Frameworks/ CarbonCore.framework/Headers/CarbonCore.h:20, from /System/Library/Frameworks/CoreServices.framework/Headers/ CoreServices.h:21, from /Developer/Headers/FlatCarbon/Files.h:1, from ../common/util.c:9, from Catalog.xs:16: /usr/include/gcc/darwin/2.95.2/g++/../stdbool.h:10: warning: empty declaration Catalog.xs: In function `XS_MacOSX__File__Catalog_xs_setcatalog': Catalog.xs:263: warning: assignment makes pointer from integer without a cast Running Mkbootstrap for MacOSX::File::Catalog () chmod 644 Catalog.bs rm -f ../blib/arch/auto/MacOSX/File/Catalog/Catalog.bundle LD_RUN_PATH= MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -flat_namespace -undefined suppress -framework Carbon Catalog.o -o ../blib/arch/auto/MacOSX/File/Catalog/Catalog.bundle chmod 755
Re: Encode failure in conversion from MacArabic/Farsi/Hebrew
Kino, On Thursday, Jul 24, 2003, at 14:39 Asia/Tokyo, Kino wrote: Anyway, I will make mac(Arabic|Farsi|Hebrew).ucm available BEFORE releasing the next version of Encode so I appreciate if you test them. I'll be very happy to test them. I am sorry I forgot to report this to you but the patch is already in bleedperl (though 1.98 remains unrelased) I have sent the patch to jhi because he was in a hurry (that happened right after RC4). You can get the UCMs via http://www.dan.co.jp/~dankogai/macbidi-ucm.tar.gz Thank you in advance for testing them. Dan the Encode Maintainer
Pantherbites
I have finally gotten an access to Panther so here is my preliminary
report on it as a Perl5 Porter. Let me begin with pros
* It is good looking
* And fast
* I love Expos~{(~}.
Now cons
* input method is a mess! I like the old one (disintegrated) better.
* took 15 minutes to find how to enter '\' (backslash) instead of ~{#$~}
(yen) ONCE Kotoeri is enabled. Once Kotoeri is enabled, '\' key
refuses to backslash and yens yens yens! Solution: Add US Extended
via [Input Menu] tab of [International] Preference Panel and use it.
* And... Perl 5.8.1 which I will discuss a little deeper.
Yes. As announced earlier Panther Preview comes w/ Perl 5.8.1-tobe
(MAINT19524 to be exact) so I hope we will make Perl 5.8.1 a reality
before Panther is. Anyway, As an Encode Maintainer I naturally typed
perl -MEncode -le 'print Encode-VERSION'
and here is what Panther said
1.04
Ohmygod! Even Perl 5.8.0 comes with Encode ver. 1.75. WHAT HAS
HAPPEND!? So I 'perldoc -m Encode' and found this.
#
# $Id: Encode.pm,v 1.4 2003/05/20 22:49:15 emoy Exp $
#
package Encode;
use strict;
our $VERSION = do { my @r = (q$Revision: 1.4 $ =~~ /\d+/g); sprintf
%d..%02d x $#r, @r };
Aha! Now I see. emoy has checked in MAINT19524 source and RCS
retagged $Revision$. I'm sorry emoy but this is NOT THE RIGHT THING
(TM).
Perl module infrastructure depends heavily upon version numbers and
auto-versioning via RCS/CVS as above is a common technique in perl.
I surely hope this will be fixed in real Panther...
Dan the Encode Maintainer Just gotten a first bite by the baby Panther
Re: Pantherbites
Hmm Mail 1.3 seems to need some more work (back in Jaguar)
On Wednesday, Jul 23, 2003, at 21:32 Asia/Tokyo, Dan Kogai wrote:
I have finally gotten an access to Panther so here is my preliminary
report on it as a Perl5 Porter. Let me begin with pros
* It is good looking
* And fast
* I love Expos~{(~}.
I meant Expos or qq(Expos\x{00e9}).
* took 15 minutes to find how to enter '\' (backslash) instead of
~{#$~} (yen) ONCE Kotoeri is
And (FULLWIDTH YEN: \x{ffe5}.
Content-Type: text/plain; charset=HZ-GB-2312; format=flowed
Content-Transfer-Encoding: 7bit
Mail 1.3 was obviously out of mind!
Dan the Perl5 Porter
Re: Pantherbites
On Thursday, Jul 24, 2003, at 01:18 Asia/Tokyo, Edward Moy wrote: Did you file a bug report? Don't worry, I already did (#3340036). I was about to do but I am a Perl5 Porter before OS X user so @perl.org had precedence. Plus it is in the middle of the change of the season (rainy - summer) and I always get cold during then. Cold won before I file the report. Thanks for moving so quickly. Do you think I did this on purpose? I hope not. Not at all. If I were you I'd have fallen in the same pit. And I am rather glad we have found this problem before Panther matures to adulthood. Do you think this has never happened before? No, Perl 5.6.0 on Jaguar and previous had the same problem with CVS (no -ko option) and only now was it ever noticed. And in the several months since I inherited Perl (actually asked for it), I would have fixed it if I had known. That was the conclusion I have reached; Perl 5.6.0 has far less modules and most modules hardcoded $VERSION so it went unnoticed. I think it is a good timing to introduce what Ilya has mentioned. On Wednesday, Jul 23, 2003, at 23:34 Asia/Tokyo, Ilya Martynov wrote: Better solution is to use FreeBSD's patches for CVS to support custom revision tags. This solves this problem nicely by allowing several maintainers to have their own revision tags in same source code. For examples snippet from /usr/src/crypto/openssh/ssh-agent.c RCSID($OpenBSD: ssh-agent.c,v 1.97 2002/06/24 14:55:38 markus Exp $); RCSID($FreeBSD: src/crypto/openssh/ssh-agent.c,v 1.2.2.8 2002/07/03 22:11:43 des Exp $); I would love to see the $Darwin$ tags! Back to emoy Sorry, I don't usually get personal, but tone of this message seemed inappropriate to me. And here is my apology for the tone of my voice. Well, I have cold to blame (my nasal cavity is so stuffy that I should have literally stood in a way of frontal lobe of my cerebrum). Nevertheless, consider this problem fixed for final Panther. I am 80% proud and 20% scared to see my codes become a part of the most popular *NIX available today. Keep going! Dan the (Encode Maintainer|Panther-user-to-be)
Re: Encode failure in conversion from MacArabic/Farsi/Hebrew
On Wednesday, Jul 23, 2003, at 23:20 Asia/Tokyo, Kino wrote: I remember someone has already brought this issue up several months ago. As I'm just a newbie in perl, I'm hesitating in reporting this. I'm not 100% sure if it is a bug. Anyway... Obviously I have overlooked and thanks for rehashing me. 3. Terminal showed MacArabic \x20 does not map to Unicode. MacArabic \x21 does not map to Unicode. MacArabic \x22 does not map to Unicode. These are easy to fix; Just copy the missing parts from ASCII. 4. In result.txt, those characters, i.e. \x20-\x2F, \x3A-\x3F, \x5B-\x5F, \x7B-\x7D, \x81, \x8C, \x93, \x98, \x9B, \xA0-\xA4, \xA6-\xAB, \xAD-\xBA, \xBC-\xBE, \xC0, \xDB-\xDF, \xFB-\xFD have not been converted to appropriate characters but changed to hexadecimal notation. I am not sure if I can fix these by simply reapplying ARABIC.TXT because of BIDI issues. I think those characters should be converted properly since they are mapped in ftp://ftp.unicode.org/Public/MAPPINGS/VENDORS/APPLE/ARABIC.TXT Similar results with conversion from MacFarsi and MacHebrew. Anyway, I will make mac(Arabic|Farsi|Hebrew).ucm available BEFORE releasing the next version of Encode so I appreciate if you test them. Dan the Encode Maintainer
Re: Few questions about psync
On Saturday, June 7, 2003, at 11:37 AM, Scott Haneda wrote: I have a few q's about psync, do you have time? I use as root psync -d / /Volumes/backupplace/daily psync -d / /Volumes/backupplace/weekly Cron triggers them accordingly... I can not seem to get the Startup Disk Pref Pane to see either of the 2 directories as bootable, played a little with the bless command, but still no go. That is the difference between a volume and a directory. Volume must be the physical root of where all other subdirectories reside and Startup Disk does see the difference. It only checks volumes, not directories in general. Does psync not work unless I point it to /Voume/volumename and not to a sundirectory thereof? In the even I needed to boot, could I just mv * up one directory? psync does back up right but when the target is a subdirectory of a volume it does not work as a startup volume. If you want BOTH 'daily' and 'weekly' bootable, partition your drives. Dan the Man with Too Many Volumes to Backup
Re: [MacOS X] consider useshrplib='false' by default
On Wednesday, June 4, 2003, at 03:33 PM, Jarkko Hietaniemi wrote:
Sounds reasonable to make the useshrplib to default to false (because
of the significant startup slowness otherwise) and at the very least
make it conditional (and I got a nod from Ed Moy of Apple, too).
So I did (change #19681).
Thank you.
How about the -prebind flags et alia? Should they be made default,
too?
I think we should but the biggest problem on slow startup was primarily
libperl.dylib (too may symbols for fix_prebinding daemon to tweak). I
am now working on benchmarking the difference but even without -prebind
flag the launch speed increase was significant.
One more caution if we want to make -prebind a default is here.
hints/darwin.sh
122:case $osvers in
123:1.[0-3].*)
124: lddlflags=${ldflags} -bundle -undefined suppress
125: ;;
126:1.*)
127: ldflags=${ldflags} -flat_namespace
128: lddlflags=${ldflags} -bundle -undefined suppress
129: ;;
130:[2-6].*)
131: ldflags=${ldflags} -flat_namespace
132: lddlflags=${ldflags} -bundle -undefined suppress
133: ;;
134:*) lddlflags=${ldflags} -bundle -undefined dynamic_lookup
135: case $ld in
136: *MACOSX_DEVELOPMENT_TARGET*) ;;
137: *) ld=MACOSX_DEPLOYMENT_TARGET=10.3 ${ld} ;;
138: esac
139: ;;
140:esac
As you see ${ldflags} is injected into $lddlflags but in case of
-prebind we need to avoid that. $ldflags is for perl linking while
$lddlflags is for XS. Since -prebind and -bundle are mutually
exclusive, we do not want -prebind in $lddlflags (though CC on darwin
is smart enough to ignore -prebind when -bundle, it still issues
warnings and I don't want to see that warning for each XS gets built).
Dan the Prebound Man
Re: [MacOS X] consider useshrplib='false' by default
On Wednesday, June 4, 2003, at 04:01 PM, Dan Kogai wrote:
I think we should but the biggest problem on slow startup was
primarily libperl.dylib (too may symbols for fix_prebinding daemon to
tweak). I am now working on benchmarking the difference but even
without -prebind flag the launch speed increase was significant.
And here is the benchmark.
with the new default as of 19681
% otool -hv ./perl
./perl:
Mach header
magic cputype cpusubtype filetype ncmds sizeofcmds flags
MH_MAGIC PPCALLEXECUTE 9 1604 NOUNDEFS
DYLDLINK
% redo_prebinding ./perl
redo_prebinding: file is not prebound: ./perl
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e
1)}' 1000 ./perl
2.860u 6.680s 0:12.75 74.8% 0+0k 0+4io 0pf+0w
with -Dldflags='-prebind' -Dlddflags='-bundle -undefined dynamic_lookup'
% otool -hv ./perl./perl:Mach header
magic cputype cpusubtype filetype ncmds sizeofcmds flags
MH_MAGIC PPCALLEXECUTE12 1884 NOUNDEFS
DYLDLINK PREBOUND TWOLEVEL
% redo_prebinding ./perl
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e
1)}' 1000 ./perl
2.290u 6.490s 0:11.59 75.7% 0+0k 0+3io 0pf+0w
As you see -prebind does help though not as significant as -Uuseshrplib.
man 8 fix_prebinding
hese hints are used by the dynamic loader to launch processes prebound,
eliminating the need to look up dynamically linked symbols. If
these
hints are out-of-date, the dynamic linker instead must lookup
referenced
symbols. As a result, the application may launch from 10-30%
slower.
So this still holds true at least for user time. Though the time
saving might not be significant for ordinary users, Busy web sites
with lots of CGIs should definitely benefit.
Dan the Benchmarker of Yours
P.S. Here is the comparison against our competitors and the script I
used to benchmark. see we compare by cusr and csys, not usr and sys.
Anything other than perl are pre-installed version.
#
use strict;
use Benchmark qw/:all/;
my $null = '/dev/null';
my $count = shift;
my %benches = map { $_ = eval qq/sub{ system '$_'='$null' }/ } @ARGV;
my $results = timethese($count = \%benches, 'all');
# Since we are benchmarkning system, we swap (usr,sys) and (cusr,csys)
# to get a correct values for cmpthese or the value gets bogus
# 0 1 23 4 5
# ($real, $user, $system, $children_user, $children_system, $iters)
for my $k (keys %$results){
my $v = $results-{$k};
@$v[1,2,3,4] = @$v[3,4,1,2]
}
cmpthese($results, 'all');
__END__
Ratepython ruby tclsh./perlsh
perl5.6.0
python16.7/s-- -29% -77% -82% -85%
-87%
ruby 23.6/s 41%-- -67% -74% -79%
-81%
tclsh 71.4/s 327% 202%-- -23% -38%
-43%
./perl92.6/s 454% 292% 30%-- -19%
-26%
sh 115/s 587% 386% 61% 24%--
-8%
perl5.6.0 125/s 647% 429% 75% 35%9%
--
We are doing great! Note ./perl is compiled with full of options like
-DDEBUGGING and -Dusethreads.
P^2.S. jhi, is there an option to make (time|cmp)these to compare by
cusr and csys so I don't have to tweak like the script above?
Re: [MacOS X] consider useshrplib='false' by default
On Wednesday, June 4, 2003, at 08:03 PM, Chris Nandor wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Dan Kogai) wrote:
As you see ${ldflags} is injected into $lddlflags but in case of
-prebind we need to avoid that. $ldflags is for perl linking while
$lddlflags is for XS. Since -prebind and -bundle are mutually
exclusive, we do not want -prebind in $lddlflags (though CC on darwin
is smart enough to ignore -prebind when -bundle, it still issues
warnings and I don't want to see that warning for each XS gets built).
Another question is whether to use something other than bundle for XS,
to
allow prebinding. I have a patch to dl_dyld.xs that seems to work; it
allows both bundle and dyld (thanks to some pointers from wsanchez).
That's a great work but with all due respect I do not think making XS
prebindable a good idea. Correct me if I am wrong but my understanding
on prebinding is that it is a technique that makes dynamic libraries
behave like static ones by predetermining ALL ADDRESSES IN NEED A
PRIORI.
With -Uuseshrplib, the only dynamic library you need is libSystem
(which is what libc and libm really are). So it is safe to assume that
no addresses would collide.
% otool -L ./perl
./perl:
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
current version 63.0.0)
But to make XS prebindable you have to make sure that addresses never
collide FOR ALL MODULES. When that fails XS may still work (so far as
I see dyld is smart enough to make sure to to collide symbols and
addresses and diverts that when it needs but when that happens a
warning is issued).
Since no one knows how many XSes a particular user needs, I think we
should leave -bundle for XS.
Theoretically, however, we can still resolve this by keeping a symbol
table handy somewhere and use that during XS builds but that I consider
a too much work.
Dan the Prebound Man
[MacOS X] consider useshrplib='false' by default
Porters,
I would like to propose that we make useshrplib='false' default for
darwin to resolve prebinding woes.
I said update_prebinding -root / should resolve the problem but only
temporarily. perl is in fact not prebind. This is what is actually
happning.
% env DYLD_PREBIND_DEBUG=1 /usr/local/bin/perl -e 1
dyld: perl: prebinding disabled because library:
/usr/local/lib/perl5/5.8.0/darwin-thread-multi-64int/CORE/
libperl.dylib got slid
dyld: in notify_prebinding_agent() determined the system shared
regions are NOT used
dyld: 2 two-level prebound libraries used out of 3
At this stage no /usr/libexec/fix_prebinding: /usr/local/bin/perl
couldn't be prebound in the past, and probably can't be prebound now.
is issued. But as time goes by and more system gets used, dyld: 2
two-level prebound libraries used out of 3 stops working and the
(in)?famous fix_prebinding warning starts appearing in your
/var/log/system.log.
When you attempt to compile perl with -prebind switch, however, this is
what happens
DYLD_LIBRARY_PATH=/Users/dankogai/work/perl-5.8.0 cc -prebind -o
miniperl \
miniperlmain.o opmini.o libperl.dylib -lm -lc
cc: unrecognized option `-prebind_allow_overlap'
ld: warning multiple definitions of symbol _Perl_listkids
opmini.o definition of _Perl_listkids in section (__TEXT,__text)
[lots of similar ld warnings to follow]
So it does not work in practice. But when you turn off useshrplib,
prebinding works beautifully.
To test that for yourself, just Configure with
-Dldflags='-prebind' -Dlddflags='-bundle -undefined dynamic_lookup'
-Uuseshrplib
And the change? Significant! See this
Reference: bundled version
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e
1)}' 1000 /usr/bin/perl5.6.0
1.560u 4.680s 0:07.46 83.6% 0+0k 0+0io 0pf+0w
-Duseshrplib
% time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e
1)}' 1000 /usr/local/bin/perl
21.490u 8.690s 0:33.22 90.8%0+0k 0+1io 0pf+0w
-Uuseshrplib and prebinding
%time /usr/bin/perl -le 'for (1..$ARGV[0]){system $ARGV[1], qw(-e 1)}'
1000 /usr/local/bin/perl
2.190u 5.810s 0:10.42 76.7% 0+0k 0+0io 0pf+0w
As we all know many systems now support -Duseshrplib but not many make
it a default.
% egrep useshrplib='?true'? hints/*.sh
hints/bsdos.sh:useshrplib='true'
hints/darwin.sh:useshrplib='true';
hints/openbsd.sh: useshrplib=true
hints/os2.sh:useshrplib='true'
hints/os390.sh:'') useshrplib='true' ;;
hints/rhapsody.sh:useshrplib='true';
hints/svr5.sh: useshrplib='true'
and those listed usually make useshrplib=true conditionally. It seems
only darwin makes it unconditionally true.
shared libperl save disk space and memory ONLY WHEN you have many apps
liked to libperl. In most cases, however, you have only perl itself
and mod_perl. So I suggest that we make useshrplib=false for darwin.
I know you all know but XS are still dynamically loaded. So there is
not much point for -D useshrplib.
Dan the Man too Tired of Unprebindable Camels
Re: psync question
On Monday, June 2, 2003, at 05:24 AM, J.C. Wren wrote: Dan, I'm a Mac owner, running OSX, but I'm not into OSX. I'm more a Linux person. What I'm looking for is a solution to backup the complete OSX volumes, including resource forks (what ever they are, but apparently I *really* want to keep those...) to a remote server on my network. psync looks like a solution, but the documentation is a little non-specific. Since I don't want to wipe anything before I go to town, I thought I'd ask this question. The docs say: sudo psync -d / /Volumes/Ibackup Why 'I'? That's a document bug. POD renders Iitalic to italic but that was in verbatim section so it does not get rendered. Will be fixed in future. Sorry. And more importantly, is the software smart enough to skip over the volume, and not incorporate the work done to this point back into the archive? Yes. Just like -xdev option of find(1). Unlike find(1) and cp -r cross-device copying is suppressed by default. But just make sure that / and /Volumes/backup reside on different devices. If they were on the same volume this safety feature does not work (just like -xdev). Can I NFS mount a volume at /Volumes/remote, and Yes. But in which case note that some files with unicode names might not be copied properly (many fonts under /Library/Fonts do have those unsafe names. psync -d / /Volumes/remote/Ibackup And similiarly, what would a restoration process be like? Can I NFS mount this image (once I've resinstalled OSX), and do a full restore from the image? And is there anyway to extract single files from the backup set? The most similar one must be rsync. And to extract single files you don't need to because psync is NOT an archiving utility. You just copy one from backup via cp and such. Any help/advice you can provide would be greatly appreciated. Oh, and I looked at rsync_hfs, and talk about about ZERO documentation... In fact, the docs in the CVS tree just refer to it as 'rsync', so I'm not sure what's supposed to make rsync_hfs more better. I would theorize it's HFS support, but there's no discussion about interoperability when moving to remote file systems (like are attributes and these resource fork things preserved?) That's why it is on CVS only :) If it were considered stable, there should've been binary distributions already. Dan the Man with Too Many Codes to Maintain
Re: safe system()?
On Saturday, Mar 29, 2003, at 03:23 Asia/Tokyo, Rich Morin wrote: Let's say that I want to use a command (e.g., md5) on a file. No problem; just use: system(md5 $file); Except that the file name could contain all manner of white space characters, shell wildcard characters, etc. Is there a module that deals with this sort of thing (e.g., wrapping each argument in the appropriate kinds of quoting)? This is definitely one of the areas where TMTOWTDI blesses you and curses you the most. There are just too many ways to do this kind of things to come up with idioms. But there are rules of thumb; * Let perl or module do it Instead of system(md5...) (Well, I think it is more like open MD5, md5 ... | if you want to reuse the result in perl), you can use Digest::MD5. Perl itself is versatile enough to do away with the need of such commands as grep, sed, and awk. And with so many modules that does shell commands, it is usually much easier to find the module and use it than resort to system() or open(). * When you have to, use taint mode and untaint with care There are still some cases where external commands are (better| the only choice). But just because you decided to use them don't blindly system() or open(). Use taint mode. With taint mode on (via -T switch), system(md5 $file) simply dies if $file is set by external data. You have to untaint it to use it. i.e. my $file = shift; # tainted $file =~ m/([\w\.\-\+]+)/o; # $1 is not tainted system(md5, $1); # okay; See perldoc perlsec for details. * when you system(), do not let shell stand in a way system(md5 $file) and system(md5, $file) looks the same but they are treated completely differently by camel, The first one is fed to the shell (/bin/sh for most cases) but the second one is directly invoked by perl so wild cards are not expanded, resulting much safer codes. Not only is it safer but also faster. So when you want to do the following, my $cmd = command arg1 arg2; Do my (@cmd) = split /\s+/ = $cmd; system(@cmd); instead of system($cmd). Of course there are still in need of shell, such as cases like below when you have to use redirections therein. $cmd = command arg1 out.txt 2 error.txt; But these cases are much rarer and can usually cope with different techniques. See perldoc perlfaq and Perl Cookbook. Dan the Man with Too Many Ways to Do It
Re: [MacPerl] Re: problem with Japanese text
On Friday, Mar 28, 2003, at 11:37 Asia/Tokyo, Joel Rees wrote: Not sure if my comments are relevant, just feeling inclined to expose my ignorance -- And here is mine. Japanese is one of those languages that has relatively few specifically plural forms. To get the pluralizations right in Japanese, the program would have to consult a dictionary. More exactly speaking, Japanese has no plural form in a sense of Indo-European languages. Japanese totally lacks subject-verb agreement so you don have to delete the es in does when you change the subject form s/he to they. On the other hand, counting can be tricky even for natives. The very name of numbers changes depending on what you count. When you count people it goes hito-ri, futa-ri, san-nin but when you count object it goes hito-tsu, futa-tsu (or ik-ko, ni-ko,) and the list goes on (I think this number-object agreement came from Chinese). But when the number is not an issue, you can totally forget if a subject is singular or plural. Pluralization could probably be ignored for this purpose for Japanese, but, if the purpose is to produce text that the technically un-inclined can parse reasonably effortlessly, there are all sorts of other context related issues, most of which would require not just vocabulary dictionaries, but idiom dictionaries as well. And your locale machinery would have to include some sensitivity to dialect issues and social status issues, to make the generated text natural and non-offending. I feel Japanese is a hard language to compose because of that but that also makes Japanese easier to read because Japanese tend to include not only what to say but also in what situation by what kind of person says. In English the singular nominative pronoun is nothing but I, no matter how old or young you are or whether you are a boy or a girl (or a computer). But in Japanese it can be Watashi or Boku or Ore or Maro or Warawa or Sessha or Jibun or Ware even English me can be used. Maybe to compensate this complexity, Japanese grammar seems much simpler. No subject-verb agreement, very few irregular verbs It is far easier to compose a grammatically correct Japanese. It gets darn hard once you aim for social and political correctness. Japanese is becoming more egalitarian, more homogenized, and less colorful, so those who work on such things are aiming at a moving target. Less colorful I am not sure because at the same time the newer, simple, and more boring expressions are pervasive, the old and more complex expressions hardly die. So in total Japanese is getting richer. Well, the total richness of Japanese is I believe is increasing but ironically per-capita richness might not be. But I believe this phenomenon is not unique to Japanese; could be even more prevalent in English. If you don't believe me just compare the Two Bushes in White House :) Thinking about the recognizer side, did anyone mention that Japanese text does not use word delimiters? Space has a somewhat different meaning for Japanese. Japanese tokenization is nothing but a trivial issue. In Japanese the very notion of a word is often moot. Nevertheless, we do have good enough tokenizers to implement input methods and search engines. Of course they are not perfect but the Japanese are very frank about the lack of perfection. After all we don't even have de jure standard Japanese to compare. Dan the Man with Too Many Languages to Deal with
Re: [MacPerl] Re: problem with Japanese text
On Thursday, Mar 27, 2003, at 01:31 Asia/Tokyo, Chris Nandor wrote: Is there a reason for MacJPerl when MacPerl 5.8.x is released? I thought none but the second thought; The built-in text editor that many not support multibyte characters. But even that is moot since there are many text editors which can use MacPerl, some of which even free (I use mi when I have to type in Japanese http://www.asahi-net.or.jp/~gf6d-kmym/, free, perl-savvy, and supports all major Japanese encodings including UTF-8). I wonder how many of you have ever tried 5.8 features such as Encode and PerlIO in MacPerl (besides make test, of course). I don't even lauch Classic these days... Dan the ex-user of MacOS
Re: DynaLoader and prebinding
pudge, On Saturday, Mar 22, 2003, at 13:10 Asia/Tokyo, Chris Nandor wrote: So I have this problem: Mac::Carbon takes a long time to load. $ time perl -Iblib/arch -Iblib/lib -MMac::Carbon -e1 real0m2.923s user0m2.570s sys 0m0.160s Profiling the run showed that over 80% of that time is taken by dyld, so I wondered if prebinding could solve the problem. However, perl uses .bundle files for DynaLoader, and .bundle files cannot be prebound. Drat. Does your /var/log/system.log say something like the following? Mar 23 04:51:05 dan-pbg4 /usr/libexec/fix_prebinding: /usr/local/bin/perl couldn't be prebound in the past, and probably can't be prebound now. Mar 23 04:51:05 dan-pbg4 /usr/libexec/fix_prebinding: 2003-03-23 04:51:05 +0900: prebinding for perl done. If so, try sudo update_prebinding -force -root / This AT LEAST makes that system warning go away and perl launches faster (sometimes significantly, sometime just slightly). At least it saves disk access by reducing the need to log the warnings. You may know that Apple's Software Updates does this update_prebinding but without -force and without it that syslog warnings will not go away. Drat. And I am not sure how much time you can save by converting .bundle to .dylib man fix_prebinding These hints are used by the dynamic loader to launch processes prebound, eliminating the need to look up dynamically linked symbols. If these hints are out-of-date, the dynamic linker instead must lookup referenced symbols. As a result, the application may launch from 10-30% slower. 10-30% seems a lot but that still does not explain the time it takes to load your module. I've tested a few biggies but even such big modules as Encode::JP and POSIX take less than 0.1s to load on my TiBook (800MHz). It seems that the size of module does not matter much. Maybe the number of symbols therein? IMHO, there is a good reason why Wilfredo Sanchez chose not to prebind XS http://developer.apple.com/tools/projectbuilder/Prebinding.html Requirements for Prebinding To work properly, libraries and executables must meet several important requirements: 1. Libraries must not have overlapping preferred addresses. For each release of Mac OS X the Apple-supplied libraries are all prebound and do not have overlapping addresses. Your libraries must not overlap with any of your own libraries, and also must not overlap with any of the Apple-supplied libraries that are installed with Mac OS X. There is currently no way to automatically select an address for a library to ensure that it does not overlap the addresses of other libraries. Non-Apple libraries can use any address in the range 0xto 0x3FFF. For the Mac OS X 10.0 release, all addresses above 0x9000 are also available. To set the address of a library, pass either the -seg1addr flag or the -seg_addr_table flag to ld(1). All executables should be at the default address, 0x. The default address is 0x. When selecting addresses for libraries, the address range of the largest executable using the libraries should be avoided. 2. There can be no undefined symbols. In most cases, this means that you must link against your dependent libraries. It also means that there can be no circular dependencies (cases where library A calls a function in library B, and a function in library B also calls a function in library A). Circular dependencies can be removed by changing the code to dynamically look up the function instead of directly referencing it. 3. You cannot override symbols that are referenced in flat namespace images used by the dependent libraries. For example, you can't define your own malloc and then prebind using flat namespace libraries. Simply put, it is just too darn hard to prebind all XS without address overlaps, especially when CPAN modules are concerned. On the other hand, libperl is .dylib already so it may be able to take advantage of prebinding. You should also note that launching takes much longer when perl is built w/ -DDEBUGGING is on. Dan the Man with Too Many Files to Prebind #!/usr/local/bin/perl
Re: man psync
On Friday, Feb 28, 2003, at 05:52 Asia/Tokyo, Brad Schonhorst wrote: Silly question- After installing MacOSX::File in order to gain access to psync I cannot seem to bring up the man page for it. I am using mac 10.2.4. Any suggestions or is there a way to get at the man page somewhere else (online perhaps?) try perldoc psync If your $MANPATH setting is appropriate, 'man psync' should suffice but perldoc is smarter at locating the document. Dan the MacOSX::File Maintainer
Re: Psync and Perl 5.8.0.
On Monday, January 27, 2003, at 01:14 PM, J. Charles Holt wrote: Any idea what the trouble might be? Any thoughts would be appreciated! [snip] In file included from Catalog.xs:16: ../common/util.c:9:19: Files.h: No such file or directory Do you have Developer Tool installed? It appears that Carbon framamework, needed to compile MacOSX::File, is missing. Dan the Father of MacOSX::File.
MacOSX::File updated to 0.65
Folks, I just updated MacOSX::File to 0.65. This is mainly thanks to a bug report from Guy Sabourin that addresses a minor typecast bug in Catalog/Catalog.xs that copies creator improperly when compiled in certain condition (the condition I could not duplicate; I suspect the compiler difference). Since Guy's version is definitely less evil and far portable I replaced the code in question with Guy's version. On Monday, Jan 20, 2003, at 02:02 Asia/Tokyo, Guy Sabourin wrote: (from: catalog.xs, line 77, source version 0.62 (from MacOSX-File-0.64)): finderInfo[0] = sv_2mortal(newSVpv((char *)fip, 4)); /* type */ finderInfo[1] = sv_2mortal(newSVpv((char *)(fip+4), 4)); /* creator */ --- Should work, but does not! finderInfo[2] = sv_2mortal(newSVuv(fip-fdFlags)); Because I kept getting garbage in MacOSX::File::Catalog, but MacOSX::File::Info would return a correct creator, I suspected some form of incorrect pointer calculation. I therefore tried the following changes: finderInfo[0] = sv_2mortal(newSVpv((char *)fip-fdType, 4)); /* type */ finderInfo[1] = sv_2mortal(newSVpv((char *)fip-fdCreator, 4)); /* creator */ finderInfo[2] = sv_2mortal(newSVuv(fip-fdFlags)); And here is the Changes. $Revision: 0.65 $ $Date: 2003/01/19 17:53:21 $ ! common/util.c s/strcpy/strncpy/ I though I fixed it :) ! Catalog/Catalog.xs Guy Sabourin [EMAIL PROTECTED] has reported that an evil typecast found in the code above was preventing MacOSX::File::Catalog from copying creator properly. Though I could not duplicate his claim on my environment (compiler difference?), his version is definitely better. Message-Id: [EMAIL PROTECTED] FYI, psync and other scripts that come with this package use MacOSX::File::Info rather than MacOSX::File:Catalog in favor of speed and memory so they are unaffected as of this release. As described above, psync and other popular scripts REMAIN unaffected. Enjoy. Dan the Man with Too Many Modules to Maintain
Re: unix or mac-style text files?
On Monday, Nov 25, 2002, at 01:05 Asia/Tokyo, Chris Nandor wrote: The bottom line was that it'd be nice to have a PerlIO filter for perl 5.8.x, so that MacPerl can execute Unix and Windows text files, and Mac OS X perl can execute Mac OS text files, etc. Patches are surely welcome! :-) One good question may be how to handle newlines in heretext, the only part that really matters because that's the only exception to the fact that newlines are nothing but whitespace from perl compiler's point of view -- oops, shebang is another. When you feed MacPerl *.pl to MacOS X, should linefeeds in heretext emit \015 or \012? I am not sure which is lazier to simply apply # Any - Unix perl -i.bak -ple 's/\015\012|\015|012/\012/g' *.pl # Any - Mac perl -i.bak -ple 's/\015\012|\015|012/\015/g' *.pl or teach camel the same trick Dan the Man with Too Many Kinds of Line Endings to Deal With
Re: psync groups?
On Tuesday, Nov 5, 2002, at 03:08 Asia/Tokyo, Ronald Florence wrote: Dan, I have installed and used your excellent psync to backup an HFS+ partition on MacOS 10.2.1. It works flawlessly, using the command line you suggest, with one exception: Every file in the backup has group `unknown' instead of the group in the original filesystem. Is there a way to fix this so that psync will backup the filesystem with the original groups? Thanks, psync DOES preserve group attributes whenever possible but the very group attribute is simply a 32 bit integer that is mapped to its name by NetInfo (/etc/groups in ordinary Unixen) so if the NetInfo database is different the group may appear in different names. Another possibility that the groups are not preserved is that the use privilege when psync was run was insufficient (I suspect this is more likely). Did you 'sudo'? Dan the Maintainer MacOSX::File
[OT] That annoying yen mark! [Was: Re: [Encode] ...]
On Friday, Oct 18, 2002, at 22:25 Asia/Tokyo, Nicholas Clark wrote: On Fri, Oct 18, 2002 at 10:21:07PM +0900, Dan Kogai wrote: AFAIK, CP¥d+ should be avoided for any data exchanged in the Net so you ^ Yen sign? That should be a backslash, as in CP\d+ ? Right. The smart-ass Mail.app (among other *.app) does this to me when your input method is Japanese and '\' is typed. I have configured Kotoeri (the input method) to be English-friendly --does Kana-Kanji conversion when and only when caps lock is set (much more convenient than toggling Keyboard script with command-space) but even that won't stop replacing slashes with yen mark. You have to get Kotoeri out of picture, something you would so easily forget in apps like Mail. [I seem to remember something about some Japanese character sets swapping \ and ¥ so that the Yen sign had a 7 bit value. As you see now '\' appears correctly because I now toggled off Kotoeri now. I usually notice this on Terminal.app because the difference is critical but not Mail.app Well, at least with MacOS X you can TELL THE DIFFERENCE even though it is sometimes annoying; Win* won't even let you notice that and you are trapped in Yen jail :) Dan the Man with Too Many (Script|Encoding|Charset)s to Fiddle With
Re: Parsing JIS X 0208 Shift JIS with 5.8.0
On Tuesday, Oct 1, 2002, at 18:16 Asia/Tokyo, Robin wrote:
Is anyone else doing/done this? Care to share notes?
Too brief a comment to grok what your point is.
If all you need is (en|de)code Shift_JIS, all you have to do is;
use Encode qw/encode decode/;
#...
my $utf8 = decode('shift-jis', $string/;
just perldoc Encode perldoc Encode::JP.
Dan the Encode Maintainter
Re: Parsing JIS X 0208 Shift JIS with 5.8.0
On Tuesday, Oct 1, 2002, at 18:47 Asia/Tokyo, Dan Kogai wrote:
my $utf8 = decode('shift-jis', $string/;
my $utf8 = decode('shift-jis', $string); # of course.
.I need to get to bed, which I have not for last couple of Earth
rotation
Dan the Insomniac
Jaguar, Psync and tcsh in Jaguar
On Saturday, Sep 28, 2002, at 14:41 Asia/Tokyo, Jeff Yana wrote: Hi Dan- After recently updating to Jaguar I decided it was high time to run a back-up using your wonderful little Psync utility. Problem is that it does not run. The Terminal returns the error command not found. Do you have any thoughts? This would not have anything thing to do with Apple moving over to the GCC would it? try /usr/local/bin/psync first. If that works, add set path = ($path /usr/local/bin) to ~/.tcshrc It is just do to the fact that on Jaguar Apple has removed system-wide tcsh initialization scripts by Sanchez, former head of Darwin Project (though convoluted that was one of the most elaborate initialization scripts I've ever seen. Why gone, Apple?). Now you have to work on your own .tcshrc to have your shell behave decently. Dan
dot files in Jaguar
On Sunday, Sep 29, 2002, at 00:33 Asia/Tokyo, Gero Herrmann wrote: Jordan Hubbard explained the decision in a posting to the Mac OS X TeX mailing list. http://www.esm.psu.edu/mac-tex/MacOSX-TeX-Digests/2002/MacOSX- TeX_Digest_09-11-02.html Thanks. But why not plain-old README that comes with the OS itself? Now you have to work on your own .tcshrc to have your shell behave decently. The file is still there; it just has to be activated. echo source /usr/share/tcsh/examples/rc ~/.tcshrc I do carry my own dot files so it is not the problem for me and I second jhk. The problem is that for many MacOS X Terminal is the first encounter to Unix shell. And we all know how dangerous vanilla shell can be to novices. It doesn't even 'alias rm rm -i'. I would hate to hear hey, Linux distro A is much user-friendlier than OS X. I think the best solution would be to auto-create .t?cshrc when an account was issued, like what many other OSes when you adduser(8). This is both novice-safe and poweruser-happy. Otherwise, it's people like me, not apple, who get messages like file not found ;) Dan the Man with Too Many Questions Redirected in Vain
psync vs. Jaguar [Was: Re: search.cpan.org: Dan Kogai]
On Friday, Sep 20, 2002, at 04:31 Asia/Tokyo, Erik J. Barzeski wrote:
Hi,
I upgraded Perl on Mac OS X (10.2.1 now) to 5.8.0 as per the
instructions at
Apple's site.
Unfortunately... This seems to have caused some trouble with psync.
Hmm... I have numerous reports that MacOSX::File and psync are working
fine w/ Jaguar and Perl 5.8.0 (it does on my own envoronment).
[3:29pm iacas@Gaia:~] % psync
dyld: perl Undefined symbols:
_Perl_sv_2pv
_perl_get_sv
Trace/BPT trap
[3:29pm iacas@Gaia:~] %
Do you have any idea what I might do to fix this? I am grateful to you
for
all your work on psync, and would like to continue using it. Have I
done
something wrong here, or is psync in need of a slight tweak to work
with
5.8?
I don't know exactly how you configured perl 5.8.0 ('per the
instructions at Apple's site' is hardly descriptive enough. Did you do
so in a manner that replaces /usr/bin/perl (not recommended)? Here is
my perl 5.8.0 config
sh Configure -Dprefix=/usr/local -DDEBUGGING -Uinstallusrbinperl -desO
The point is to preserve preinstalled perl (/usr/bin/perl) so
-Uinstallusrbinperl is set.
Dan the Man with Too Many perls installed
Re: Problems install Text::Iconv
On Thursday, May 2, 2002, at 11:21 , Ward W. Vuillemot wrote: I am trying to get, ultimately, XML::SAX and some of its own supporting modules (e.g. XML::SAX::ParserFactory which needs XML::SAX::Writer which needs Text::Iconv). How how the merry nymphs dance and prance on m' forehead. Argh! Has anyone encountered this? Here is the output from an install. Naturally, you have to install iconv BEFORE Text::Iconv. FYI, Iconv capabilities are all added in Perl 5.8 via Encode (and XML::SAX is already designed to use it if Encode is available) so if you are patient enough to wait for 5.8, Text::Iconv will no longer be a prereq. Dan the Encode Maintainer
Re: MacOSX-File-0.50.tar.gz uploaded to CPAN
On Friday, April 26, 2002, at 06:28 , Vonleigh Simmons wrote: Hello, Hi there. Dan, you are the man for making psync. I just tried it to backup my main drive and it works exactly as advertised. One question though, how would I go about restoring a drive? Should I just boot from the copy and copy back to the main drive, or is there a niftier restore feature? (didn't quite understand the -r flag in the man pages). Suppose you've backed up your drive with something like; psync / /Volume/backup If you are booting from the same drive, you can intuitively psync /Volume/backup / # it won't mangle /Volue/backup like cp Or, if you are booting from the volume you just backed up, you can psync / /Volume/newdrive to do so. As for -r option, not all 'Volumes' can store all the necessary file metadata (such as Apple Share volumes; you'll lose file ownership) so when you use -r, an extra database is created and used when you restore. In any case, thanks a bunch for making psync, awesome job. I'm trying to figure out if maybe I could make a cocoa front end for it, so that it would backup on a repeating basis (user defined), plus being able to restore. I'd do a cron job for it, but maybe it would be better to get it out to the less unix-savvy user. For the time being I am too occupied with Perl 5.8 but when it settles I would like to work further on with MacOSX::File. Thanks for your input. FYI, MacOSX::File is now 0.64. Use the latest one. Dan the Man with Too Many Modules to Manage -- _ Dan Kogai __/ CEO, DAN co. ltd. /__ /-+-/ 2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan /--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ - __/ /Tel:+81 3-5665-6131 Fax:+81 3-5665-6132 GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc
Re: Permanently add INC directory?
On Monday, April 22, 2002, at 11:50 , Levan, Jerry wrote: Is there any way to globally add an INC directory to Perl after compilation? I know about setenv PERLLIB5 and do that in my .cshrc. But it doesn't get set when I run Perl from within BBEdit or cron. Is there any way to do this so it is truly global (it can just be across me as the user or for all users, since I'm the only user anyway, as long as that will work with things like BBEdit and cron). Thanks, Peter. In a pinch you could do something like: push INC , Pathtofile At the top of your program, you might have to use A Begin block to enclose the push for use access Rather than require access. More elegant solution; use lib qw(/your/directory); Dan the Man with Too Many perlvar manglings these days
Re: BSD::stat - and Mac OS X
Willam, On Tuesday, April 16, 2002, at 04:55 , William H. Magill wrote: I'm not a programmer, so I may simply be mis-interpreting things. I was hunting for a way to display the flags found in OS X in a rational manner. (ie not having to get info for every bloody file.) So I found your contribution to CPAN. [My goal was to write an ls -l equilivant which would display the flags information as well. If you know of such a critter, that would be a great time saver.] Under Mac OS X, the /usr/include/sys/stat.h struc looks like this below. Which appears to be different than the field sequence in the man page for BSD::stat for fields 13/14/15. Am I simply interpreting things incorrectly? Is Darwin/NeXT different from the BSD in this? Though each BSD differ from one another on st_flags, important fields remain compatible. I do use BSD::stat on MacOS X (in fact my main client machine is PowerBook G4 Ti). So you can still rely on the value of stat()-flags but you may find some of the predefined constants may not work. I borrowed from FreeBSD which appears to have more flags switches than any other. Maybe it is not a good idea to predefine FLAGS constants there after all. I will check to see if Fcntl module can be used for that purpose. But for the time being, please give me more time than usual; I am doing Encode, the largest module (in size) in the upcoming perl 5.8. Dan the Man with Too Many Modules to Manage -- _ Dan Kogai __/ CEO, DAN co. ltd. /__ /-+-/ 2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan /--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ - __/ /Tel:+81 3-5665-6131 Fax:+81 3-5665-6132 GPG Key: http://www.dan.co.jp/~dankogai/dankogai.gpg.asc
Re: PAUSE bug discovered?
On 2002.03.08, at 04:03, Elaine -HFB- Ashton wrote: This has happened only one other time that I can recall and I think that Randal somehow added a LF to his html file. Double check your file name before you upload it this time around. I don't know that this is a bug but it's not a feature. e. Or it could be web browser that has caused this. At any rate, I consider this kind of behavior for a CGI/mod_perl or any web program too goofy for a site like PAUSE (PAUSE is no Matt's script archive!). I want it fixed ASAP. FYI I used a browser called iCAB, available only for Macs (what a shame it is darn best browser available to date; it is even lighter than Opera yet handles multilingual text correctly. It even filters ads!). You can get more info on this browser via http://www.icab.de/ and here is its (default) Agent: header (it is customizable but I leave it as default) is Mozilla/4.5 (compatible; iCab 2.7.1; Macintosh; I; PPC) Dan the Man with Too Many Web Browsers
PAUSE bug leads to LWP bug
On 2002.03.08, at 08:28, Elaine -HFB- Ashton wrote:
I would think it's in the filename itself since PAUSE fetches the URL
you
feed it and the fetch would fail if it had a gremlin on the end. I don't
see how it could be anywhere else but the filename.
Negative. See
http://www.cpan.org/modules/by-authors/id/D/DA/DANKOGAI/
now and see what's going on. I have uploaded MacOSX-File-0.64.tar.gz
again but this time with a different browser, Netscape 6. I DID NOT
CHANGE THE FILENAME OF THE ORIGINATING URI.
As for the possible cause of URL-filename inconsistency, I can guess
various reasons, like passing the query straight to LWP and
basename($url) for file name. Speaking of that, I have found something
really interesting.
Now I have found a (bug|undocumented feature) in LWP, too (Adding
Gisle's address to the recipients) .
perl -MLWP::Simple -e 'print get("$ARGV[0](J\(Bn")'
http://www.dan.co.jp/cases/
gives the same result as
perl -MLWP::Simple -e 'print get($ARGV[0])' http://www.dan.co.jp/cases/
that is, fetches the content, despite the fact the first one is fed
with bogus URI.
perl -MLWP::Simple -e 'print get("$ARGV[0] ")'
http://www.dan.co.jp/cases/
perl -MLWP::Simple -e 'print get("$ARGV[0]\t")'
http://www.dan.co.jp/cases/
or any whitespace will do. I am not sure if I should call this a bug
because this is a kind of nice. But it is certainly undocumented and
definitely confusing.
For MacOSX Folks, I have made MacOSX-File-0.64.tar.gz (source
distribution) also available via
http://www.dan.co.jp/cases/macosx/MacOSX-File-0.64.tar.gz
so you don't have to wait till PAUSE is fixed.
Dan the Man with Too Many Programs to Manage
Re: psync questions
On 2002.03.05, at 03:07, Hugh Harris wrote: Intuitivey it seems that the command sudo psync / /Volumes/backup would try to backup /Volumes/backup to /Volumes/backup hence creating a nasty loop - why doesn't this happen? You can find the answer by looking at the source but I will answer anyway. Before psync begins the directory traversal, it checks the device ID (stat-dev) of the directory where the traversal begins. When it hits anything which device ID is differenct it simply skips. Same mechanism do exist for most other backup commands such as tar, pax and rsync (usually with -x switch) but for some reason do not traverse different volume is not default. How do you go about doing a restore? There are many ways but here is the simplest; 0) boot from /Volume/backup 1) run psync / /Volume/original where original is the name of the volume you backed up In other words I would think booting from another drive then doing sudo psync /Volumes/backup /Volumes/restore_destination_volume/ would work - what do you think? You've got it correct. Thanks, Dan the Man with Too Many Volumes to Backup
Re: Newline independence?
On 2002.02.18, at 14:47, Chris Devers wrote: On Mon, 18 Feb 2002, Peter N Lewis wrote: Does anyone know a good trick? Would it be worth skimming over the source code for a text editor for ideas? Vim can handle pretty much any line endings scheme you throw at it, and I'd assume Emacs can too. Maybe it would help you to look over what those editors are doing to see if you can get any ideas there. If you still care, all you have to do is a simple (and famous even) one liner to convert'em all. Works on virtually any given platform. perl -i.bak -ple 's/(\012\015|\012|\015)/\n/g' files Dan the Man with Too Many Architectures to Handle
Re: psync question
On 2002.02.08, at 07:08, Mark Edwards wrote: Okay, I've finally got psync humming along quite nicely every morning at 4am, backing up my whole drive. Thanks to your help! I'm curious about one last thing. psync, and pretty much every other utility I've tried, can't seem to correctly copy a locked file (locked from the Finder). It copies it as locked, but it changes the permissions to system.unknown. I'm running psync as root, by the way. Is this just not possible to do, or is it something you are going to add? Would you give me a result of 'ls -l file_in_question' and 'pgetfinfo file_in_question'? Permission to system.unknown doesn't make sense to me. Do you mean OWNERSHIP to system.unknown? One known feature of MacOS X is that it ignores chown() on AFP and disk images (Owner will be whoever mounted that volume). Though this is understandable, this stands in a way when you want to backup system files. To overcome this feature psync comes with an option '-r'. When this is specified psync makes a file called .psync.db and stores ownerships there. More pod polishing is needed, maybe Dan
Re: psync fails with 5.7.2
On 2002.02.06, at 05:00, Randal L. Schwartz wrote: Rick == Rick Frankel [EMAIL PROTECTED] writes: Rick Running 5.6.1 here, but I think it may be a permission problem in the Rick distrib directory, Rick The test scripts should probably copy, etc. in /tmp instead of the Rick current tree. I ran the tests as merlyn, with merlyn owning the build tree. What more permission is needed? Hmm I don't know. I confess I didn't bother check with perl 5.7.2 because I consider perl 5.7.2 too unstable (for one thing, it didn't even build on FreeBSD 4.x. The latest breadperl does, however). And I only have breadperl installed with prefix=$HOME. So I checked with breadperl to see if it compiles fine. It did warn but all tests passed (I consider these warning too much because they all trap 'use 5.6.0;'). Randal, would you also try /usr/bin/perl Makefile.pl if you have preinstalled version of perl untouched? FYI MacOSX::File is developed under perl 5.6.1 on G4 Ti and tested under preinstalled 5.6.0 on G3 pismo. Dan the Man with Too Many Generations of Camels to Shepherd PERL_DL_NONLAZY=1 /Users/dankogai/bin/perl5.7.2 -Iblib/arch -Iblib/lib -e 'use Test::Harness qw(runtests $verbose); $verbose=0; runtests @ARGV;' t/*.t t/catalogv-string in use/require non-portable at blib/lib/MacOSX/File/Catalog.pm line 25. t/catalogok t/copy...v-string in use/require non-portable at blib/lib/MacOSX/File/Copy.pm line 22. t/copy...ok t/file...v-string in use/require non-portable at blib/lib/MacOSX/File.pm line 3. t/file...ok t/info...v-string in use/require non-portable at blib/lib/MacOSX/File/Info.pm line 23. t/info...ok t/spec...v-string in use/require non-portable at blib/lib/MacOSX/File/Spec.pm line 3. v-string in use/require non-portable at blib/lib/MacOSX/File.pm line 3. t/spec...ok All tests successful. Files=5, Tests=29, 9 wallclock secs ( 1.51 cusr + 0.36 csys = 1.87 CPU)
Re: One more psync question
On 2002.02.05, at 07:38, Mark Edwards wrote: I've also noticed that some of the directory sizes do not match between the psync copy and the original. This may be due to .* files not being copied, but in one case the directory was actually larger in the copy than in the original, despite containing fewer items (no .* files) This one I don't quite understand. On HFS+ directory size Always appears 0 (in blocks. Though ls -l shows something different). Maybe this is due to the fact that psync always copies finfo of the directory as well. Remeber on HFS+ directory is not a distinct file like UFS. Directory is just a catalog entry so the very size of the directory seems irrelevant. Well, I don't know what 0 drwxr-xr-x 2 dankogai dankogai 24 Feb 5 08:26 foo/ ^ This is # of blocks it takes. ^^This figure exactly mean myself. Because no matter how large a directory is, the number of blocks it actually takes is always 0 (or it is part of the catalog). Dan
Re: psync question
On 2002.02.05, at 09:23, Mark Edwards wrote: I don't know why I would have an old version. I downloaded the .61 source code and compiled it with perl Makefile.PL make make test make install I did compile version .41 earlier, but I never did make install, and I deleted the directory before doing anything with .61. Any suggestions? I think I got it. maybe you have to make install UNINST=1 to overwrite previously installed version. If the worse gets the worst, you can try rm -f `cat /Library/Perl/darwin/auto/MacOSX/File/.packlist` to delete the old files first then install 0.61 again. Dan
Re: psync question
On 2002.02.05, at 15:13, Mark Edwards wrote: That didn't work either. See, I didn't actually install a previous version. I've only done a make install with .61 I cleared every single file and directory that .61 installed, and I re-installed and got the same problem. I'm attaching the output of the install I just did, just in case you can see anything amiss there. I've seen your attachment and it looks all right. Here is what I want you to do. * instead of 'psync /from /to', try 'perl bin/psync /from /to' from MacOSX-file directory. * send /usr/local/bin/psync as is. I want to check to see if regexp is correct or gets mangled when it gets installed. What I don't understand is that there is no other report with the same symptom... I use it over and over on my platforms with no problem and got the same reports from everywhere... Dan
Re: psync question
I finally got the picture! On 2002.02.05, at 16:45, Mark Edwards wrote: The directory that caused problems was a standard ~/Sites/images directory. Here is the file list of the source directory: -rwxr-xr-x 1 mark staff 82 Feb 13 2001 ._apache_pb.gif -rwxr-xr-x 1 mark staff 82 Feb 13 2001 ._macosxlogo.gif -rwxr-xr-x 1 mark staff 82 Feb 13 2001 ._web_share.gif -rwxr-xr-x 1 mark staff 2326 Feb 13 2001 apache_pb.gif -rwxr-xr-x 1 mark staff 2829 Feb 13 2001 macosxlogo.gif -rwxr-xr-x 1 mark staff 13370 Feb 13 2001 web_share.gif And here is the file list of the psync copy: -rwxr-xr-x 1 mark staff 2326 Feb 13 2001 apache_pb.gif -rwxr-xr-x 1 mark staff 2829 Feb 13 2001 macosxlogo.gif -rwxr-xr-x 1 mark staff 13370 Feb 13 2001 web_share.gif Yes indeed psync DELIBERATELY ignores files that start with ._, not just . with a good reason. It is a FEATURE. Files that start with '._' is RESERVED BY APPLE to store finder info and resource fork. See http://developer.apple.com/techpubs/macosx/Essentials/SystemOverview/Finder/ The_Finder___Operations.html to get the picture. It appears that your '._' files exist on HFS+ volumes. Though possible it is not recommended. Try copying these files to UFS volume via cp command (you can create UFS file image via Disk Copy) then try psync again. Your destination files will be one piece. With a UFS volume you can try backwards -- HFS+ to UFS copy. In that case '._' files gets created for each file copied. Dan the Man with a Mistery Solved
Re: psync
Ulrich, Hi. On 2002.02.01, at 21:02, Ulrich auf dem Keller wrote: thanks for providing information on the useful psync command. I already tried it successfully for backups of entire partitions with a firewire drive as target directory. Since I would like to use it routinely on our institute MacOS X server I tried to include it into the root crontab file. Therefore I wrote a small script that only includes the path to psync and the psync command itself (I am a quite UNIX newbie). The problem was simple after all. See below. When I run the script as root from the command line being logged in as administrator and using sudo everything goes fine except that the finder is not able to display the icons before I logout and login again (this is no problem for me since I see everything correctly when browsing in the terminal). But when the cron job runs while nobody is logged in some files and directories are missing in the backup. Do you have any idea what is going wrong ? As for the icons psync does not backup Desktop (DB|DF) so simple desktop rebuilding will fix it (I deliberately did so but this can be altered very easily. Future version may include commandline switch to control which files/directories to ignore). And now for the cron Here is the little script for running psnyc: #!/bin/sh - # PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin sudo psync /Volumes/Data /Volumes/d-backup No. the trick is that you can't use sudo in cron. Remember you have to type in your password before you 'initialize' sudo? Anything that demands tty (that is, Terminal or any interactive commandline interface) will fail in cron. So here is what you should do in the script. And since you are already running as root via cron, there is no point sudoing; #!/bin/sh PATH=/bin:/usr/bin:/sbin:/usr/sbin:/usr/local/bin ; export PATH psync /Volumes/Data /Volumes/d-backup /var/tmp/psync.out 21 # put all output to /var/tmp/psync.out #end and here my crontab entry: 15 1 * * * rootsh /etc/backuptest This can stay as is. Dan
Re: MacOSX-File-bindist
On 2002.01.31, at 07:17, James Reynolds wrote: On http://search.cpan.org/search?dist=MacOSX-File in the section titled DEPENDENCIES you say: This module requires MacOS X. Develper kit is needed to make install. To get binary distribution, check MacOSX-File-bindist via CPAN. I can't find the binary anywhere. Can you help me out. I can't install the Dev Tools on the target Mac because it is going to be used in a disk image that is going to be distributed in a public lab (so size and security are the reason). The answer is simple. It has not been uploaded yet since MacOSX::File is still development phase. But it is faily stable now so I should upload it soon. Dan
Why not MacPerl X [Was: Re: Please DON'T]
On 2002.01.25, at 01:17, Cranz, Gregory wrote: Please, pretty please, carbonize MacPerl. I shudder to think of having to differentiate between both versions when debugging or having a conversation on this thread. IMHO, MacPerl was a stopgap that kept the Mac in the game until we've got OS/X i.e. Un*x to work with. It was wonderful I used it profusely. Hell I still do, with my older machines, but mixing both of them in one environment is asking, no begging for trouble. I am not in need of MacPerl X or Carbonized MacPerl myself, too. Still I find no reason for objecting MacPerl X. Windoze come w/ cygwin perl and ActivePerl. MacPerl X for OS X can be what ActivePerl is for Windoze. Or how about ProjectBuilder support Perl for those who are in need of IDE? As Larry Wall says, there are more than one way to do it. Well, for me Emacs is quite enough (caveat broken VC mode of preinstalled version). Dan the Man with Too Many Platforms to Support
Re: MacOSX::File uploaded to CPAN
Fred, on 02.1.9 9:12 AM, Wilfredo Sánchez at [EMAIL PROTECTED] wrote: Have you considered adding this functionality into existing File I/O code (possibly with some new options) instead of adding whole new API? Do you mean that I modify File::Copy? That's a possibility but as I answered in MacOSX::File::Copy vs. File::Coply, I believe File::Copy should behave like /bin/cp (actually, copy() does cp -p because it copies mtime and atime) while MacOSX::File::Copy behaves like /Developer/Tools/CpMac. No one knows if someone wants to explicitly copy(._file, elsewhere/._file) Other modules in question might BSD::stat, yet another module by me that works like CORE::stat and File::stat combined with BSD-specific fields. That one works perfectly fine on MacOSX as well (Not to mention FreeBSD and NetBSD. I'm yet to test that on OpenBSD but I believe it works). Darwin is surprisingly BSD maybe except for directory layouts. Dan the PM Writer
Namespace [Was: Re: MacOSX::File]
Hi Chris. Long time no see. on 02.1.9 7:46 AM, Chris Nandor at [EMAIL PROTECTED] wrote: Hi Dan. Two comments: Okay let me answer one by one. 1. Did you ask [EMAIL PROTECTED] about the namespace? I am not sure MacOSX is a good top-level namespace. Maybe I should have and I did think over this issue. But I can tell you what happened when I did ask for a namespace to [EMAIL PROTECTED] before. Back then when there was no 5.6 (and not even 5.005) I made a module called Jcode, which allows you to handle varios Japanese charset (en|de)coding. The name came from jcode.pl, a (very, very) popular package that existed before Perl5. Since this 'taints' top-level module namespace I did RFC in [EMAIL PROTECTED] and I got no response for a long time. Since that namespace was empty I did upload it and now Jcode is one of the most widely-used perl module in Japan (it's now a part of FreeBSD ports and many Linux packages). When it comes this far even I cannot change the situation. Anyway, since then my policy to upload a module is as follow; 0) Make sure it does not exist yet. 1) Upload and see what happens. So far so good. But of course, I am open to opinions. If enough number of you (well, even I am not sure how many would be enough. Say if my mailbox gets flooded with complaints) don't like it I am happy to change that. As for the toplevel 'MacOSX', I first considered 'Darwin' but Dawin's own /bin/cp and /bin/mv ignore Resource fork. Then I considered 'Carbon' but What actually my module does is to bridge both worlds. So I picked MacOSX, the name that contains both worlds. Dan the PM Writer
File::Copy vs. MacOSX::File::Copy [Was: Re: MacOSX::File uploadedto CPAN]
Now let me answer the 2nd question of Chris 2. Did you look at the modules in MacPerl that do the same thing, with an eye toward compatability of interfaces? Yes I did and I did check File::Copy myself as well. As a matter of fact File::Copy appears to be MacPerl-compliant already. In a course of writing MacOSX::File, 95% of the time is spent on research and just 1% is spent on actual coding (Don't you think this retio, research vs. coding is getting worse as time goes by?) on 02.1.9 8:44 AM, Ken Williams at [EMAIL PROTECTED] wrote: Also, File::Copy should copy files correctly on MacOS (X and otherwise), though I'm not sure whether it currently does so. Do you know the situation? The fact remains that /bin and /usr/bin ignores Carbon world. My understanding is that Darwin does not have to care MacOS world; it is left to Carbon that does. Therefore I belive File::Copy should do what /bin/cp does while mine does what /Developer/Tools/CpMac does. IMHO, a module like this should have been done by Apple... Dan the PM Writer
MacOSX::File uploaded to CPAN
Hi all, My name is Dan Kogai and this is my first time to drop a message here -- maybe with a good reason. I just uploaded a module called MacOSX::File, which allows you to write programs like the ones on /Developer/Tools. You can now copy() with resource fork and finder info, gets and sets finder flags, etc. Hope you guys like it. Any comments are welcome. Yours, Dan the JAPHOMOX -- _ Dan Kogai __/ CEO, DAN co. ltd. /__ /-+-/ 2-8-14-418 Shiomi Koto-ku Tokyo 135-0052 Japan /--/--- mailto: [EMAIL PROTECTED] / http://www.dan.co.jp/ - __/ /Tel:+81 3-5665-6131 Fax:+81 3-5665-6132 PGP Key: http://www.dan.co.jp/$B!1(Bdankogai/dankogai.pgp.asc
