Re: DropScript confusion about cwd
On Sunday, July 13, 2003, at 03:29 AM, David Ledger wrote: The sooner 'Project Builder' can create perl or shell projects directly the better. What sort of projects? A simple .pl file doesn't really need a project - it's just a single file. You can use PB to edit it, although BBEdit is arguably a much better editor for that. If you're looking for full-scale apps, rather than single .pl files, you should have a look at CamelBones. With it, you can create Cocoa apps in Perl. And yes, it comes with app templates for Project Builder. sherm-- C programmers never die - they're just cast into void. I'd just like to GUIise some of the scripts I use in conjunction with GUI apps. The Project/Interface builder team looks like a solution, but I've only seen a demo and tried the sample prog so far. I'd like to use them to implement something in a language I know rather than have to learn a new language and a new program development technique at the same time. Historically I'm an assembler programmer, now I use ksh, awk and perl. Missed out on most of the stuff in between except for a bit of C and a bit of Modula (I, not II). David -- David Ledger - Freelance Unix Sysadmin in the UK. Chair of SysAdmin SIG of HP/Works technical user group (www.hpworks.org.uk) [EMAIL PROTECTED] (also [EMAIL PROTECTED]) www.ivdcs.co.uk
Re: DropScript confusion about cwd
Le samedi, 12 juil 2003, à 17:25 Europe/Paris, Steven Bach a écrit : But I fully agree with Chris that it is purely a matter of opinion whether Perl is hard compared to AS, and I would add that programming backgrounds, learning styles and other factors are likely to come into play. May I add my opinion ? I've started programming in Fortran IV followed by Basic and then assembly language my learning curve was, by far, much more easier within Perl than AS. Curiously i've found the so called natural language of AS loosing me... being un-natural to me. Yvon
Re: DropScript confusion about cwd
I agree that the semantic distinction is very tenuous. However, I disclaim any ownership or responsibility for it - it's not *my* distinction. It's a marketing distinction, and personally I find it not only a patently false distinction but also an intentionally misleading one - AppleScript is easy, not like those other guys! You'll be up and running and doing really cool things and being super productive with AppleScript in *no time*. That may in fact be true in some cases, but it doesn't mean that you'll be doing any of those things well. If a language is Turing complete, it's a programming language. I have no idea what a 'scripting' language is. -jeff Having been in the industry for a long time, and seen things develop and seen terms come into use, I would describe a scripting language as one where typed-in interactive command lines can be saved in some way as a 'script' to be be run later. This excludes AppleScript from being a scripting language because there is no interactive environment to 'script'. OTOH many people use perl as their command shell on Unix systems. Personally I've never got started with AppleScript - it's just too complicated to bother with. The sooner 'Project Builder' can create perl or shell projects directly the better. David -- David Ledger - Freelance Unix Sysadmin in the UK. Chair of SysAdmin SIG of HP/Works technical user group (www.hpworks.org.uk) [EMAIL PROTECTED] (also [EMAIL PROTECTED]) www.ivdcs.co.uk
Re: DropScript confusion about cwd
On Sunday, July 13, 2003, at 03:29 AM, David Ledger wrote: The sooner 'Project Builder' can create perl or shell projects directly the better. What sort of projects? A simple .pl file doesn't really need a project - it's just a single file. You can use PB to edit it, although BBEdit is arguably a much better editor for that. If you're looking for full-scale apps, rather than single .pl files, you should have a look at CamelBones. With it, you can create Cocoa apps in Perl. And yes, it comes with app templates for Project Builder. sherm-- C programmers never die - they're just cast into void.
Re: DropScript confusion about cwd
On Saturday, July 12, 2003, at 07:30 am, Jeff Lowrey wrote: AppleScript, on the whole, has a shorter learning time FOR A PROGRAMMER to be productive than Perl does. Given that any language will try to provide the functionality that the user culture currently requires of it, all languages have common themes. The implemetations of those themes will differ, so yes if you're familiar with programming concepts you have a leg up as it were. But the questions to ask is do you feel that the time you spend grocking AppleScript as it doggedy stretches the 'like English' anology to the boundries of patience, is time well spent? I don't, and I suspect this reason is precisely why Apple makes sure you have to use it for IPC in Acqua rather than leaving a nice programatic interface. Robin
Re: DropScript confusion about cwd
Well, that's flat-out ridiculous. Perl is HARD compared to Applescript. That is a matter of opinion. Actually, it's NOT a matter of opinion. Many people have differing opinions, but that's not the same thing. It's a matter of marketing, flat out. ... However, AppleScript is a scripting language, and Perl is a programming language - at least by marketing. ... I regard Perl as a scripting language, and generally refer to perl programs as 'scripts.' Many people regard scripting languages as those where a 'script' is text file of a block of code that is interpreted rather than compiled, so your semantic distinction can be tenuous here. I would posit that in general those who do not have any background in programming tend to have an easier time learning AppleScript. Perl (whether a scripting language or a programming language) uses a lot of constructs that are going to be familiar to a programmer who has already used C/C++/Java/ObjC/etc. So in general a programmer will have an easy time with those pieces, even if other bits seem weird. I know a few Lisp/SmallTalk people who also found Perl easy and are bewildered by AppleScript's bizarre syntax. I began learning Perl and AppleScript at the same time, and am quite proficient in Perl, and still sometimes bewildered when using AppleScript which I regard as a dificult language, I still tend to pull out reference books to figure out how to do something, and sometimes just wind up calling 'do shell script' and using Perl/sh/etc to save time. I know there are many folks who love AppleScript and can do things with it that are truly remarkable, and still cannot figure out how to work in Perl. Of all the folks I know in that boat that I know (a huge sample size of three), I have asked what language they first learned, and they all reported that they learned AppleScript before any other language. But I fully agree with Chris that it is purely a matter of opinion whether Perl is hard compared to AS, and I would add that programming backgrounds, learning styles and other factors are likely to come into play. Regards, Steven
Re: DropScript confusion about cwd
At 10:25 AM -0500 7/12/03, Steven Bach wrote: Well, that's flat-out ridiculous. Perl is HARD compared to Applescript. That is a matter of opinion. Actually, it's NOT a matter of opinion. Many people have differing opinions, but that's not the same thing. It's a matter of marketing, flat out. ... However, AppleScript is a scripting language, and Perl is a programming language - at least by marketing. ... I regard Perl as a scripting language, and generally refer to perl programs as 'scripts.' Many people regard scripting languages as those where a 'script' is text file of a block of code that is interpreted rather than compiled, so your semantic distinction can be tenuous here. I agree that the semantic distinction is very tenuous. However, I disclaim any ownership or responsibility for it - it's not *my* distinction. It's a marketing distinction, and personally I find it not only a patently false distinction but also an intentionally misleading one - AppleScript is easy, not like those other guys! You'll be up and running and doing really cool things and being super productive with AppleScript in *no time*. That may in fact be true in some cases, but it doesn't mean that you'll be doing any of those things well. If a language is Turing complete, it's a programming language. I have no idea what a 'scripting' language is. snipped lots of stuff that I agree with and believe support my point But I fully agree with Chris that it is purely a matter of opinion whether Perl is hard compared to AS, and I would add that programming backgrounds, learning styles and other factors are likely to come into play. Yes. But AppleScript is *marketed* as being easier than Perl, or Cocoa, or any other programming language. So the distinction is not a matter of opinion, it's a matter of marketing. -jeff
Re: DropScript confusion about cwd
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chip Howland) wrote: At 1:10 AM +0900 7/11/03, Robin wrote: But if I have to have a double clickable perl script I prefer using the '.command' technique because I really believe Apple should just go ahead and use Perl as the scripting language and put AppleScript to bed along with OS9 Well, that's flat-out ridiculous. Perl is HARD compared to Applescript. That is a matter of opinion. Here's an Applescript tutorial: Open the Script Editor Type display dialog Hello, world. Run the script and here's a Perl tutorial: [snip way too many lines of tutorial, apparently intended to make perl look a lot harder than it is] Here is what, perhaps, you meant: Open BBEdit Type print Hello, world. Run the script HAND. HTH. Now that you've mastered Perl and Applescript, it should be trivial to use either language to create a script that extracts information from a FileMaker database and places it into a QuarkXPress template, then imports images into the document from a remote server, applies the appropriate style sheets to the text, prints the document on a color printer, exports the document as a PDF, saves the text as an HTML file, then opens the HTML file in BBEdit. Yes, quite. A snippet: use Mac::Glue; my $fm = new Mac::Glue 'FileMaker Pro'; $fm-obj(file = $file)-open; # get fields my @fields = $fm-prop(name = fields = database = 1)-get; # get records where second cell isn't empty my @data = $fm-obj(records = whose(NOT = [cell = 2, equals = '']), database = 1 )-get; etc. Or did you intend to mean that manipulating data in AppleScript was hard? If you find this difficult to accomplish in Perl I don't. :-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: DropScript confusion about cwd
At 10:29 AM -0700 7/11/03, Chris Nandor wrote: and here's a Perl tutorial: [snip way too many lines of tutorial, apparently intended to make perl look a lot harder than it is] Here is what, perhaps, you meant: Open BBEdit Type print Hello, world. Run the script Yes, that's one way to run a Perl script, but Apple doesn't bundle BBEdit with OS X. I wasn't trying to make Perl look harder than it is. I was illustrating the baseline of knowledge you need to get started. Now that you've mastered Perl and Applescript, it should be trivial to use either language to create a script that extracts information from a FileMaker database and places it into a QuarkXPress template, then imports images into the document from a remote server, applies the appropriate style sheets to the text, prints the document on a color printer, exports the document as a PDF, saves the text as an HTML file, then opens the HTML file in BBEdit. Yes, quite. A snippet: use Mac::Glue; my $fm = new Mac::Glue 'FileMaker Pro'; $fm-obj(file = $file)-open; # get fields my @fields = $fm-prop(name = fields = database = 1)-get; # get records where second cell isn't empty my @data = $fm-obj(records = whose(NOT = [cell = 2, equals = '']), database = 1 )-get; etc. Or did you intend to mean that manipulating data in AppleScript was hard? If you find this difficult to accomplish in Perl I don't. :-) I think you might be a special case. Not everyone has written Mac::Glue or maintained MacPerl. If you are claiming that you can do everything with Perl and Mac::Glue that you can with Applescript, then I won't dispute you. But don't pretend it's just as easy for a novice. My original point stands: getting rid of Applescript because Robin prefers Perl is a bad idea. I wish I had cross-posted my original reply to MACSCPT so we could have a proper flamewar. -- Chip Howland The Sportsman's Guide
Re: DropScript confusion about cwd
On Friday, July 11, 2003 14:14 -0500 Chip Howland [EMAIL PROTECTED] wrote: I think you might be a special case. Not everyone has written Mac::Glue or maintained MacPerl. If you are claiming that you can do everything with Perl and Mac::Glue that you can with Applescript, then I won't dispute you. But don't pretend it's just as easy for a novice. I too can do everything with Mac::Glue that I can do with Applescript, and I wrote neither of 'em. It matters not that he wrote Mac::Glue. He's published it, so I can use it too. And I have just as much difficulty with using Mac::Glue as I do with using Applescript. That difficulty is solely because Applescript and all its trappings like the events and methods and stuff* that applications expose, and how to call them, is so piss-poorly documented that it may as well not be documented at all. * - so badly documented that I don't even know what the correct terminology is -- David Cantrell
Re: DropScript confusion about cwd
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chip Howland) wrote: At 10:29 AM -0700 7/11/03, Chris Nandor wrote: and here's a Perl tutorial: [snip way too many lines of tutorial, apparently intended to make perl look a lot harder than it is] Here is what, perhaps, you meant: Open BBEdit Type print Hello, world. Run the script Yes, that's one way to run a Perl script, but Apple doesn't bundle BBEdit with OS X. I wasn't trying to make Perl look harder than it is. I was illustrating the baseline of knowledge you need to get started. Oh, come now. Even if you wanted to do the bundled with Mac OS X thing, it could have been as simple as: Open Terminal Type perl -e 'print Hello, world.\n' Hit enter You did not go through how to save scripts in Script Editor, which was part of what you did for the Perl example. You did not discuss differences between compiled scripts, applications, and source text. etc. I think you might be a special case. Not everyone has written Mac::Glue or maintained MacPerl. If you are claiming that you can do everything with Perl and Mac::Glue that you can with Applescript, then I won't dispute you. But don't pretend it's just as easy for a novice. As long as you don't pretend that AppleScript is easy for a novice, I won't pretend that Perl is. I am an expert of sorts, and I find AppleScript very difficult to use. YMMV, of course. I do concede -- for the record! -- that AppleScript is easier to figure out than Mac::Glue, for finding out what works and what doesn't. I even use Script Editor when I am figuring out what to use in Mac::Glue, sometimes, if I get stuck. But AppleScript is MUCH more difficult -- for me -- in pretty much *everything else*. And since once I know how to do something controlling an app in AppleScript, it is pretty simple to convert to Mac::Glue (while the opposite is not true: knowing how to do something handling data or flow control etc. in Perl provides no instruction for AppleScript), it makes a lot of sense to use Mac::Glue, if you know Perl. Yes, there is a learning curve, but what gets me is when people assert that AppleScript is easy for some reason. I just don't see it. And if you already know AppleScript well, the learning curve for Mac::Glue is tiny (mostly a matter of modifying syntax). OK, I admit, I've gone off on a tangent from the original yes Perl can do that onto Mac::Glue r00lZ!, but I just released it for Mac OS X recently and I haven't talked about it much on this list since then. :-) I wish I had cross-posted my original reply to MACSCPT so we could have a proper flamewar. Oh yeah, that's a GREAT idea. ;-) -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: DropScript confusion about cwd
In article [EMAIL PROTECTED], [EMAIL PROTECTED] (David Cantrell) wrote: It matters not that he wrote Mac::Glue. He's published it, so I can use it too. And I have just as much difficulty with using Mac::Glue as I do with using Applescript. That difficulty is solely because Applescript and all its trappings like the events and methods and stuff* that applications expose, and how to call them, is so piss-poorly documented that it may as well not be documented at all. * - so badly documented that I don't even know what the correct terminology is Yeah, the majority of problems I have in Mac::Glue are as you say. The reason I sometimes test in AppleScript is not because it is easier, but because feedback is more immediate when I am trying to figure out why an app is not responding as I think it should. It's really a giant PITA, but it is mostly the fault of the design of Apple events, or the design of a given app, and not something either tool really makes that much easier. Speaking of documentation, something new with Mac OS X's Mac::Glue is gluedoc, a perldoc wrapper: % gluedoc Finder Tells you all the events, classes, etc. for the Finder. Those glue PODs were created for Mac OS version too, but now are more easily accessible. gluedoc -h for more info. -- Chris Nandor [EMAIL PROTECTED]http://pudge.net/ Open Source Development Network[EMAIL PROTECTED] http://osdn.com/
Re: DropScript confusion about cwd
At 10:29 AM -0700 7/11/03, Chris Nandor wrote: In article [EMAIL PROTECTED], [EMAIL PROTECTED] (Chip Howland) wrote: At 1:10 AM +0900 7/11/03, Robin wrote: But if I have to have a double clickable perl script I prefer using the '.command' technique because I really believe Apple should just go ahead and use Perl as the scripting language and put AppleScript to bed along with OS9 Well, that's flat-out ridiculous. Perl is HARD compared to Applescript. That is a matter of opinion. Actually, it's NOT a matter of opinion. Many people have differing opinions, but that's not the same thing. It's a matter of marketing, flat out. AppleScript is Turing complete. Perl is Turing complete. Ergo, anything you can do in one you can do in the other. In either language, I personally find that sometimes I'd rather be programming a Turing machine, but that's different. However, AppleScript is a scripting language, and Perl is a programming language - at least by marketing. You don't have to be a programmer to use a scripting language, whereas *obviously* you have to be a programmer to use a programming language. The fact that you have to be a programmer in order to use a scripting language *well* is elided so as not to confuse the huddled masses. AppleScript fills the same niche that VisualBasic does. As such, until Microsoft does something sensible (I can't believe I just said that) like adopt a standardized language for their own scripting language, AppleScript will be the Apple marketed scripting language for MacOS. All of the faults of the OSA object model and the events and objects that individual applications expose and fail to document are solely the fault of the people developing those applications. Apple has made very big efforts to create standard events and objects that all app developers *should* use. But when the three biggest developers of applications for MacOS are Adobe, Quark, and Microsoft it should be plainly obvious that standard has at least four separate contexts. Perl, on the whole, is faster than AppleScript. AppleScript, on the whole, has a shorter learning time FOR A PROGRAMMER to be productive than Perl does. For a non-programmer, it's about the same. Perl has no mechanism of recording or otherwise auto-generating scripts, at least that is widely publicized without a CPAN search. Oh. Umm. Rant off. -jeff
Re: DropScript confusion about cwd
On Sunday, May 11, 2003, at 7:04 AM, John Delacour wrote: Whatever you can do with DropScript you can do more conveniently with Perl in an AppleScript droplet that _does_ know where it is. On Thursday, July 10, 2003, at 03:37 am, Wilfredo Sánchez wrote: The assumption that your working directory is where your script lives is broken. Conceptually I have to agree with WIlfredo, but also I agree under old MacOS the idea of root was toally nebulous, , so it was necessary to check the PWD to get a path to use in scripts, but that was through the os dealing with paths behind the scenes. But if I have to have a double clickable perl script I prefer using the '.command' technique because I really believe Apple should just go ahead and use Perl as the scripting language and put AppleScript to bed along with OS9 - and this coming from someone who built a multiuser mailing system with AppleScript, osaxen and a copy of Eudora back around OS7. Robin
Re: DropScript confusion about cwd
At 1:10 AM +0900 7/11/03, Robin wrote: But if I have to have a double clickable perl script I prefer using the '.command' technique because I really believe Apple should just go ahead and use Perl as the scripting language and put AppleScript to bed along with OS9 Well, that's flat-out ridiculous. Perl is HARD compared to Applescript. Here's an Applescript tutorial: Open the Script Editor Type display dialog Hello, world. Run the script and here's a Perl tutorial: Open the Terminal Learn how to use ls and cd Learn how to use vi, emacs or pico or use a GUI text editor and make sure you know all about line endings Type #!/usr/bin/perl print Hello, world.; Save the file and exit the editor Learn how to use chmod Learn about permissions Give your file the correct permissions Learn what a PATH is and where to change it Make sure the file is in your PATH Run the script Now that you've mastered Perl and Applescript, it should be trivial to use either language to create a script that extracts information from a FileMaker database and places it into a QuarkXPress template, then imports images into the document from a remote server, applies the appropriate style sheets to the text, prints the document on a color printer, exports the document as a PDF, saves the text as an HTML file, then opens the HTML file in BBEdit. If you find this difficult to accomplish in Perl, feel free to convert the FileMaker database to MySQL and retrain all of your designers to use LaTeX instead of QuarkXPress. Don't forget to rewrite the 100+ workflow automation Applescripts you've already created in Perl. While you're working on that, I'll contact Apple and urge them to get rid of PHP, Python, Ruby, C++ and Java. Perl for OS X: There's Only One Way To Do It!
Re: DropScript confusion about cwd
On Sunday, May 11, 2003, at 7:04 AM, John Delacour wrote: Whatever you can do with DropScript you can do more conveniently with Perl in an AppleScript droplet that _does_ know where it is. The assumption that your working directory is where your script lives is broken. You script's path is argv[0]. The path to files dropped onto the droplet are full paths. That's information you can rely on. Checking CWD doesn't make sense unless you set it yourself. Here's a very simple example of a droplet (save as *Application* from Script Editor) that will create a text file containing a list of the paths of all the files dropped on it as Unicode UTF-8 and open the file in TextEdit displaying the names in Unicode preceded by the posix path of the droplet itself. The problem with that is that now you are writing AppleScript as well as Perl. That's a whole new set of dependancies, and another language to learn/deal with. The point is DropScript is that it's language-agnostic. You can drop a gzip *binary* on DropScript and get a droplet out. Such a droplet has the added advantage that it can be saved as a stay-open application, so that regular tasks can be executed immediately without the boring delay while the applet launches. If you double-click on a DropScript droplet, it stays running. -wsv Wilfredo Sánchez - [EMAIL PROTECTED] iTunes Music Store - Content Acquisition
Re: DropScript recursive processing
Thanks for the help so far guys, I've got a much better picture of what's
going on now!
Does the @ARGV array contain the full paths to the file, or just their names
(ie, do the files HAVE to be in the same directory as the dropscript?)
Cheers,
-Shannon
On 6/9/02 12:51 AM, in article p05200809b99d1b83553c@[158.152.20.126], John
Delacour [EMAIL PROTECTED] wrote:
Suppose you have a perl script test.pl as below saved with UNIX
line endings in your user directory, and in the same directory you
have three text files a.txt, b.txt, c.txt ...
#!/usr/bin/perl
foreach $file (@ARGV){
open FILE, $file;
print FILE;
}
Re: DropScript recursive processing
At 12:05 pm +1000 6/9/02, Shannon Murdoch wrote:
Thanks for the help so far guys, I've got a much better picture of what's
going on now!
Does the ARGV array contain the full paths to the file, or just their names
(ie, do the files HAVE to be in the same directory as the dropscript?)
The full paths. To verify this, make a droplet using this script and
drop a few files on it. A file will open listing the pathnames of
the files.
#!/usr/bin/perl
$report = 'report.txt' ;
open REPORT, $report ;
for (ARGV) {
print REPORT $_\n;
}
`open $report` ; # shell command
This script will do more, but only drop small things...
#!/usr/bin/perl
$report = 'report.txt' ;
open REPORT, $report ;
for () {print REPORT $_\n;}
`open $report` ;
JD
Re: DropScript recursive processing
Hi Pete, Unfortunately I'm not a command-line wiz :(. Could you explain how the target file/directory parameters are usually passed to the script when it IS called from the command line? Cheers, -Shannon On 5/9/02 2:59 AM, in article [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: These are the notes I had on DropScript from April 23, 2002: In the old version of DropScript, it would run the script once for each file dropped on it. Now it takes all of the files dropped on it, and passes the list to DropScript, which is the way MacPerl droplets do it, or the way the command line does it... http://www.mit.edu/people/wsanchez/software/ I'm thinking it should take whatever you drop on it (file or folder) and pass it in just as if you called the script from the command line...
Re: DropScript recursive processing
Well, you might call a script like this: perl foo.pl file1 file2 file3 where each argument to the script (in this case 3 files) is passed in to the script, separated by a space. If I created a DropScript out of my foo.pl, and dropped file1, file2, and file3 onto it, it would be just like typing the command above. Pete On Thu, 05 Sep 2002 20:37:20 +1000, Shannon Murdoch [EMAIL PROTECTED] said: Hi Pete, Unfortunately I'm not a command-line wiz :(. Could you explain how the target file/directory parameters are usually passed to the script when it IS called from the command line? Cheers, -Shannon On 5/9/02 2:59 AM, in article [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: These are the notes I had on DropScript from April 23, 2002: In the old version of DropScript, it would run the script once for each file dropped on it. Now it takes all of the files dropped on it, and passes the list to DropScript, which is the way MacPerl droplets do it, or the way the command line does it... http://www.mit.edu/people/wsanchez/software/ I'm thinking it should take whatever you drop on it (file or folder) and pass it in just as if you called the script from the command line... -- http://fastmail.fm/ - Consolidate POP email and Hotmail in one place
Re: DropScript recursive processing
More to the point, %ARGV -Charles [EMAIL PROTECTED] At 1:42 PM + 9/5/2002, [EMAIL PROTECTED] wrote: Well, you might call a script like this: perl foo.pl file1 file2 file3 where each argument to the script (in this case 3 files) is passed in to the script, separated by a space. If I created a DropScript out of my foo.pl, and dropped file1, file2, and file3 onto it, it would be just like typing the command above. Pete On Thu, 05 Sep 2002 20:37:20 +1000, Shannon Murdoch [EMAIL PROTECTED] said: Hi Pete, Unfortunately I'm not a command-line wiz :(. Could you explain how the target file/directory parameters are usually passed to the script when it IS called from the command line? Cheers, -Shannon On 5/9/02 2:59 AM, in article [EMAIL PROTECTED], [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: These are the notes I had on DropScript from April 23, 2002: In the old version of DropScript, it would run the script once for each file dropped on it. Now it takes all of the files dropped on it, and passes the list to DropScript, which is the way MacPerl droplets do it, or the way the command line does it... http://www.mit.edu/people/wsanchez/software/ I'm thinking it should take whatever you drop on it (file or folder) and pass it in just as if you called the script from the command line... -- http://fastmail.fm/ - Consolidate POP email and Hotmail in one place
Re: Think I know what's up; why I'm not a Finder fan (Re: DropScript)
On Sunday, December 2, 2001, at 08:11 PM, Wilfredo Sanchez wrote:
The potentially surprising event here is that the script is running
twice. I was actually aware of this, but had forgotten. If the Finder
has been written in Cocoa, I think you'd see the script invoked only
once, with multiple arguments. This would almost certainly be the case
if you build and run DropScript on Rhapsody.
What's going on is that the Carbon pasteboard is somehow unclever,
and doesn't accept multiple items or something like that. The upshot
is that Finder sends two open: requests to the drop application and not
one with two file names.
I think this is what's tripping you up. Your test ends up
overwriting the log file on the second invocation, so you only see the
last file name received. If you were to append, I think you'll see
both.
This is actually a big problem... It means that DropShove probably
doesn't work, because it will only archive one file. That sucks.
I don't know where/when this API bigotry started, but I wish it would
stop. Let's make Mac OS X great and stop bickering about whose API is
better than the other guys, or that the a particular problem is the
result of Carbon vs. Cocoa, and instead, let's just fix the problem.
This has nothing to do with Carbon - it has to do with how AppKit
dispatches odocs and how DropScript is written. From the DropScript
source:
- (BOOL) application: (NSApplication*) anApplication
openFile: (NSString* ) aFileName
{
if (myAppIsLaunching) myAppWasLaunchedWithDocument = YES;
[self runScriptWithFiles: [NSArray arrayWithObject: aFileName]];
return YES;
}
So for every file that you get a message for, you run the script. The
end result, that the script is invoked N times, shouldn't be surprising
to anyone.
I've fixed DropScript to do the right thing. I'm not a regular
contributor to Darwin so please tell me who/where to send the patch so
the problem will be fixed for users of the software.
[Although I am subscribed to this list under my company address, I am
speaking for myself and fixed this of my own volition, not that of my
employer, yadda yadda yadda...]
Jim
Re: DropScript
Fred -
Thanks for the help. Now I can see the errors that the script is
generating, but I'm still not sure how to access argv from my perl
script. For example, if I want to assign the contents of argv to
@some_array how do I do that?
Tantalizingly, if i just write:
code
#!/usr/bin/perl -w
use strict;
open LOG, log.txt or die can't open the logfile $!;
foreach my $file (@ARGV) {
print LOG $file\n;
}
/code
then I get (just) one of the files, but this leads me to believe that
I don't need to create my own array. Any help is appreciated.
Thanks!
--Josh
File names are passed via argv[]. I would suggest that you
monitor the console log (run Console.app) while creating the droplet
and see if there are any errors, and if none do the same while
dropping files on the new droplet. Error reporting via the UI is
nonexistant. Perhaps it's failing to set the executable bit on the
script placed in the droplet or something.
-Fred
On Friday, November 30, 2001, at 11:43 AM, Joshua Kaufman wrote:
How are the names of the dropped files passed to the script? For
example, when I make the following script into a 'droplet' it
silently fails to even create the log file. Are the file names not
passed to @ARGV? are there permissions issues?
--
Re: DropScript
At 4:25 PM -0600 12/1/01, Joshua Kaufman wrote:
Thanks for the help. Now I can see the errors that the script is
generating, but I'm still not sure how to access argv from my perl
script. For example, if I want to assign the contents of argv to
@some_array how do I do that?
Tantalizingly, if i just write:
code
#!/usr/bin/perl -w
use strict;
open LOG, log.txt or die can't open the logfile $!;
foreach my $file (@ARGV) {
print LOG $file\n;
}
/code
then I get (just) one of the files, but this leads me to believe
that I don't need to create my own array. Any help is appreciated.
@ARGV _is_ an array, and it can be copied to another array:
@some_array = @ARGV;
Just to check: are you dropping multiple files on the droplet in one
'drop', or are you dropping each file one at a time?
If the latter, study the open() command; as written, each time your
script is called, it writes over what was already there.
Otherwise, what are the errors you see? Maybe there's a hint there.
HTH
1;
--
- Bruce
__bruce_van_allen__santa_cruz_ca__
Re: DropScript
bruce-
thanks for the response. i am dropping multiple files, but only one
is being written to the log file. the problem is that i don't know
how to access the list of arguments that is passed to the shell by
the droplet (or how to pass that directly to perl). $* would work in
a shell script, but i don't know how to get at that from perl.
no errors are generated by the script below when i run it from the droplet.
--josh
At 4:25 PM -0600 12/1/01, Joshua Kaufman wrote:
Thanks for the help. Now I can see the errors that the script is
generating, but I'm still not sure how to access argv from my perl
script. For example, if I want to assign the contents of argv to
@some_array how do I do that?
Tantalizingly, if i just write:
code
#!/usr/bin/perl -w
use strict;
open LOG, log.txt or die can't open the logfile $!;
foreach my $file (@ARGV) {
print LOG $file\n;
}
/code
then I get (just) one of the files, but this leads me to believe
that I don't need to create my own array. Any help is appreciated.
@ARGV _is_ an array, and it can be copied to another array:
@some_array = @ARGV;
Just to check: are you dropping multiple files on the droplet in one
'drop', or are you dropping each file one at a time?
If the latter, study the open() command; as written, each time your
script is called, it writes over what was already there.
Otherwise, what are the errors you see? Maybe there's a hint there.
HTH
1;
--
- Bruce
__bruce_van_allen__santa_cruz_ca__
--
Re: DropScript
At 1:43 PM -0600 11/30/01, Joshua Kaufman wrote:
I'm interested in using Wilfredo Sanchez's DropScript to make some
of my perl scripts available to users who prefer not to use the
command line.
How are the names of the dropped files passed to the script? For
example, when I make the following script into a 'droplet' it
silently fails to even create the log file. Are the file names not
passed to @ARGV? are there permissions issues?
Not having tried it, but I suspect that DropScript calls a shell
directly, passing the shell-style $1..$9 arguments. So you might
want to use something like:
exec perl -S $0 $@'
as the first line of the script.
(Or maybe I'm completely wrong.)
--Sandy
script
#!/usr/bin/perl -w
use strict;
open LOG, log.txt or die can't open the logfile $!;
for (@ARGV) {
print LOG $_\n;}
/script
--
Re: DropScript
What happens if you try to make a droplet out of the simple script:
/bin/sh -c /usr/bin/perl -e '$cmd = `touch foo`'
will foo get created then?
-s-
At 2:51 PM -0600 11/30/01, Joshua Kaufman wrote:
Thanks for the reply Sandor, but further investigation reveals that
the following also fails to create the file 'foo' as expected when
made into a droplet:
script
#!/usr/bin/perl -w
use strict;
my $cmd = `touch foo`;
/script
so, putting the problem of passing arguments to the script aside for
the moment, it seems that the perl script is not being executed. The
two shell scripts that were provided with dropscript as examples
(shove.sh and unshove.sh) worked fine when I made them into
droplets. Does anyone know what my error is?
Thanks;
-Josh
At 12:19 PM -0800 11/30/01, Sandor W. Sklar wrote:
At 1:43 PM -0600 11/30/01, Joshua Kaufman wrote:
I'm interested in using Wilfredo Sanchez's DropScript to make some
of my perl scripts available to users who prefer not to use the
command line.
How are the names of the dropped files passed to the script? For
example, when I make the following script into a 'droplet' it
silently fails to even create the log file. Are the file names
not passed to @ARGV? are there permissions issues?
Not having tried it, but I suspect that DropScript calls a shell
directly, passing the shell-style $1..$9 arguments. So you might
want to use something like:
exec perl -S $0 $@'
... as the first line of the script.
(Or maybe I'm completely wrong.)
--Sandy
script
#!/usr/bin/perl -w
use strict;
open LOG, log.txt or die can't open the logfile $!;
for (@ARGV) {
print LOG $_\n;}
/script
--
--
Re: DropScript
On Friday, November 30, 2001, at 12:51 PM, Joshua Kaufman wrote: Thanks for the reply Sandor, but further investigation reveals that the following also fails to create the file 'foo' as expected when made into a droplet: script #!/usr/bin/perl -w use strict; my $cmd = `touch foo`; /script so, putting the problem of passing arguments to the script aside for the moment, it seems that the perl script is not being executed. The two shell scripts that were provided with dropscript as examples (shove.sh and unshove.sh) worked fine when I made them into droplets. Does anyone know what my error is? I think Wilfredo is on this list, so he's the expert. But in my own tests, and looking at the source code, it seems that if you drag one or more files onto the droplet, the droplet will run the script with the files as arguments, and then quit. If you just double-click on the droplet, it will launch, and just wait for the user to select the Open menu item, and then run the script on that selected file. -- Edward Moy Apple Computer, Inc. [EMAIL PROTECTED] (This message is from me as a reader of this list, and not a statement from Apple.)
Re: DropScript
File names are passed via argv[]. I would suggest that you monitor the console log (run Console.app) while creating the droplet and see if there are any errors, and if none do the same while dropping files on the new droplet. Error reporting via the UI is nonexistant. Perhaps it's failing to set the executable bit on the script placed in the droplet or something. -Fred On Friday, November 30, 2001, at 11:43 AM, Joshua Kaufman wrote: How are the names of the dropped files passed to the script? For example, when I make the following script into a 'droplet' it silently fails to even create the log file. Are the file names not passed to @ARGV? are there permissions issues?
Re: DropScript
Oh, I wrote an article on DropScript for MacTech, which you might find useful, if not more than you need to know. August 2001. My copy of it is at: http://www.mit.edu/people/wsanchez/papers/DropScript/ -Fred
