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