Copying files
Hi,
Thanks all for the help on the mail question a few days back. That's
fixed. Now I've run into another problem. I'm trying to copy a file on
a local network (off a PC) to my Mac. But when the script is called
from within cron, it seems that the script doesn't run. The cron looks
like this:
* * * * * /Users//Library/Scripts/backup.pl
The script is as follows:
#!/usr/bin/perl -w
use strict;
my @files = db1.txt, db2.txt, db3.txt, db4.txt;
foreach (@files) {
rename /path/to/pc/file/$_, /Users//Documents/$_..bak;
}
exit;
And finally, should I even use perl to do this? I'm comfortable with
the little perl I know, but should I use some sort of bash file -- I've
never messed with bash before, but maybe now is a good time to learn. I
don't even know if I am referencing bash correctly here.
Thanks for you help.
Mark
Re: Copying files
Hi,
Thanks all for the help on the mail question a few days back. That's
fixed. Now I've run into another problem. I'm trying to copy a file on
a local network (off a PC) to my Mac. But when the script is called
from within cron, it seems that the script doesn't run. The cron looks
like this:
* * * * * /Users//Library/Scripts/backup.pl
The script is as follows:
#!/usr/bin/perl -w
use strict;
my @files = db1.txt, db2.txt, db3.txt, db4.txt;
foreach (@files) {
rename /path/to/pc/file/$_, /Users//Documents/$_..bak;
You should always check that 'rename' succeeded (as apparently it isn't).
rename $oldfile, $newfile or warn Can't rename file: $!;
$! will then provide you more information as to why its not working.
}
exit;
And finally, should I even use perl to do this? I'm comfortable with
the little perl I know, but should I use some sort of bash file -- I've
never messed with bash before, but maybe now is a good time to learn. I
don't even know if I am referencing bash correctly here.
Using Perl is fine, but you want something other than 'rename'. I
suspect this is failing because you are attempting to move a file across
a filesystem boundary, from perldoc -f rename:
For example, it will usually not work across file system boundaries,
even though the system mv command sometimes compensates for this.
I would suggest File::Copy instead though make sure to check the docs
and test, I don't have my laptop to check for issues on OS X:
perldoc File::Copy
HTH,
http://danconia.org
Re: Image::Magick
On Apr 27, 2004, at 1:56 AM, Jan Eden wrote: But I'd still like to get Image::Magick working. Will experiment with various path names. From what you posted earlier, it looks like what you'll need to add: -L/usr/local/lib to LIB -I/usr/local/include -I/usr/local/include/freetype2 to INC Don't include the quotes, and don't replace what's there - just add the stuff between the quotes. sherm--
Re: Image::Magick
On Apr 26, 2004, at 3:52 AM, Jan Eden wrote: I did not find something like ltiff or ljpeg Libraries are more of a C thing than a Perl thing, but it's useful to know about for compiling extensions, so here goes. What you see there -ltiff -ljpeg are options that tell the linker to link against the tiff and jpeg libraries. The linker will look for one of several files in which to find those libraries. The file libtiff.a, is a static library - that is, linking against it will cause its contents to be copied into your application. So when your app runs, the separate library file doesn't need to be present - everything the app needs is built-in. This is convenient, but it has its drawbacks too - every app that uses the library has its own embedded copy of it, so it's wasteful. The alternative is shared (or dynamic) libraries. They can have a variety of names - libtiff.so, libtiff.dylib, or libtiff.bundle for Mac OS X, or libtiff.dll for Windows. When these are linked, only the name of the library is stored in the app, so the library file needs to be present when the app runs - which can complicate distribution. But it's more space-efficient - any number of apps can use the same library without having multiple copies of it. It also makes upgrading the library much easier - you can upgrade the single shared copy without having to rebuild all of the apps that use it. There is also a hidden, lurking evil behind dynamic libraries. If two libraries share the same name, but are not compatible - that is, they don't make the same functions available - then problems happen. Windows users call this DLL Hell; Perl users have often seen this manifest itself as dyld errors when loading modules that were compiled for a different version of Perl. Perl normally avoids this type of problem by putting extensions that have binary libraries in a version-specific directory; each version of Perl then looks only in its own directory for such modules. With earlier versions of Mac OS X however, Apple simplified things too much, using /System/Library/Perl and /Library/Perl without the version numbers. Thus, when users tried to upgrade to 5.8, their new 5.8 tried to load the old, incompatible modules that had been installed for 5.6, and Bad Things happened. They've corrected the problem - you'll notice that in Panther the version-specific directories have returned. Whew. That turned out to be longer than I'd expected - and it turned into a Perl thing there at the end. At least it's on-topic then. ;-) sherm--
Re: Image::Magick
On Tue, 27 Apr 2004, Sherm Pendley wrote: On Apr 27, 2004, at 1:56 AM, Jan Eden wrote: But I'd still like to get Image::Magick working. Will experiment with various path names. From what you posted earlier, it looks like what you'll need to add: -L/usr/local/lib to LIB -I/usr/local/include -I/usr/local/include/freetype2 to INC Don't include the quotes, and don't replace what's there - just add the stuff between the quotes. If you have Fink installed, then isn't the Easy Solution one of these: sudo fink install imagemagick or, for the pre-built binary version, sudo apt-get install imagemagick ? Hand-rolling popular software from source is nice and all, but how many times does the wheel need to be re-invented, ya know? :-) -- Chris Devers
Re: Image::Magick
On Apr 27, 2004, at 2:58 PM, Chris Devers wrote: how many times does the wheel need to be re-invented, ya know? :-) I've always thought that an odd expression. The first wheels were simply logs placed under a sled; when the sled had passed over them they were picked up and carried around to the front. We then found that narrow round slices of these logs could be mounted on an axle and carried with the sled. And then we made them lighter by switching to spokes, and made them more durable by putting iron bands around the rims. And we added tires to soften the ride, and then switched to tubeless tires. The wheel has been re-invented *many* times through history. ;-) sherm--
Re: Copying files
On Apr 27, 2004, at 12:59 PM, Wiggins d Anconia wrote: I would suggest File::Copy instead I second this, with one caveat: If you're backing up a file server that's used by pre-X Macs, or you're using Classic apps under X, you should be aware that File::Copy won't preserve resource forks. In that case you might want to use system() to call /Developer/Tools/CpMac instead. sherm--
Re: Image::Magick
On Tue, 27 Apr 2004, Sherm Pendley wrote: On Apr 27, 2004, at 2:58 PM, Chris Devers wrote: how many times does the wheel need to be re-invented, ya know? :-) I've always thought that an odd expression. Fair enough :-) But still, think about it: do we need to make one of these refinements to the basic design of the wheel every time we want to take a car from one state to another, or *gasp* drive to another country? Of course not. And yet here we are tinkering over building software when perfectly good package management software will not only do this for you on demand, but they'll even provide you with pre-made versions for your platform. And still people are out there sanding down their wheels from unhewn blocks of stone and crafting axles from the last remaining Live Oaks out in the back yard, with blood, sweat, and absolutely no power tools. For what? Now if you want to argue over what *color* our wheels should be, or what people want out of their wheels, that's a different matter entirely... :) -- Chris Devers
Re: Mod_perl woes...
I just stumbled into this EXACT same problem today while attempting to
get mod_perl up and running.
MacOSX 10.3.3
Perl v5.8.1-RC3
Apache 1.3.29
mod_perl 1.26
My 'stupid' test script:
#!/usr/bin/perl
print Content-type: text/plain\n\n;
print mod_perl rules!\n;
Carl's first example script below works for me, too. I also found an
article by David Wheeler over at MacDevCenter regarding building Apache
with mod_perl and a little snippet of httpd.conf code works, also:
PerlModule Apache::Status
Location /perl-status
SetHandler perl-script
PerlHandler Apache::Status
/Location
Has anyone solved this issue? I'm contemplating installing up to date
versions of perl and mod_perl and give that a shot.. (Three days
later.. Naw, I'm just really tired.)
--
Benjamin Adair
Central Office Database Programmer/Analyst
Cancer Leukemia Group B
Phone: 773-702-6731
Fax: 312-345-0117
Email: badair at uchicago dot edu
Web: http://www.calgb.org/
On Nov 24, 2003, at 4:00 AM, Carl Cunningham wrote:
Hi folks,
I'm having a devil of a time with something that should be very easy.
I'm
using mod_perl and CGI::Application for some pokey stuff, and my
scripts run
just dandy in a CGI environment, but outputs absolutely nothing in my
mod_perl setup.
I'm using:
MacOSX 10.3
Perl 5.8.1 (the standard delivered version)
Mod_perl 1.26 (the standard delivered version)
Apache 1.3.28 (the standard delivered version)
perl -MApache -e 'print $Apache::VERSION' = 1.27
perl -Mmod_perl -e 'print $mod_perl::VERSION' = 1.26
perl -MCGI -e 'print $CGI::VERSION' = 3.00
Here's my Apache::Registry Configuration out of the httd.conf
PerlModule Apache::Registry
Location /registry
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Location
Now this is where it gets weird. Following script works dandy:
my $r = Apache-request;
$r-content_type(text/html);
$r-send_http_header;
$r-print(Hi There!);
But this script only generates output in a CGI environment:
use strict ;
use CGI ;
my($q) = new CGI ;
print $q-header,
$q-start_html('hello world'),
$q-h1('hello world'),
$q-end_html;
--
Carl K. Cunningham
Roberts´ interactive GmbH
E-Mail: initials of first and last name, at 'roberts' dot 'de'
---
-
Re: Image::Magick
On Apr 27, 2004, at 3:45 PM, Chris Devers wrote: But still, think about it: do we need to make one of these refinements to the basic design of the wheel every time we want to take a car from one state to another, or *gasp* drive to another country? Of course not. Oh, I agree for the most part. The original poster, though, asked a question that (as far as I know) Fink can't answer. He already has ImageMagick and a given set of libraries, and he wants to install PerlMagick to use those. I can think of a couple ways that one *might* be able to convince Fink to install it that way - but neither of them is easy. And yet here we are tinkering over building software when perfectly good package management software will not only do this for you on demand, but they'll even provide you with pre-made versions for your platform. No argument here. Heck, I'm one of the people providing pre-made versions. The unfortunate fact is though, that no package management is perfect, and the pre-made versions won't always fit everyone's need. That's why open source is a Good Thing. It's good to have the option of a custom build, even when it's an option of last resort. sherm--
Re: Copying files
On Apr 27, 2004, at 11:59 AM, Wiggins d Anconia wrote:
The script is as follows:
#!/usr/bin/perl -w
use strict;
my @files = db1.txt, db2.txt, db3.txt, db4.txt;
foreach (@files) {
rename /path/to/pc/file/$_, /Users//Documents/$_..bak;
You should always check that 'rename' succeeded (as apparently it
isn't).
rename $oldfile, $newfile or warn Can't rename file: $!;
$! will then provide you more information as to why its not working.
I'd be willing to bet that it will be because there's no file called
/path/to/pc/file/db1.txt, db2.txt, db3.txt, db4.txt
on your system. Perhaps you mean:
my @files = (db1.txt, db2.txt, db3.txt, db4.txt);
or just
my @files = qw(db1.txt db2.txt db3.txt db4.txt);
Anyway, Wiggins is right - if you'd checked the error status, $! would
have told you...
-Ken
Re: Image::Magick
Yes, open-source makes advanced things possible. But does installing Imagemagick and Perlmagick really need to be in the advanced category? Took me (a unix newbie, I admit) an awfully long time to get it working, and I never would have succeeded without access to a personal expert who had done it before himself. As I recall, these were the major steps: 1. Installed Fink. 2. Installed Imagemagick via Fink. 3. Installed a whole new Perl, since Perlmagick seemed to require a newer version than Apple provided. 4. Downloaded Imagemagick source just to get Perlmagick, then installed Perlmagick from source. I'm afraid I didn't take notes on all the minor stumbling blocks I encountered along the way, or I'd post more detailed instructions to save others the headaches. I do remember that it took me a very long time to get PerlMagick to build without errors. There was something about editing a makefile, which I first did incorrectly, then fixed it but it kept using the old renamed version until I moved that to a different directory. Or something. Now it all works, but I dread the next time I have to touch anything. Of course, there may have been an easier way that I didn't discover. Maybe you can install Perlmagick via Fink, though when I checked it was labeled unstable, and only available from source. So I offer my sympathy to others who are going through this ordeal, and I beg the experts to come up with a better method, or at least better instructions. Thanks for listening, Dan On Apr 27, 2004, at 2:28 PM, Sherm Pendley wrote: On Apr 27, 2004, at 3:45 PM, Chris Devers wrote: But still, think about it: do we need to make one of these refinements to the basic design of the wheel every time we want to take a car from one state to another, or *gasp* drive to another country? Of course not. Oh, I agree for the most part. The original poster, though, asked a question that (as far as I know) Fink can't answer. He already has ImageMagick and a given set of libraries, and he wants to install PerlMagick to use those. I can think of a couple ways that one *might* be able to convince Fink to install it that way - but neither of them is easy. And yet here we are tinkering over building software when perfectly good package management software will not only do this for you on demand, but they'll even provide you with pre-made versions for your platform. No argument here. Heck, I'm one of the people providing pre-made versions. The unfortunate fact is though, that no package management is perfect, and the pre-made versions won't always fit everyone's need. That's why open source is a Good Thing. It's good to have the option of a custom build, even when it's an option of last resort. sherm--
Re: Image::Magick
On Apr 27, 2004, at 5:18 PM, Dan Schroeder wrote: But does installing Imagemagick and Perlmagick really need to be in the advanced category? Well, the original poster had a detailed set of requirements that Fink cannot easily fulfill - he wanted to use a specific set of libraries that he'd already installed under /usr/local. I'd say that yes, that level of fine-grained control is advanced. It's beyond what one can reasonably expect of a package manager like Fink. What's more, PerlMagick is well-known for being horribly difficult to configure and install. It wraps around a complex C library, which in turn depends on a variety of other libraries - you can easily find yourself lost in a twisty maze of dependencies, all alike. So I offer my sympathy to others who are going through this ordeal, and I beg the experts to come up with a better method, or at least better instructions. PerlMagick does seem to come up fairly often. What do the rest of you think? Would you like to see a Fat Camel package of graphics modules? Are there any other modules you'd like to see in it, aside from PerlMagick and Imager, which have already been mentioned? We probably shouldn't clutter the list with module requests, so email those to me privately, and I'll summarize to the list in a few days. sherm--
reinventing wheels (was Re: Image::Magick)
On 2004.4.28, at 03:58 AM, Chris Devers wrote: ... Hand-rolling popular software from source is nice and all, but how many times does the wheel need to be re-invented, ya know? :-) sherm: The first wheels were simply logs placed under a sled; ... We probably shouldn't clutter the list with module requests, so email those to me privately, and I'll summarize to the list in a few days. Like the analogy, Sherm. (Apologies to Chris Devers and to the list for cluttering it with noise, but this thread made me think of a new tag-line.) -- Joel Rees If God hadn't meant for us to tweak our source code, He'd've given us Microsoft. ;-P
Re: Copying files
Yup. You're right. I missed that one. Here's what I did to simplify the
testing of the script.
#!/usr/bin/perl -w
use strict;
use File::Copy;
copy(/Users/xx/Documents/db1.txt,
/Users/xx/Documents/db1.txt.bak) or warn Can't copy file: $!;
print Backup Completed.;
exit;
-
I know the cron is firing off the request, because when first tried it,
I got Permission Denied in my email box. So I changed the permission to
755 and it still doesn't copy the file. And I get nothing in my email
box. I'm a little confused. What am I missing?
Mark
On Apr 27, 2004, at 1:31 PM, Ken Williams wrote:
On Apr 27, 2004, at 11:59 AM, Wiggins d Anconia wrote:
The script is as follows:
#!/usr/bin/perl -w
use strict;
my @files = db1.txt, db2.txt, db3.txt, db4.txt;
foreach (@files) {
rename /path/to/pc/file/$_, /Users//Documents/$_..bak;
You should always check that 'rename' succeeded (as apparently it
isn't).
rename $oldfile, $newfile or warn Can't rename file: $!;
$! will then provide you more information as to why its not working.
I'd be willing to bet that it will be because there's no file called
/path/to/pc/file/db1.txt, db2.txt, db3.txt, db4.txt
on your system. Perhaps you mean:
my @files = (db1.txt, db2.txt, db3.txt, db4.txt);
or just
my @files = qw(db1.txt db2.txt db3.txt db4.txt);
Anyway, Wiggins is right - if you'd checked the error status, $! would
have told you...
-Ken
Re: Copying files
On 4/27/04 Mark Wheeler wrote: Yup. You're right. I missed that one. Here's what I did to simplify the testing of the script. copy(/Users/xx/Documents/db1.txt, /Users/xx/Documents/db1.txt.bak) or warn Can't copy file: $!; - I know the cron is firing off the request, because when first tried it, I got Permission Denied in my email box. So I changed the permission to 755 and it still doesn't copy the file. And I get nothing in my email box. I'm a little confused. What am I missing? Is that Permission Denied for execution of your script? Perhaps it's for writing the file. Check the write permissions of the /Users/xx/Documents directory. 1; - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Copying files
Hi Bruce, Good question. Here are the results. The permissions for the /Users/xx/Documents directory is: drwx-- 7 xx xx 238 27 Apr 15:08 Documents The permission for the /Users/xx/Library/Scripts directory is: drwxr-xr-x 3 xx xx 102 27 Apr 14:22 Scripts Does that look write? Or should the Documents directory be the same as the Scripts Directory? Thanks, Mark On Apr 27, 2004, at 3:24 PM, Bruce Van Allen wrote: On 4/27/04 Mark Wheeler wrote: Yup. You're right. I missed that one. Here's what I did to simplify the testing of the script. copy(/Users/xx/Documents/db1.txt, /Users/xx/Documents/db1.txt.bak) or warn Can't copy file: $!; - I know the cron is firing off the request, because when first tried it, I got Permission Denied in my email box. So I changed the permission to 755 and it still doesn't copy the file. And I get nothing in my email box. I'm a little confused. What am I missing? Is that Permission Denied for execution of your script? Perhaps it's for writing the file. Check the write permissions of the /Users/xx/Documents directory. 1; - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Copying files
On 4/27/04 Mark Wheeler wrote: Good question. Here are the results. The permissions for the /Users/xx/Documents directory is: drwx-- 7 xx xx 238 27 Apr 15:08 Documents The permission for the /Users/xx/Library/Scripts directory is: drwxr-xr-x 3 xx xx 102 27 Apr 14:22 Scripts Does that look right? Or should the Documents directory be the same as Most likely your script is not running as owner, so you probably want drwxrwxrwx for the Documents directory ( chmod 0777, '/Users/xx/Documents' ). The Scripts directory is correct. On Apr 27, 2004, at 3:24 PM, Bruce Van Allen wrote: Is that Permission Denied for execution of your script? Perhaps it's for writing the file. Check the write permissions of the /Users/xx/Documents directory. 1; - Bruce __bruce__van_allen__santa_cruz__ca__
Re: reinventing wheels (was Re: Image::Magick)
On Apr 27, 2004, at 6:07 PM, Joel Rees wrote: sherm: We probably shouldn't clutter the list with module requests (Apologies to Chris Devers and to the list for cluttering it with noise Sorry, I didn't mean to imply that your request for help with PerlMagick was noise. Far from it - that's what this list is here for. What I meant was, if anyone has a request for me to include a particular module in a Fat Camel package, just send me that privately. If God hadn't meant for us to tweak our source code, He'd've given us Microsoft. I like it! ;-) sherm--
Re: Copying files
OK... I changed the permissions. Still no change. The file is not being backed up. How do I check to see if the script is even executing? Is there a log I can look at? I haven't changed anything from the standard install for 10.3. I'm the only person on the machine. Do I need to activate perl like I need to when running apache? Thanks so much for your help, Mark On Apr 27, 2004, at 3:46 PM, Bruce Van Allen wrote: On 4/27/04 Mark Wheeler wrote: Good question. Here are the results. The permissions for the /Users/xx/Documents directory is: drwx-- 7 xx xx 238 27 Apr 15:08 Documents The permission for the /Users/xx/Library/Scripts directory is: drwxr-xr-x 3 xx xx 102 27 Apr 14:22 Scripts Does that look right? Or should the Documents directory be the same as Most likely your script is not running as owner, so you probably want drwxrwxrwx for the Documents directory ( chmod 0777, '/Users/xx/Documents' ). The Scripts directory is correct. On Apr 27, 2004, at 3:24 PM, Bruce Van Allen wrote: Is that Permission Denied for execution of your script? Perhaps it's for writing the file. Check the write permissions of the /Users/xx/Documents directory. 1; - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Copying files
On 4/27/04 Mark Wheeler wrote:
OK... I changed the permissions. Still no change. The file is not being
backed up.
One more permission to check, which is whether the original file may be
read 'executed' by your script. Should be:
-rwxr-xr-x
How do I check to see if the script is even executing? Is
there a log I can look at? I haven't changed anything from the standard
install for 10.3. I'm the only person on the machine. Do I need to
activate perl like I need to when running apache?
Always test the result of actions taken in your script, especially
things that the operating system gets involved in, like filesystem
calls.
Get back to a simple starting point. Set aside the cron stuff for a
minute. Just see if you can execute the script from the command line, an
Apache CGI call, or perhaps a BBEdit shell worksheet. Also, try a script
that doesn't do anything to any files, like the classic:
#!/usr/bin/perl -w
print Hello, World;
__END__
Now try to *open* your original file, testing for open()'s result.
If successful, then read and print out the first four lines of the file.
#!/usr/bin/perl -w
use strict;
my $file= '/Users/xx/Documents/file.txt';
open FILE, $file
or die Can't open $file:\n$!\n;
for (1..4) {
print FILE
}
close FILE;
__END__
Note that you don't need the '__END__'; I've put them above to make
clear where each little script ends.
In some situations, you'd even want to test the result of close(FILE).
You can access your various OS X logs with the Console app, the latest
(Panther) version of which is nice enough to already know where the logs
are.
But you can learn lots just by making use of die() and other Perl
functions and pragmas (plus your logged error messages will have more
info in them). In the words of programmer and regex adept Ronald J.
Kimball, Leave a useful error message when you die.
For myself, something short of Tim Leary's Why not? Why not! Why not.
will do. For my coding heirs, I promise
Can't open /Users/xx/Documents/file.txt:
No such file or directory
The No such file or directory, Permission denied, etc. messages come
from the system, expressed via the Perl special variable $!.
1;
- Bruce
__bruce__van_allen__santa_cruz__ca__
Re: Copying files
On Apr 27, 2004, at 5:07 PM, Mark Wheeler wrote: Yup. You're right. I missed that one. Here's what I did to simplify the testing of the script. #!/usr/bin/perl -w use strict; use File::Copy; copy(/Users/xx/Documents/db1.txt, /Users/xx/Documents/db1.txt.bak) or warn Can't copy file: $!; print Backup Completed.; exit; - I know the cron is firing off the request, because when first tried it, I got Permission Denied in my email box. So I changed the permission to 755 and it still doesn't copy the file. And I get nothing in my email box. I'm a little confused. What am I missing? First rule when it looks like a script isn't doing anything on OS X: check the line endings. Make sure they're unix-style. If they're Mac-Classic style, running the script won't actually do anything. First rule when setting up cron jobs: make sure cron itself is running. Set up a job with the same timings as the script in question, but make its action echo foo or something like that. You should get an email when it runs. If not, then cron's the problem, not perl. I know you said it worked before, but just to make sure... -Ken
Re: Copying files
On Apr 27, 2004, at 5:46 PM, Bruce Van Allen wrote: On 4/27/04 Mark Wheeler wrote: Good question. Here are the results. The permissions for the /Users/xx/Documents directory is: drwx-- 7 xx xx 238 27 Apr 15:08 Documents The permission for the /Users/xx/Library/Scripts directory is: drwxr-xr-x 3 xx xx 102 27 Apr 14:22 Scripts Does that look right? Or should the Documents directory be the same as Most likely your script is not running as owner, so you probably want drwxrwxrwx for the Documents directory ( chmod 0777, '/Users/xx/Documents' ). That's a bad idea. I wouldn't want *my* Documents directory world-writable. The cron script is going to run as the user who sets it up, so it's not necessary either. -Ken
Re: Copying files
On 4/27/04 Ken Williams wrote: On Apr 27, 2004, at 5:46 PM, Bruce Van Allen wrote: Most likely your script is not running as owner, so you probably want drwxrwxrwx for the Documents directory ( chmod 0777, '/Users/xx/Documents' ). That's a bad idea. I wouldn't want *my* Documents directory world-writable. Of course you're right. I wasn't thinking of it as THAT Documents directory, even though I reproduced the OP's path with '/Users' in it... The cron script is going to run as the user who sets it up, so it's not necessary either. Ah. Thanks. - Bruce __bruce__van_allen__santa_cruz__ca__
Re: Image::Magick
Sherm Pendley wrote on 27.04.2004: On Apr 27, 2004, at 1:56 AM, Jan Eden wrote: But I'd still like to get Image::Magick working. Will experiment with various path names. From what you posted earlier, it looks like what you'll need to add: -L/usr/local/lib to LIB -I/usr/local/include -I/usr/local/include/freetype2 to INC Don't include the quotes, and don't replace what's there - just add the stuff between the quotes. Thanks, the part suggested for LIB was already present, I added the other string to INC, but still get a lot of errors on both make and make test, about non constant initializer elements, undeclared functions and the like. - Jan -- There are 10 kinds of people: those who understand binary, and those who don't
Re: Image::Magick
Sherm Pendley wrote on 27.04.2004: On Apr 27, 2004, at 3:45 PM, Chris Devers wrote: But still, think about it: do we need to make one of these refinements to the basic design of the wheel every time we want to take a car from one state to another, or *gasp* drive to another country? Of course not. Oh, I agree for the most part. The original poster, though, asked a question that (as far as I know) Fink can't answer. He already has ImageMagick and a given set of libraries, and he wants to install PerlMagick to use those. I can think of a couple ways that one *might* be able to convince Fink to install it that way - but neither of them is easy. Yes, and I already checked out the Fink packages. Fink's PerlMagick depends on Fink's ImageMagick, which I do not want to install in addition to my existing ImageMagick. - Jan -- Either this man is dead or my watch has stopped. - Groucho Marx
Re: Copying files
OK... I got the foo in my mailbox, so cron is working. So I'll go with the next step of a basic perl script. Mark On Apr 27, 2004, at 8:23 PM, Ken Williams wrote: On Apr 27, 2004, at 5:07 PM, Mark Wheeler wrote: Yup. You're right. I missed that one. Here's what I did to simplify the testing of the script. #!/usr/bin/perl -w use strict; use File::Copy; copy(/Users/xx/Documents/db1.txt, /Users/xx/Documents/db1.txt.bak) or warn Can't copy file: $!; print Backup Completed.; exit; - I know the cron is firing off the request, because when first tried it, I got Permission Denied in my email box. So I changed the permission to 755 and it still doesn't copy the file. And I get nothing in my email box. I'm a little confused. What am I missing? First rule when it looks like a script isn't doing anything on OS X: check the line endings. Make sure they're unix-style. If they're Mac-Classic style, running the script won't actually do anything. First rule when setting up cron jobs: make sure cron itself is running. Set up a job with the same timings as the script in question, but make its action echo foo or something like that. You should get an email when it runs. If not, then cron's the problem, not perl. I know you said it worked before, but just to make sure... -Ken
