Re: To shell or not to shell
Re: To shell or not to shell
- Subject: Re: To shell or not to shell
- From: Doug McNutt <email@hidden>
- Date: Tue, 23 May 2006 12:37:49 -0600
At 18:31 +0200 5/23/06, Björn Lundin wrote:
>Shell, is that bash? or perl? or tcl? or python? C? Ada? Pascal?
>Or any binary that does not use a GUI?
>
>The definition of shell will easily become fairly broad...
I vote for anything with a shebang line or a true x bit in permissions. Shell is a misnomer in Do Shell Script except that AppleScript always passes requests through a newly formed instance of "sh" which is really bash in the free-UNIX world. It knows nothing about previous calls to a different shell in the same AppleScript and it totally ignores your .profile or .tcshrc settings unless you do special things..
We have a problem of definition here: Just what constitutes an application?
AppleScript came about when were were "desperately seeking 7". Steve was running another company - Next. Applications were all type APPL and had BNDL and FREF resources. OS 7 introduced interprocess communications to allow AAPLs to talk to each other.
AppleScript followed quickly as an interface to those "high level events" for use by users. It managed to obscure the high level events themselves to the point that they were rarely documented by the writers of the applications. That was the job of Script Editor's multilingual interpretation of aevt and other resources in the APPL's resource fork.
With OS neXt we suddenly had two very different kinds of applications. The old APPLs became *.app and were in packages. The new-to-Apple but really much older applications were, as always, identified by a true x bit in the file permissions. They can be executed by passing their name or full path as a command line to a shell.
Finder will not recognize those applications - er tools - on an open or double-click even though one might hope that omission will be repaired one day. The likes of Linux have a "desktop environment" that similarly allow for APPL-like things that are different from UNIX executables. They almost universally need X-11 for communication with a window manager and a graphical toolkit which makes them look more like Apple's APPLs. (Why do I keep typing AAPL?)
But UNIX executables ARE applications. They should not be relegated to some lower status by AppleScript conventions. AppleScript is a method for coordinating the procedures available in divers applications under control of a user. UNIX executables are applications and not some immigrant to be discriminated against.
It's possible to make an executable into a *.app by creating a couple of nested folders and making up content and a plist into which the executable is placed. It's a PITA. A quickie AppleScript application can run the executable with a double click from Finder. It can also pass a file reference to the executable through a drag and drop operation. For common questions on this list, especially text editing and numeric calculation, scripters would be well advised to write in perl, C, python or any of many languages which are made for the purpose. The resulting UNIX executable identified by a #!/usr/... line at the beginning is easily linked to a very short AppleScript APPL to make it work from Finder. Access to "real" applications via high level events uses the UNIX-like osascript tool as required.
What goes away is the continuing problem of namespaces and divers definitions of classes from application to application. And don't even think about saying that reading an AppleScript dictionary is more straightforward than reading a UNIX man page. This list proves that dictionaries are mis-interpreted most of the time. How many scripters think an alias is a line of text with colons instead of slashes? And why do you get an alias when you write "file" in front of a path?
--
Applescript syntax is like English spelling:
Roughly, but not thoroughly, thought through.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Applescript-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden