Memory.bundle will not compile.
I have a script which runs fine on OS 10.6.8 but fails on 10.7.2. The error message is this: inline: Screen Shot 2013-12-12 at 14.37.31.png the script itself begins: #!/usr/bin/perl use PDF::API2; use Mac::OSA; and the error occurs at 'use Mac::OSA;' Any help would be appreciated. Alan Fry
MacOSX-File-0.71
Installation of MacOSX-File-0.71 on 10.6.6 (Perl 5.10.0) fails with the following errors: Kanga:MacOSX-File-0.71 alanfry$ 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 Kanga:MacOSX-File-0.71 alanfry$ make 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.10.0/ExtUtils/xsubpp -typemap /System/Library/Perl/5.10.0/ExtUtils/typemap Catalog.xs Catalog.xsc mv Catalog.xsc Catalog.c gcc-4.2 -c -I../ -I/Developer/Headers/FlatCarbon -arch x86_64 -arch i386 -arch ppc -g -pipe -fno-common -DPERL_DARWIN -fno-strict-aliasing -I/usr/local/include -Os -DVERSION=\0.70\ -DXS_VERSION=\0.70\ -I/System/Library/Perl/5.10.0/darwin-thread-multi-2level/CORE Catalog.c Catalog.xs: In function ‘xs_getcatalog’: Catalog.xs:70: error: subscripted value is neither array nor pointer Catalog.xs: In function ‘xs_setcatalog’: Catalog.xs:181: error: subscripted value is neither array nor pointer Catalog.xs: In function ‘XS_MacOSX__File__Catalog_xs_setcatalog’: Catalog.xs:263: warning: assignment makes pointer from integer without a cast In file included from Catalog.xs:17: ../common/macdate.c: In function ‘D2UDT’: ../common/macdate.c:30: warning: integer constant is too large for ‘long’ type Catalog.xs: In function ‘xs_setcatalog’: Catalog.xs:155: warning: ‘FSpRstFLock’ is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:10257) Catalog.xs:231: warning: ‘FSpSetFLock’ is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:10241) Catalog.xs: In function ‘XS_MacOSX__File__Catalog_xs_setcatalog’: Catalog.xs:263: warning: assignment makes pointer from integer without a cast In file included from Catalog.xs:17: ../common/macdate.c: In function ‘D2UDT’: ../common/macdate.c:30: warning: integer constant is too large for ‘long’ type Catalog.xs: In function ‘xs_setcatalog’: Catalog.xs:155: warning: ‘FSpRstFLock’ is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:10257) Catalog.xs:231: warning: ‘FSpSetFLock’ is deprecated (declared at /System/Library/Frameworks/CoreServices.framework/Frameworks/CarbonCore.framework/Headers/Files.h:10241) Catalog.xs: In function ‘XS_MacOSX__File__Catalog_xs_setcatalog’: Catalog.xs:263: warning: assignment makes pointer from integer without a cast lipo: can't open input file: /var/folders/N8/N8iepXMZEmGqNnd+KxwGgE+++TI/-Tmp-//ccyaLHkm.out (No such file or directory) Can anyone suggest a fix? Or does anyone know how to contact the author? The module was used in various script on 10.5.8 (Perl 5.8.0). The difficulties seem to have arisen in the system upgrade to Snow Leopard. I would be grateful for any help. Alan Fry
Re: location of 'com.apple.versioner.perl'
On 9 Jul 2010, at 18:27, Chris Devers wrote: On Fri, Jul 9, 2010 at 6:42 AM, Packy Anderson packyander...@gmail.com wrote: On Fri, Jul 9, 2010 at 6:39 AM, Alan Fry a...@afco.demon.co.uk wrote: However for the life of me I cannot find the file 'com.apple.versioner.perl.plist' on that machine. It is not in /Library/Preferences. What am I missing? Did you also look under ~/Library/Preferences? It's ~/Library/Preferences/com.apple.versioner.perl.plist Here's how you prove it, and any other questions like this: 1/ In one Terminal window, run `sudo filebyproc.d | grep -i plist` 2/ In another Terminal window, run the defaults command in question 3/ In the original window, hit ctrl-C to cancel, then examine the results. Tweak the grep filter as needed and you can use this trick to isolate all kinds of weird what file is that damned thing looking at type questions. Thank you for this tip -- 'filebyproc.d' is a new one to me. One learns something everyday. Could be really useful, as you say, to find out who's doing what to whom. I am still bothered about putting a 'Prefer-32-bit plist' on someone else's computer (via the installer) just for the sake of Mac::Processes. What if the owner prefers 64 bit...? Alan
location of 'com.apple.versioner.perl'
A script using Mac::Processes failed on OS 10.6.3 because of a 64/32 bit issue. Following the recommendations in 'man perl' I ran defaults write com.apple.versioner.perl Prefer-32-bit -bool yes which fixed the problem. However for the life of me I cannot find the file 'com.apple.versioner.perl.plist' on that machine. It is not in / Library/Preferences. What am I missing? Secondly in a '.pkg' distribution for the script how should one manage the possibility the installation might be on either a 32 bit or 64 bit system? Is there any disadvantage in running that 'defaults' line (above) irrespective of the OS (and/or) Perl versions? Suggestions would be most gratefully received. Alan Fry
Re: Perl install problems OSX 10.4.11
the following in Terminal:
perl -e 'foreach (@INC) {print$_\n}'
In the unlikely event it is not in the list, then add it to @INC.
I hope these notes might be helpful to someone relatively unused to
Perl and apologise if I appear, so to speak, to be trying to teach my
grandmother to suck eggs...
Alan Fry
(PS I am afraid I shall be away for ten days from tomorrow and unable
to respond until I get back.)
Re: Sudden death of PDF::API2
On 15 Feb 2009, at 13:01, Landry Le Chevanton wrote: I did also had problems with perl scripts after installing the security patch. Strategy for fixing has been worked out and reported here: http://bulknews.typepad.com/blog/2009/02/mac-os-x-security-update-2009001-br eaks-perl-cpan.html As well as in Apple forum http://discussions.apple.com/thread.jspa?threadID=1905157tstart=0 Thank you very much for these links, which confirmed it was the security patch which was the cause of the problem and gave a good start on how to go about fixing the matter. This recipe worked for me so far. I reinstalled IO-1.2301 and Compress-Zlib but this did not restore functionality to PDF::API2. Running one of the 'example scripts' provided in the documentation for Zlib.pm resulted in an error involving 'dualval' which turned out to be a subroutine in Scalar::Utils which is 'use'd by Zlib.pm. Reinstalling Scalar-List-Utils-1.19 fixed that problem and also (thankfully) restored PDF::API2. I am not sure what happened to Scalar::Utils when the security patch was applied but I have a suspicion it might have been deleted? Whilst these measures have fixed my immediate problems with Perl I fear we may yet see some more bugs emerging from the woodwork as time goes on. I am most grateful for your help, Kind regards, Alan Landry Le 15/02/09 12:10, « Alan Fry » a...@afco.demon.co.uk a écrit : I have an Intel MacPro running Mac OS X 10.5.6 (Perl 5.8.8) and a copy of PDF::API2. This has worked flawlessly for a long time. Suddenly it has failed. There have been no changes at all to the machine apart from a recent 'Security Update', which I think had to do mostly with a loophole in Safari. This minimal script: my $pdf_in = PDF::API2-open($file_in) or die $!\n; my $pdf_out = PDF::API2-new or die $!\n; $page = $pdf_out-page; $page-mediabox(595, 842); $gfx = $page-gfx; #$xo = $pdf_out-importPageIntoForm($pdf_in, 1); #$gfx-formimage($xo, 0, 0, 1); fails with the error message: Undefined subroutine Compress::Zlib::compress called at /Library/ Perl/ 5.8.8/PDF/API2/Content.pm line 103. However the folder 'Compress' is there, (alongside the folder 'PDFwhich contains the module), the file 'Zlib' in that folder, and Zlib has a subroutine named 'compress'. So what can possibly have gone wrong here? If the last two lines above are uncommented, the error message becomes: Can't call method infilt on an undefined value at /Library/Perl/ 5.8.8/PDF/API2/Util.pm line 667. presumably as a result of failure to access Zlib subroutines? I have run 'repair permissions' which has not altered the situation and run out of ideas of what to do next. I would be most grateful if anyone could help. Alan Fry
Sudden death of PDF::API2
I have an Intel MacPro running Mac OS X 10.5.6 (Perl 5.8.8) and a copy of PDF::API2. This has worked flawlessly for a long time. Suddenly it has failed. There have been no changes at all to the machine apart from a recent 'Security Update', which I think had to do mostly with a loophole in Safari. This minimal script: my $pdf_in = PDF::API2-open($file_in) or die $!\n; my $pdf_out = PDF::API2-new or die $!\n; $page = $pdf_out-page; $page-mediabox(595, 842); $gfx = $page-gfx; #$xo = $pdf_out-importPageIntoForm($pdf_in, 1); #$gfx-formimage($xo, 0, 0, 1); fails with the error message: Undefined subroutine Compress::Zlib::compress called at /Library/Perl/ 5.8.8/PDF/API2/Content.pm line 103. However the folder 'Compress' is there, (alongside the folder 'PDFwhich contains the module), the file 'Zlib' in that folder, and Zlib has a subroutine named 'compress'. So what can possibly have gone wrong here? If the last two lines above are uncommented, the error message becomes: Can't call method infilt on an undefined value at /Library/Perl/ 5.8.8/PDF/API2/Util.pm line 667. presumably as a result of failure to access Zlib subroutines? I have run 'repair permissions' which has not altered the situation and run out of ideas of what to do next. I would be most grateful if anyone could help. Alan Fry
Installing PerlMagick-6.32
Attempts to install PerlMagic on an Intel Mac running OS 10.5.1 (using MCPAN) result in the following failure: Running make test /bin/sh ../magick.sh PERL_DL_NONLAZY=1 /usr/bin/perl - MExtUtils::Command::MM -e test_harness(0, 'blib/lib', 'blib/ arch') t/*.t t/bzlib/*.t t/jpeg/*.t t/mpeg/*.t t/png/*.t t/ps/*.t t/ tiff/*.t t/x/*.t t/xfig/*.t t/zlib/*.t /bin/sh: ../magick.sh: No such file or directory make: *** [test_dynamic] Error 127 JCRISTY/PerlMagick-6.32.tar.gz /usr/bin/make test -- NOT OK //hint// to see the cpan-testers results for installing this module, try: reports JCRISTY/PerlMagick-6.32.tar.gz Running make install make test had returned bad status, won't install without force The file magic.sh certainly does not exist -- where should it have come from? (I cannot find reports JCRISTY/PerlMagick-6.32.tar.gz, BTW.) I would be grateful if anyone could tell me what to do to resolve this problem. Regards, Alan Fry
Term-Gnuplot0.9030905 installation
On running 'make', 91(!) error messages of this kind occur (all much
the same):
In file included from /System/Library/Frameworks/Foundation.framework/
Headers/Foundation.h:12,
from term/openstep.trm:90,
from term.h:149,
from term.c:1002:
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:60: error: syntax error at '@' token
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:60: error: parse error before NSString
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:62: error: parse error before '*' token
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:63: error: parse error before '*' token
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:64: error: parse error before '*' token
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:65: error: parse error before '*' token
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:68: error: parse error before '*' token
/System/Library/Frameworks/Foundation.framework/Headers/
NSObjCRuntime.h:69: error: parse error before '*' token
Finally the 'make' gives up with:
/System/Library/Frameworks/CoreServices.framework/Frameworks/
OSServices.framework/Headers/OpenTransportProtocol.h:714: error:
conflicting types for `S_OUTPUT'
tables.h:90: error: previous declaration of `S_OUTPUT'
/System/Library/Frameworks/CoreServices.framework/Frameworks/
OSServices.framework/Headers/OpenTransportProtocol.h:723: confused by
earlier errors, bailing out
{standard input}:2435:FATAL:.abort detected. Assembly stopping.
make[1]: *** [term.o] Error 1
make: *** [gnuterm/libgnuterm.a] Error 2
Has anyone succeeded with Term::Gnuplot or any suggestions what to do?
Alan Fry
Problems installing latex2html
I am trying to get 'latex2html' to work on Mac OS X which in turn depends on getting 'netpbm' to work. I apologise if the connection to Perl is a bit tenuous, but the installation of 'latex2htm' depends on a number of Perl scripts. Firstly 'configure.pl' (in the 'latex2html source folder) trips up at line 1268: ($stat,$msg,$err) = get_out_err($pnmcrop -version); where $pnmcrop is the full path to 'pnmcrop' in 'netpbm'. It transpires the reason 'configure.pl' trips up is that 'pnmcrop - version' returns the following message (rather than the version number): dyld: Library not loaded: /libnetpbm.10.dylib Referenced from: /usr/local/netpbm/bin/pnmcrop Reason: image not found Trace/BPT trap Looking at the installation of 'netpbn' the directory /usr/local/ netpbm/lib contains a link 'libnetpbm.10.dylib' to 'libnetpbm. 10.26.dylib', the permissions for which are '-rwxr-xr-x' (FWIW). I would be grateful if anyone can throw any light on this (what image is not found for instance) or suggest what to do next. Again apologies if this is too far away from Perl on Mac OS X. Alan Fry
Re: Terminal (spurious command line) problem
Many thanks to everybody who responded. On 18 Apr 2006, at 18:59, Bill Stephenson wrote: Can anyone suggest where to look for such a file? Look in the Terminal preferences to see if you have a script entered to run when opening a window. The Open a saved .term file… checkbox was unselected and no '.term' files could be found anywhere either, so that didn't seem to be the cause. Similarly Boysenberry Payne wrote: Have you tried looking in ~/.profile? Sorry if that's too obvious... Nope -- there was nothing unusual in '.bash_profile', just some PATH statements. Brian McKee wrote: Start Terminal.app and check under preferences (apple-,) If you don't see it there, quit Terminal, backup and delete ~/Library/Preferences/com.apple.Terminal.plist Betcha that gets it. Yippee! That hit the nail right on the head. In fact it is possible to mouse the 'com.apple.Terminal.plist out of the folder onto the desktop temporarily just to see what happens. MacOS then immediately rewrites a new '.plist'; Terminal opens normally and seems to function normally. However it raises some interesting questions. Sherm Pendley wrote: It's not a great idea to manipulate preference files directly. Their location, filename, format, etc. are considered an implementation detail that's subject to change without notice. Apple has already made at least two changes, from old-style plists to XML-based plists, and then from that to a binary file format. Looking in the '.plist' file with BBEdit, it is indeed a binary file. However Property List Editor shows its content to be a XML dictionary. Clicking the little triangle next to 'Root' reveals the 'Property list'. In this particular case there was an 'Execution String' with a 'value' which was exactly the spurious command line in question. Property List Editor allowed that entry to be selected and deleted. Having done that, and having put the file back into '~/ Library/Preferences', everything seemed to return to 'normal', or at least, what it had been in the past. Interestingly, the XML content of the newly written '.plist' and the original '.plist' had not one single word in common -- they were totally and radically different. But Terminal seems to behave pretty much the same whichever '.plist' is installed in ~/Library/ Preferences. I guess the original '.plist' dates back to OS 10.2.? and now it is OS 10.4.6 and, er, things have changed a bit…It certainly bears out what Sherm says above. Chris Devers added: [/snip/ -- preferences and caches are generally easy safe to rename or remove when trying to diagnose software problems. So, for the moment I have stayed with the original version of the '.plist', edited with Property List Editor and all seems to be well. Again thank you all very much for your prompt help and advice which will no doubt prove very useful to many folk in a similar pickle. Alan Fry
Terminal (spurious command line) problem
A weird problem with Terminal.app has arisen in which a command line (of the form perl file1.plx file2.txt )gets written to the Terminal window each time a new Terminal window is opened (File-New Shell). The problem seems to owe its origins to some experiments with ScriptGUI to see if that app would create a 'droplet' to fulfil the function of the command line above. Somehow a file (?) seems to have got left somewhere (?) in the bowels of system which is 'read' by Terminal each time a new window is opened. ScriptGUI itself has subsequently been deleted. Can anyone suggest where to look for such a file? Where could any 'command string' be kept in the system which would be 'written' to the Terminal window on launch? The machine BTW is a G4 running Tiger 10.4.6. and for what it's worth, both of the files referenced in the spurious command line have been deleted. I would be deeply grateful to anyone for some clues as to where to look or what to do to mitigate the nuisance (and apologise if this is too far off-topic for this list). Alan Fry
Re: Faxing
On 25 Jan 2006, at 10:32, Robert Whittle wrote: Thanks for the detailed and useful info provided. When using the efax approach described, is there any record available anywhere that tells you whether or not the fax was successfully sent or not? Options to retry if the number is busy ? There are return codes from 'efax' which tell you what transpired: 0 The fax was successfully sent or received. 1 The dialed number was busy or the modem device was in use. Try again later. 2 Something failed (e.g. file not found or disk full). Don’t retry. Check the session log for more details. 3 Modem protocol error. The program did not receive the expected response from the modem. The modem may not have been properly initialized, the correct -o options were not used, or a bug report may be in order. Check the session log for more details. 4 The modem is not responding. Operator attention is required. Check that the modem is turned on and connected to the correct port. 5 The program was terminated by a signal. I guess one would have to handle the return codes appropriately in the perl script. This, and much more information on the capabilities of 'efax' are all to be found in the 'man pages': type 'man efax' into the Terminal window. HTH
Re: Faxing
On 23 Jan 2006, at 17:34, Bill Stephenson wrote: On Jan 23, 2006, at 5:09 AM, Alan Fry wrote: I was intrigued by the original question and have done some experiments on this G4 running Mac OS X 10.4.4. snip Wow, thanks for sharing what you've learned! Admittedly, I haven't had much time to play with this since I asked that question but your reply puts me way ahead of where I was then. I'd also like to thank everyone else that replied. If I get my Fax the House script finished I'll post a copy of it. As a PS, [EMAIL PROTECTED] suggested to me [slightly condensed]:- Well, I'd skip the Perl - applescript - Terminal - bash hoopla why not just use system(efax command line) or just back-ticks. Indeed that's much better, faster, and cleaner, and works fine. Many thanks for your kind remarks. I look forward to seeing Fax the House in due course. Alan
Re: Faxing
be of interest to some with my apologies to those not interested in faxing from Perl for his long spiel. Alan Fry On 18 Jan 2006, at 09:10, Robert Whittle wrote: I managed to get perl to send faxes using the 'fax' front-end program, but never satisfactorily. I had to use root user to send faxes and I never managed to send any faxes that has graphics in the. In the end I installed PageSender, which has examples of sending faxes via AppleScript, and I called the AppleScript from perl. I know that sounds a lot more round-about but it had a lot of advantages for me. I could send HTML files, correctly formated, and there is a record kept which you can view in the GUI of all faxes send, or not. If you do get something working, I'd be very interested to know how you got it done Robert Whittle On 18 Jan 2006, at 08:29, Dominic Dunlop wrote: On 2006–01–17, at 20:29, Bill Stephenson wrote: Is there a way to fax a document using the built-in Mac OSX (10.3) fax feature with perl? Well, the command-line program underlying the facility is efax. There's also a simplified front-end program, fax. You could try calling either of those with system() or whatever. Alternatively, CUPS makes the fax modem visible as a printer once it's configured -- run lpinfo -v and you should see it listed. This means that you should be able simply to pipe the stuff you want to fax to lpr. The trick would be to work out what option you need to put on the command line in order to get the number dialled, and acceptable formats for the data. (Text is probably OK. Beyond that, I've no idea.) Not that I've tried either possibility myself. I want to write a script that faxes selected members of congress my humble opinions ;) A laudable aim. -- Dominic Dunlop
Re: Cron Progress Bar in OSX
On Monday, Oct 20, 2003, at 17:03 Europe/London, Chris Nandor wrote:
In article [EMAIL PROTECTED],
[EMAIL PROTECTED] (Thane Norton) wrote:
One of my personal favorites is to use a here document to supply
the code
for an applescript via osascript. i.e.
my $script = 'APPLESCRIPT';
tell application Finder
display dialog Hello World
end tell
APPLESCRIPT
local *script_to;
local *script_from;
local *script_error;
my $pid = open3(*script_to, *script_from, *script_error,
/usr/bin/osascript) or die Couldn't open osascript;
print script_to $script;
close script_to;
A much more efficient method would be to use one of the XS AppleScript
methods, including MacPerl::DoAppleScript() in Mac::Carbon,
applescript() in
Mac::OSA::Simple (requires Mac::Carbon), and RunAppleScript from
Mac::AppleScript.
Also system('open', applescript.app) seems to run a tad faster (?)
than RunAppleScript although it is not AFAIK possible to take Perl
variables into and out of AS that way.
In passing I suspect a minor bug with RunAppleScript: in the example
given the Perl script dies even thought the AppleScript succeeds.
Coming back to the original question in this thread: CronniX is a
very nice application which one would be hard pushed to better.
'CamelBones' looks attractive for the kind of GUI one used to be able
to do so easily with MacPerl. I have not found any documentation apart
from the three How To's on the CB site. Can anyone help?
Alan Fry
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: Cron Progress Bar in OSX
At 9:00 am -0600 13/10/03, James Reynolds wrote: This is one way to do it: on open these_items repeat with this_item in these_items set the_path to POSIX path of this_item set result to do shell script /Users/james/backatcha.pl \ the_path \ display dialog result end repeat end open Yippee! I have got this to work, and now, with a few minor variations have a nice little applet on which you can drop a 'pod' file and get a 'pdf' version in return. I am most grateful for all the very helpful contributions from so many folk in the last day or so. Many thanks, Alan
Re: Cron Progress Bar in OSX
Tue, 14 Oct 2003 08:38:22 +0100 John Delacour wrote: At 12:16 am +0100 14/10/03, Alan Fry wrote: do shell script /Users/alanfry/Desktop/backatcha.pl results in the error: ...backatcha.pl:perl:bad interpreter:Permission denied The script runs fine from the Terminal with the command 'perl' however. What am I missing? You have two choices: do shell script perl quoted form of pathname or, if the permissions are set to executable and the script has the shebang (chmod pathname +x), do shell script ./Users/alanfry/Desktop/backatcha.pl for example /tmp/test.pl reads #!/usr/bin/perl print hello\n do shell script ./tmp/test.pl -- hello Running a 'chmod' fixes the problem and both methods above now work. However I don't seem to need the dot before the path (?) in the case where the file is 'executable'. Many thanks, Alan
Re: Cron Progress Bar in OSX
James Reynolds wrote Thu, 9 Oct 2003 08:38:24 -0600: I have been writing an extremely lightweight Cocoa utility (10 lines of code about) that displays a dialog box with a barber pole and some message. It isn't quite done yet (I don't like the way it looks). It is intended to be launched by a perl script. I would be very interested in giving that a try on a 'test-bed' basis if that appeals to you. Alan
Re: Cron Progress Bar in OSX
Doug McNutt wrote Thu, 9 Oct 2003 05:40:58 -0600: At 10:46 +0100 10/9/03, Alan Fry wrote: I have a MacPerl script I am trying to transfer from OS9 to OSX. There are two problems: cron cron needs to point, with a full path, to an executable, That is, something with the x permission bit set. That can be /usr/bin/perl with arguments pointing to a perl script as text or it can be to the script itself if it begins with a #!/usr/bin/perl line and has been made executable with a chmod. Remember that your .login and other initializations, $PATH in particular, will not be set up for you by cron. cron can open an AppleScript APPL (man open) but if all it is used for is to start up MacPerl you won't need it. Except for GUI things that involve Finder like drag and drop you'll be better off replicating the AppleScript tasks in a shell script. Osascript is available for simple AppleScript-like things from a shell. Many thanks Doug for your comments, which I have carefully filed against the day I shall understand what you're saying. My personal problem is total ignorance of Unix and all its manifold works. I have a learning curve to negotiate, to say the least. At the moment I am merely chipping away like Fred Flintstone at a paleolithic Terminal window, getting nowhere fast. What I miss most is the MacPerl droplet, on which you could drop a file, extract the path (into ARGV) and do something with the file. For instance I have a droplet to decode Base64 -- drop and bingo there is the decoded file. And similarly with more complicated issues like translating a 'pod' file to 'pdf'. Is there anyway one can get back to this functionality in MacOS X? Experiments with AppleScript have not been rewarding. Sure, you can write an applet which will extract the full path name from a file dropped on it. But the path is the old Mac-style colon separated directory path. What can you do with that? Even assuming you could translate the Mac-style path to a Unix-style path (in AppleScript!), how can you pass the path to a Perl script? I have tried telling application Terminal to do a perl script pushing a valid path into @ARGV and then to run a second perl script to see what is in the ARGV list. The answer is always nothing. So I am stuck -- wondering if things might perhaps be more cheerful with WinPerl? Can anybody cheer me up? Alan
Re: Cron Progress Bar in OSX
At 9:00 am -0600 13/10/03, James Reynolds wrote: This is one way to do it: on open these_items repeat with this_item in these_items set the_path to POSIX path of this_item set result to do shell script /Users/james/backatcha.pl \ the_path \ display dialog result end repeat end open Save as an application. And /Users/james/backatcha.pl is: #!/usr/bin/perl print I got: $ARGV[0]; Thank you very much for that suggestion -- it is just the sort of thing I was hoping for. But I have a bug somewhere -- just a simple AS do shell script /Users/alanfry/Desktop/backatcha.pl results in the error: ...backatcha.pl:perl:bad interpreter:Permission denied The script runs fine from the Terminal with the command 'perl' however. What am I missing? Alan
Cron Progress Bar in OSX
I have a MacPerl script I am trying to transfer from OS9 to OSX. There are two problems: cron and a progress bar. Regarding 'cron', the perl script is kicked off by an AS application, so the problem really is how to get the AS application to run at specific times. The second problem is how to replace the MacPerl Progress Bar in OSX perl. I would be grateful for guidance. Alan Fry
