Thank a lot
 

Your recommendations are very useful. Well, finding out existence of this script is a workaround to find out if app runs.
Firstly, I wrote a shell script where called osascript $COMMAND (where $COMMAND is apple script command). But this shell script is running from some app and performed under root (I can't change this).
And on Leopard (and maybe on Tiger) osascript is not performed under root.
So I tried to call from shell script "osasscript myscript.scpt".
Seems that in this case myscript.scpt is not performed under root.
But I need to know if app (for example "Address Book" is not running).
For some reasons some commands "do shell script " (like sed -n '$=' file_name) in myscript.scpt does not work on Leopard either. It does not mean that they don't work if I run it right from Terminal, but only when I run it from my app. So I'm trying to find some other ways to solve my problem.
Maybe it would be easier to get out if app is not active? But I'm newcomer about apple script, and need to solve this problem as quickly as can.

Why go by feeling when you can test it? Performance can always be analyzed; don't make implementation decisions based on assumptions of performance. ;)

I also prefer -f because it's more explicit. You want to know if a file exists, and there is a reasonably fast way of doing it explicitly. No reason to spawn two processes instead of one, when one is the explicit version that is already fast.

For what it's worth, if you use ls and the file doesn't exist, ls exits non-zero, which causes "do shell script" to throw an error that has to be caught with try/on error anyway. You don't really save any code.

You should've told us your actual goal in your very first post, because the answer is completely different. I have to run out for the afternoon, so I can't address it, but I imagine someone will come along shortly and do so.

I had thought that would be the case, but I was working on my wife's computer, which is running 10.3.9, and it worked as I have it listed, whether or not the file existed. Trying the same code on my machine running Tiger does throw an error, so I guess the point is moot.

There may be a better way, but this shell script works for me:
If the result is 1, it isn't running. If it's 2, it is.

I would recommend that the ps part be:
this makes you see other users processes which you otherwise would miss.
Also only outputs the command name so it has to do less digging in kernel data.
and the grep part:
If you do it like this you avoid catching the grep process and the answer from
will be zero when not running
otherwise it's the number of processes for that name

See the various solutions suggested (for determining if a particular app is running) on DaringFireball.net: http://daringfireball.net/2006/10/processing_processes

See also the two versions of the app_running script on my Bash scripts page: http://hayne.net/MacDev/Bash/

Whether or not you need to do this depends entirely on why you need to know if an app is running in the first place.

I did in such way:
tell application "Address Book"
set itRuns to it is running
if not (itRuns) then
activate
end if
-- add some addresses
if not (itRuns) then
quit
end if
end tell
And so with other apps. Main problem was to run these scripts from specific app that runs them under root. Now it's over.
Thanks to all.

What are you doing with GUI apps running as root? This is a bad idea.

I agree - it is a very bad idea to run GUI apps as 'root'. Anything that requires 'root' privileges should be done by a small command-line tool that is invoked as needed by the GUI app.

This app is our installer that runs some tasks. And if some of them have to be performed under root (installing widgets), it performs all tasks under root.
This is bug that nobody will fix in near future, and we have to do workarounds.

Tell us what your product is called so we can recommend against installing it.
:)

You should be using a GUI-less helper tool to install your software. Have you read any of the (extensive) installer and security documentation from Apple?

It sounds like you aren't using a standard installer package, either. Why not?

What, exactly, are you calling a bug? The fact that you shouldn't be running a GUI app as root? That you can't gain elevated privileges for your GUI app after it launches under a lower-privilege user?

Agreed with Hayne.

I have no idea about this. We don't use PackageMaker. This is our internal product, although we released lots of installers created with it.
I mean bug in installer is that when one of the tasks requires higher permissions, all of the tasks are performed with these highest permissions.

Yet, you're working on the installer? You still haven't explained why you don't use Apple's standard installer system. It's very rare that anyone should need to roll his or her own installer. (And it requires good knowledge of what and what not to do. I've had to custom-roll them before, and it's really something you want to avoid unless you have no choice.)

Does not compute. Please explain what you mean.

This is request of our director to use our installer instead of Apple's installer.
As my native language is not English, it's a bit difficult task.
For example, installer has to perform such tasks: install app into /Applications, widget into /Library/Widgets, importer into /Library/Spotlight, music into ~/Music etc. and do some additional tasks: add installed music to iTunes.
Installing widget requires authorization even if it runs under admin. And then all tasks are performed under root.
But actually I just found that there is option in installer for each task to specify which permissions it requires. And if set to perform with lowest permissions it works fine.
So it will be a good lesson for me.
Anyway I will remember to not using Finder in apple scripts if possible and to use POSIX file.

It wasn't a language problem, it was a verbosity problem. The extended explanation you gave this time is clear and informative, whereas what you said before wasn't. :)

It's only doing that because you're running the GUI app as root. If you use a helper tool that performs the copying, and just invoke that tool as root, you can leave the GUI running under the normal user account and do only what you need as root.

It sounds like whoever wrote your installer system may have taken care of the "don't run GUI as root" problem, but without knowing more about this installer program, I couldn't confirm or disconfirm that.

To be candid, your director should understand that Apple's already written a great installer system that his company doesn't have to maintain, and that users are comfortable with because it's standard and easy to use. And it's probably better than what he had his people build. We're also generally more trusting of Apple's installer system, because it avoids problems like the one we're talking about.