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