Re: osascript and *.command files
Re: osascript and *.command files
- Subject: Re: osascript and *.command files
- From: Axel Luttgens <email@hidden>
- Date: Wed, 10 Oct 2007 13:20:28 +0200
On 7/10/07 18:25, Thomas Treichl wrote:
Axel Luttgens schrieb:
[...]
What happens if you run the .command file directly, e.g. by typing:
~/Desktop/other.command
Sure that works.
After all, the .command file is just a regular shell script, and
Terminal.app is already opened.
It seems to be not, because shell scripts can be called without any
problem. I expect the problem is somewhere in the osascript part of
the example file but I don't know for sure.
Strictly speaking, it _is_ a regular shell script; the fact that its
name ends with .command doesn't mean that it _must_ be run with the help
of the "open" shell tool.
And by running it directly, it seems one avoids some problematic
interactions between double-clicking the .command file (or applying
"open" to it) and the fact that it interacts with Terminal.app through
Apple Events.
But I'm not sure to have correctly understood your question.
Axel
My example code from above is just a small part of a startup script
that I use for the startup of a special application. A user reported
that if he uses this startup procedure then he can't open any other
*.command files anymore that should do some Terminal.app output by
double-clicking the icon (in Finder or on Desktop).
Another example so that you can reproduce my problem:
Create the file example.command with the code from above.
Double-click it the first time and see two windows will be opened.
Double-click it a second time and see that nothing happens anymore
(but actually I would expect that another 'ls' is done?!).
I still don't have a clear view of the way you need to organize your
workflow, so forgive me if I'm just erring...
But perhaps could you reverse the logics.
Let's start with your the core of your example:
tell application "Terminal"
activate
do script "ls"
end tell
and save it now as an applet, say ~/Desktop/test.app.
It may even be somewhat enhanced, so as to avoid all those windows:
tell application "Terminal"
launch
activate
if (count of windows) > 0 then
do script "ls" in window 1
else
do script "ls"
end if
end tell
Each double-click on its icon will execute "ls" in Terminal.app's front
window.
The same way, it may be invoked as often as needed from a shell script
or from the command line with:
open ~/Desktop/test.app
So, your users may now have a "double-clickable solution".
But this still doesn't solve the problem related to .command files: even
with the above arrangement, they won't have any effect anymore when
double-clicked.
In fact, the problem seems to be with Terminal.app itself wrt Apple
Events, not with osascript nor the Finder nor LaunchServices etc.
As a "proof", save this script
#!/bin/sh
ls
as ~/Desktop/test1.command.
Assuming Terminal.app is not running, a double-click on test1.command
will launch Terminal.app as expected; each subsequent double-click will
be functional too.
Now, in Script Editor, just execute:
tell application "Terminal" to get properties
Poof! Double-clicking on test1.command doesn't have any effect any more...
HTH,
Axel
_______________________________________________
Do not post admin requests to the list. They will be ignored.
AppleScript-Users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
Archives: http://lists.apple.com/archives/applescript-users
This email sent to email@hidden