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 /Users/alanfry/Droplets/ChangeMode.app
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 /Users/alanfry/Droplets/PerlScripts/ChangeMode.txt
#!/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 file' in the Terminal I'm not
sure...
Alan Fry
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: 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)
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)
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)
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]
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: 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 EOT;
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 (PROG) {
if (/lwp-request/) {
=
