Problem with System Beep
For some reason I can't hear a system beep. Maybe I'm mistaken, but isn't: print "\a"; suppose to generate a system beep? I'm using Mac OS X v10.2.3 and I remember being able to do this with v10.0.0. Thanks -John
Re: DBI and DBD::MySQL (Panther)
I would think this should stay out of the perl sources since it is not a bug of perl's... Thoughts? I also just discovered that this fixes a build problem with Data::Dumper... Or so it would appear. It's possible this will effect several packages. The patch should not be put in all the perl sources should it? C On 10/15/03 6:28 PM, "Edward Moy" <[EMAIL PROTECTED]> wrote: > In hints/darwin.sh, replace > > *) ld="MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; > > with > > *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; > > Hopefully, this will go into 5.8.2. > > Ed > > On Oct 15, 2003, at 5:05 PM, David Wheeler wrote: > >> On Wednesday, October 15, 2003, at 04:58 PM, Edward Moy wrote: >> >>> We recently discovered the DBD::mysql problem as well. The patch is >>> to edit >>> /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, >>> replacing: >>> >>> ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' >>> >>> with >>> >>> ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' >>> >>> Unfortunately, this change is too late to get into Panther. >> >> Is there a patch that could go into the Perl sources themselves? >> >> Regards, >> >> David >> >> -- >> David Wheeler AIM: dwTheory >> [EMAIL PROTECTED] ICQ: 15726394 >> http://www.kineticode.com/ Yahoo!: dew7e >>Jabber: >> [EMAIL PROTECTED] >> Kineticode. Setting knowledge in motion.[sm] >>
Re: DBI and DBD::MySQL (Panther)
Edward, I edited /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, switched perl back to the apple install and had no problems building DBD::mysql. Your information is greatly appreciated! c On 10/15/03 5:58 PM, "Edward Moy" <[EMAIL PROTECTED]> wrote: > We recently discovered the DBD::mysql problem as well. The patch is to > edit /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, > replacing: > > ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' > > with > > ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' > > Unfortunately, this change is too late to get into Panther. > --- > Edward Moy > Apple > > On Oct 15, 2003, at 1:52 PM, Conrad Schilbe wrote: > >> I was encountering the same errors as you in my quest to install >> DBD::mysql >> and discovered that under the following setup: >> >> Custom installed Perl 5.8.1 RC3 - No multi-threading >> ggc 2.95 - via /usr/sbin/gcc_select 2 >> >> Removing /sw/lib/perl5/Storable.pm & /sw/lib/perl5/auto/Storable >> >> I was able to compile and install Bundle::Msql which installs >> DBD::mysql. >> >> I cannot isolate wich of the above steps actually fixed the problem >> but I >> noted this difference in the make procedure: >> >> Running Mkbootstrap for DBD::mysql () >> chmod 644 mysql.bs >> rm -f ../blib/arch/auto/DBD/mysql/mysql.bundle >> LD_RUN_PATH="/usr/lib" MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle >> -undefined >> dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o >> -L/usr/local/mysql/lib -o >> ../blib/arch/auto/DBD/mysql/mysql.bundle -L/usr/local/mysql/lib >> -lmysqlclient -lm -lz >> chmod 755 ../blib/arch/auto/DBD/mysql/mysql.bundle >> cp mysql.bs ../blib/arch/auto/DBD/mysql/mysql.bs >> chmod 644 ../blib/arch/auto/DBD/mysql/mysql.bs >> >> >> Running Mkbootstrap for DBD::mysql () >> chmod 644 mysql.bs >> rm -f blib/arch/auto/DBD/mysql/mysql.bundle >> LD_RUN_PATH="/usr/lib" /usr/local/bin/perl myld >> MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -undefined dynamic_lookup >> -L/usr/local/lib dbdimp.o mysql.o -o >> blib/arch/auto/DBD/mysql/mysql.bundle >> -L/usr/local/lib -lz >> >> >> As you can see the first one carried on past the previous error point. >> >> >> I have a feeling that Bundle::Msql would successfully install under the >> default apple environment without switching gcc, without recompiling >> perl, >> and without removing Storable... I simply combined the methods of >> previous >> posts and hoped for the best. Later resorting to a memory of installing >> Bundle::Msql elsewhere. >> >> Someone should likely attempt to install Bundle::Msql under a clean OSX >> (Panther) install and report back on the outcome...
Re: DBI and DBD::MySQL (Panther)
In hints/darwin.sh, replace *) ld="MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; with *) ld="env MACOSX_DEPLOYMENT_TARGET=10.3 ${ld}" ;; Hopefully, this will go into 5.8.2. Ed On Oct 15, 2003, at 5:05 PM, David Wheeler wrote: On Wednesday, October 15, 2003, at 04:58 PM, Edward Moy wrote: We recently discovered the DBD::mysql problem as well. The patch is to edit /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, replacing: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' with ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' Unfortunately, this change is too late to get into Panther. Is there a patch that could go into the Perl sources themselves? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: DBI and DBD::MySQL (Panther)
On Wednesday, October 15, 2003, at 04:58 PM, Edward Moy wrote: We recently discovered the DBD::mysql problem as well. The patch is to edit /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, replacing: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' with ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' Unfortunately, this change is too late to get into Panther. Is there a patch that could go into the Perl sources themselves? Regards, David -- David Wheeler AIM: dwTheory [EMAIL PROTECTED] ICQ: 15726394 http://www.kineticode.com/ Yahoo!: dew7e Jabber: [EMAIL PROTECTED] Kineticode. Setting knowledge in motion.[sm]
Re: DBI and DBD::MySQL (Panther)
We recently discovered the DBD::mysql problem as well. The patch is to edit /System/Library/Perl/5.8.1/darwin-thread-multi-2level/Config.pm, replacing: ld='MACOSX_DEPLOYMENT_TARGET=10.3 cc' with ld='env MACOSX_DEPLOYMENT_TARGET=10.3 cc' Unfortunately, this change is too late to get into Panther. --- Edward Moy Apple On Oct 15, 2003, at 1:52 PM, Conrad Schilbe wrote: I was encountering the same errors as you in my quest to install DBD::mysql and discovered that under the following setup: Custom installed Perl 5.8.1 RC3 - No multi-threading ggc 2.95 - via /usr/sbin/gcc_select 2 Removing /sw/lib/perl5/Storable.pm & /sw/lib/perl5/auto/Storable I was able to compile and install Bundle::Msql which installs DBD::mysql. I cannot isolate wich of the above steps actually fixed the problem but I noted this difference in the make procedure: Running Mkbootstrap for DBD::mysql () chmod 644 mysql.bs rm -f ../blib/arch/auto/DBD/mysql/mysql.bundle LD_RUN_PATH="/usr/lib" MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -undefined dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o -L/usr/local/mysql/lib -o ../blib/arch/auto/DBD/mysql/mysql.bundle -L/usr/local/mysql/lib -lmysqlclient -lm -lz chmod 755 ../blib/arch/auto/DBD/mysql/mysql.bundle cp mysql.bs ../blib/arch/auto/DBD/mysql/mysql.bs chmod 644 ../blib/arch/auto/DBD/mysql/mysql.bs Running Mkbootstrap for DBD::mysql () chmod 644 mysql.bs rm -f blib/arch/auto/DBD/mysql/mysql.bundle LD_RUN_PATH="/usr/lib" /usr/local/bin/perl myld MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -undefined dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o -o blib/arch/auto/DBD/mysql/mysql.bundle -L/usr/local/lib -lz As you can see the first one carried on past the previous error point. I have a feeling that Bundle::Msql would successfully install under the default apple environment without switching gcc, without recompiling perl, and without removing Storable... I simply combined the methods of previous posts and hoped for the best. Later resorting to a memory of installing Bundle::Msql elsewhere. Someone should likely attempt to install Bundle::Msql under a clean OSX (Panther) install and report back on the outcome...
Re: DBI and DBD::MySQL (Panther)
Mike, I was encountering the same errors as you in my quest to install DBD::mysql and discovered that under the following setup: Custom installed Perl 5.8.1 RC3 - No multi-threading ggc 2.95 - via /usr/sbin/gcc_select 2 Removing /sw/lib/perl5/Storable.pm & /sw/lib/perl5/auto/Storable I was able to compile and install Bundle::Msql which installs DBD::mysql. I cannot isolate wich of the above steps actually fixed the problem but I noted this difference in the make procedure: Running Mkbootstrap for DBD::mysql () chmod 644 mysql.bs rm -f ../blib/arch/auto/DBD/mysql/mysql.bundle LD_RUN_PATH="/usr/lib" MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -undefined dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o -L/usr/local/mysql/lib -o ../blib/arch/auto/DBD/mysql/mysql.bundle -L/usr/local/mysql/lib -lmysqlclient -lm -lz chmod 755 ../blib/arch/auto/DBD/mysql/mysql.bundle cp mysql.bs ../blib/arch/auto/DBD/mysql/mysql.bs chmod 644 ../blib/arch/auto/DBD/mysql/mysql.bs Running Mkbootstrap for DBD::mysql () chmod 644 mysql.bs rm -f blib/arch/auto/DBD/mysql/mysql.bundle LD_RUN_PATH="/usr/lib" /usr/local/bin/perl myld MACOSX_DEPLOYMENT_TARGET=10.3 cc -bundle -undefined dynamic_lookup -L/usr/local/lib dbdimp.o mysql.o -o blib/arch/auto/DBD/mysql/mysql.bundle -L/usr/local/lib -lz As you can see the first one carried on past the previous error point. I have a feeling that Bundle::Msql would successfully install under the default apple environment without switching gcc, without recompiling perl, and without removing Storable... I simply combined the methods of previous posts and hoped for the best. Later resorting to a memory of installing Bundle::Msql elsewhere. Someone should likely attempt to install Bundle::Msql under a clean OSX (Panther) install and report back on the outcome... cschilbe
Re: Patch for LWP Makefile.PL
Ken Williams <[EMAIL PROTECTED]> writes: > There's still a flaw with the conflict-detection in LWP's Makefile.PL > that prevents /usr/bin/head from being overwritten by HEAD on Mac OS > X. The problem is that MakeMaker uses $Config{installscript} as the > installation location for EXE_FILES items, not $Config{sitebin} as was > assumed in the code. Therefore the conflict never gets detected when > those two paths are different. > > The patch below is against LWP 5.69. Applied. Regards, Gisle > = > --- Makefile.PL-orig Fri Jul 11 10:03:30 2003 > +++ Makefile.PL Fri Jul 11 10:08:46 2003 > @@ -87,7 +87,7 @@ > print < > This package comes with some sample programs that I can try > -to install in $Config{sitebin}. > +to install in $Config{installscript}. > > Note that you can avoid these questions by passing > the '-n' option to 'Makefile.PL'. > @@ -108,7 +108,7 @@ > The lwp-request program will use the name it is invoked with to > determine what HTTP method to use. I can set up alias for the most > common HTTP methods. These alias are also installed in > -$Config{sitebin}. > +$Config{installscript}. > > EOT > my @tmp; > @@ -116,7 +116,7 @@ > my $default = "y"; > # check that we don't overwrite something unrelated with > # the current defaults. > - if (open(PROG, "<$Config{sitebin}/$alias")) { > + if (open(PROG, "<$Config{installscript}/$alias")) { > $default = "n"; > while () { > if (/lwp-request/) { > =
Re: Cron & Progress Bar in OSX
At 9:48 am -0600 14/10/03, Doug McNutt wrote: At 00:16 +0100 10/14/03, Alan Fry wrote: do shell script "/Users/alanfry/Desktop/backatcha.pl" results in the error: ...backatcha.pl:perl:bad interpreter:Permission denied do shell script is misnamed as are a lot of other commands in AppleScript. What it really means is Tell the OS to execute something that has been flagged as executable by setting the x bit in its permissions for the user who is making the request. It doesn't matter whether the file pointed to is a shell script or not though AppleScript does invoke the bash shell to manage the execution and can accept bash commands directly. Compiled C code and perl scripts with a #! line are equally executable but you must set that x bit. The failure you report is that you didn't have execute permission. Right. JD pointed that out in his message -- but I am grateful for the amplification. Terminal is the easy way. The command is chmod 777 path_to_file which actually opens it up completely to anyone. The rightmost bit in each octal digit is the x bit for user, group, and world. man chmod for more. It would be nice if Finder allowed access to the x bit but it doesn't. It would be nice if Finder would execute a double-clicked file with the x bit set but. . . Steve?Is it possible to write an AppleScript to do that? Expanding James Reynolds idea (13th Oct) a little I have got the following to work: AppleScript (application) as file on open myFile set myPath to POSIX path of myFile display dialog "File: " & myPath & return & "Set new permissions as:" default answer "0755" set newMode to text returned of result set newPath to do shell script "/Users/alanfry/Droplets/PerlScripts/ChangeMode.txt \"" & myPath & "\" \"" & newMode & "\"" display dialog result buttons {"QUIT"} default button 1 end open Perl script as file #!/usr/bin/perl my $myFile = $ARGV[0]; my $perms = $ARGV[1]; $perms = oct $perms; my @list = stat($myFile); print "File: $myFile\n"; printf "%-32s%o\n", "Previous permissions were:", $list[2]; chmod "$perms", "$myFile"; @list = stat($myFile); printf "%-30s%o\n", "Current permissions are now:", $list[2]; On dropping any file onto the applet a dialog is put up asking for the new permissions (with 0755 as default suggestion). After clicking the 'OK' button the perl script changes the mode and puts up another AS dialog confirming the full-path file name, the previous permissions and the new current permissions. Comments would be very welcome. I suppose folders should be excluded and things like zip disks at the very least. Whether it's any improvement on typing 'chmod 0777 ' in the Terminal I'm not sure... Alan Fry