Applescript and Unix commands (check if process exists)
 

Ok, I'm totally green at this and I've been at it for hours. This is all I have to show for it:

It seems that "tell application "System Events" to get name of every process" does not return 'server-bin' even though it shows up in Activity Monitor or using top. Other than that, the script works and runs 'do script with command... ' every minute because System Events does not return true to server-bin.

Is there another way to make this work? Either through AppleScript or adding to it and using terminal commands?

Any help would be greatly appreciated.

You might do better with "if exists process" as in post #10 of this other thread:
http://forums.macosxhints.com/showthread.php?t=27113

You seem to be trying to restart a process that might have crashed. If so, see this other thread with an example of how to do this in a shell script (running in Terminal):
http://forums.macosxhints.com/showthread.php?t=24044

Unfortunately the 'if exist process' still uses System Events which does not see 'server-bin' running

I looked at the suggested examples and came up with this:
Which returns this : tcsh: if: Expression Syntax. And of course everyminute it opens a new terminal window. Can I run a script like this on one line? Can I make it use the same window again?

I would really like to use Applescript because I can save the script as a Stay open application. Is there no way applescript can check all running system processes?

Sorry if this looks totally newb, but I have no idea how to implement scripts with Terminal.

1) You might want to read some Unix tutorials, e.g. the one here:
http://www.osxfaq.com/Tutorials/LearningCenter/

2) Don't bother with trying to run a complicated command line from AppleScript. Instead, make those commands into a shell script and then run the script from AppleScript. See #1 above on making shell scripts.

3) To pursue your original tack of using System Events to list the processes, you should figure out why it isn't finding the process you named. To do this, I would start by just doing some AppleScript to show you all the names of the processes. Probably you will see that the process you are looking for has some different name than what you think.

Hayne, usually The processes I look for are applications, I notice that atFault is not, and thought that maybe it was a case sensitive spelling problem.
So tested the script. on a process called pmTool, but typing it pmtool.

The script did not find it as I expected. But when I corrected the t to T it still did not find it.

The script work as expected when looking for an app name like Safari.

So I then used a applescript with a do shell script "ps -ax | grep -e pmtool" to check for pmtool and then I tried pmTool. that script found both. with and without the -i option.

Yes - I think you are right. I did a few experiments running the simple AppleScript:
by using 'osascript' in a command in a Terminal window. This prints out the results as a comma-spearated list.
Only the programs that gave some GUI component show up in the results.
I think it might only be reporting on the apps that make a connection to the WindowServer process.

atFault:
It looks like you will need to use a solution based on 'ps' in a shell script.

Ok, I've been trying other stuff and am here:

I know this part works properly because if I have just that in a script it works.
So it must be something with
I still get a Type 1 on error from the script. I have no idea how exact the "if cmdOutput contains "server-bin"" results must be to the actual output from the "ps ax | grep server-bin | grep -v grep" shell script. I hope it can be generalized because the process ID is different everytime it runs "server-bin". Is there a way to filter the result any more? Is "ps ax | grep server-bin | grep -v grep" the right thing to be using? Applescript is new, but Unix is completely foreign.

Again, any help would be greatly appreciated.

Take out the second grep pipe ( | grep -v grep" ), with the second pipe you are saying invert the result ( select non-matching lines ) so there is no match.

The second grep is necessary to filter out the process corresponding to the first grep.

atFault:
The way to figure out what is happening (what is going wrong) is to proceed step by step. Don't try to get your 'if' statement working. Just run an AppleScript (in Script Editor) that has the line
do shell script "ps ax | grep server-bin | grep -v grep"
and look at what the result is (shown in one of Script Editor's windows).
Then you will see what that script is returning and hence why the 'if' statement isn't working.

But really you are making things much harder on yourself by continuing to debug this from AppleScript. When you are dealing with a shell script, it really is essential to get it working first in Terminal, and only then, once you have it working and understand its output, wrap it up inside AppleScript. You are being hampered by the AppleScript wrapper.
I.e. I think you need to go and read that Unix tutorial I suggested. Then try out the commands in Terminal, etc. Step by step.

I have been doing things line by line and trying the shell commands in the terminal. It all seems right, but the problem seems to be that while returns it seems that is not the right line to make sense of the result to continue running if/then/else situation.

Hayne can you explain how grep -v does this filter?

I obviously did not understand the man page and miss reading the script.

so the ps ax | - looks at the process an pipes it to

grep "server-bin" | - which looks for server-bin and pipes that to

grep -v grep"

which does what? if you mean it looks for grep in the result of
grep "server-bin"

then does not the -v tell the last grep to ignore all lines with grep

??

This sort of thing works for me.
Maybe the problem is with the action you are taking inside the 'if' statement. Instead of doing some action like in your first example script,
just set a variable.
E.g. something like:
That will print out the value of the variable 'foo'
As I said, when I do this sort of thing, it works.

Exactly.
Just run the command without the second grep (and do the search for a process that you know is running - e.g. run a 'sleep 100' in another Terminal window):

ps ax | grep sleep

Then you will understand.

This kind of works. If server-bin is running foo returns "found it". If it isn't I get "An error of type 1 occured". It really seems to be the "if cmdOutput contains "server-bin" then" line. Everything else works, but why would that line give an error if the the result of "set cmdOutput to do shell script "ps ax | grep server-bin | grep -v grep"" is null?

If i put "ps ax | grep server-bin | grep -v grep" into terminal while 'server-bin' is not running I get nothing returned. Of course that makes sense because there is nothing to return and "grep -v grep" is ignoring the "grep server-bin".

The same thing happens with

"An error of type 1 occured" if Safari is not running. Is there a way to cause an output of somekind depending on the result in order to avoid a null output?

I really appreciate the the help you guys are giving me. Hopefully I will be able to sleep tonight and not thing about conditions :rolleyes:

Okay, I see the same problem - if the shell script doesn't print any text, then you get an error in AppleScript.

You could add error handling in your AppleScript ('try' & 'on error' - search these forums for examples) but it seems to me that would be a kludge.
The correct thing to do would be to write a shell script (based on your 'ps' & 'grep' command) that printed either "running" or "not running". Then you could use that shell script in the AppleScript.

I supplied such a shell script in the thread I referred to above:
http://forums.macosxhints.com/showthread.php?t=24044

Ah, I see, you get

535 std R+ 0:00.00 grep sleep
533 p2 S+ 0:00.02 sleep 100

on my first tests with pmtool, I was only getting the one line which had grep in. So again its dependent on the type of process.

Sorry if I'm beating a dead horse, but no, it doesn't depend on the type of process. If you only get the one line with the grep, that means that the process you were grep'ing for does not exist. (In your first try, you told us that you had misspelled the name of the process)

Its not your horse that needs flogging, I think it must be me,

But what I mean by my first test, was actually the one I did with

ps ax | grep server-bin | grep -v grep"

I do not have the server-bin so I used pmTool again in terminal.

ps ax | grep pmtool | grep -v grep

and | open -f

to see the result.

which returned nothing.

but

ps ax | grep pmTool | open -f

returned only the one line.

560 std R+ 0:00.00 grep pmtool

and I got the same regardless if its 't' or 'T'


This is why I did not get the use of the filter because I was only getting one line.

So I now know why you needed to use the filter for grep,
but whats throwing me is the inconsistent results compared to what you are getting.

( the pmTool is running but I am only getting one line )

1) I don't know why you are using 'open -f' to see the results. The results will appear in the Terminal window if you just do:
ps ax | grep pmTool

2) If the process doesn't show up, you need to check that it is appearing in the output from 'ps ax'. I.e. just run the command:
ps ax
and look at the output to see if you see the line with pmTool
Maybe the problem is that the output from 'ps ax' is truncated at 80 characters. Try 'ps axww' to get the untruncated output.

Yer that was the problem.
I now get

402 ?? Ss 17:33.68 /Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool
672 std R+ 0:00.00 grep pmTool

so now when I do
ps axww | grep pmTool | grep -v grep

I get

402 ?? Ss 17:41.83 /Applications/Utilities/Activity Monitor.app/Contents/Resources/pmTool

Which means I am getting what I should be.

I understand now the grep -v grep .
And I will remember about that truncation. ( I hope )
EDIT**
And should have read your link
Thanks and Thanks for your patience.

Now to recapture my hijacked thread and post my solution.

I took the "grep -v grep" off of the set "cmdOutput to do shell script "ps ax | grep server-bin"" line so that I would get both the grep of the grep and the grep of the server-bin thereby eliminating the NULL condition.

I then modified 'if cmdOutput does not contain "sfcsar" then" to query for a different, but unique return from the "ps ax | grep server-bin" that would not be present if "server-bin" wasn't running. It turns out the NULL condition was the cause of my 'A type 1 error occured" message and this solved the problem.

My final script is this:
So I figured it out on my own, but there is no way I would have put it all together without you guys, thanks for the pointers and info. It even sounds like the hijackers got something from my little problem. I don't know how 'clean' my script is or how appropriate it is to make it work like this, but it does work and is making many people happy.

Ciao, and thanks again

atFault

Just a helpfull pointer...

ps -axc to take out the path name of the application

for example:

See the difference... type man ps to find more ps fun :)

Thought I would dust this thread off and post my solution in case it is helpful to anyone else.

The wc command will return 0 if it is not running. And in my case, I want to allow more than one instance running of comskip.exe under wine, so this serves two purposes. It tells me if it is running, and how many instances.

B

As jkenney pointed out (though perhaps not emphatically enough),
using the 'c' option with ps not only trims off the pathname... but,
ALSO totally obviates the need for the extra |grep -v grep !

If someone can explain *why* that actually works, I'm all ears.
[seems like grep should still find the same string it did before?]

--

Another trick -- which works without the 'c' option -- is to prefix a [/]
bracket expression onto the searched name. So grep must then match
a leading / forward slash, right before the string. Thus -- for example,
to see if Safari is running -- this will do the trick:

Code:

---

if [[ $(ps ax |grep [/]Safari) ]]
then
        # Safari is running...

else
        # Safari NOT running...

fi

---

§

I will also briefly mention that that final pipe into "|cut -d ' ' -f8" is pretty much not needed.
Yes... wc does stick a bunch of spaces in there, for some odd reason.
But the shell sees spaces as nothing but separation: IFS=$' /t/n'
So... it can still do math, and "if" comparisons, etc., just fine.
For most purposes, simply don't quote the (integer) variable... and the spaces go away!
E.g.:

if [ $isRunningComskip -gt 0 ]
or
(( $isRunningComskip+=1 ))
or
echo $isRunningComskip

all work fine. (the spaces are simply ignored/discarded)

-HI-

Here's an example that should lead you to the path of understanding:

Ahh, thanks for that tip on cut. I may give that a whirl, although I wrapped my package already. For the record I had to use When using c, it captured I was running bash, but not the name of the bash script.

B

Not really. In fact... that makes it more mysterious. :D
[i can see it does work... but not how/why it works.]

Try this:
$ ps -ax | grep Safari
88880 ?? 0:39.45 /Applications/Safari.app/Contents/MacOS/Safari -psn_0_454767
94274 ttys000 0:00.00 grep Safari

$ ps -acx | grep Safari
88880 ?? 0:39.45 Safari

Now... why doesn't the 2nd grep *also* see itself (grepping Safari)?
The text being matched is simply "Safari"... so, i don't get it.

Perhaps I should have emphasized that those behaviors apply to Bash, and not AppleScript.

However, most of the examples in this thread seem to use AppleScript only to
either talk to the shell (do shell script) or Terminal (tell application "Terminal").
So --unless there's some use for it [not shown] -- a shell script should suffice.

But yes, to have AppleScript display that number as text, we'd need to strip
the spaces (if we cared about it looking perfect). I much prefer sed over cut:

Look again at the 'grep grep' example I showed above.
The output from the 'ps -axc' case shows that the line in the output from the 'ps' command with those options is simply "19541 ttys000 0:00.00 grep"
- there is no "grep grep" in the 'ps' output.

Similarly when you 'grep Safari', there is no "Safari" in the line from 'ps' for that process since the "-c" option does not include the command's arguments in the output.

Or here's another way to understand:
Run a shell script that loops, running a command like 'grep foo /etc/passwd'
and then look at the full output from 'ps -xc' with something like:
ps -axc | more

No arguments!
*NOW* I get it.

[duh :o ]

Thanks C.H.

I had a friend explain sed to me the other day. It is much cleaner and doesn't suffer from the limitation I found in cut. If the # of processes is 10 or higher, the field changes to 7 from 8.

B