Shell Programming and Scripting

The second backtick is there in every instance (just after -f7). Perhaps you're looking ahead at the final argument within [.

Regards,
Alister

My sincere apologies alister. The sloping quotes are indeed matched.

Until we know what O/S and Shell we have this is going to be guesswork.
As it doesn't like "==" we are probably on a mainstream unix.

I have concerns about an unquoted "?" in any Shell.

I'd prefer "ps -fuibiaud" to "ps -ef" piped to "grep ibiaud".


Unless you have a system which will not shut down, or a totally rogue process arising from bad code, there is NEVER a reason to issue "kill -9" to a commercial application. There is often reason to issue "kill -15".

Code:

ls -lad killscrp.sh shows:
-rwxrwxrwx   1 brsas2   other        148 Apr  1 15:49 killscrp.sh

Code:

cat killscrp.sh shows:
# set -x
if [ "$(ps -ef  | grep  "ibiaud" | grep -v grep | tr -s " " | cut -d " " -f7)" =  "?" ]; then
        echo "not running"
else
        echo "running"
fi

Code:

uname -a shows:
SunOS xyxprod 5.9 Generic_118558-06 sun4u sparc SUNW,Sun-Fire-V440

Code:

echo $SHELL shows:
/bin/sh

Code:

# ./killscrip.sh shows:
./killscrp.sh: test: unknown operator  | cut -d

@shanonadams68
I think we hit the solution earlier, except for the "==". Did you try the following?

Code:

if [ "`ps -ef  | grep  'ibiaud' | grep -v grep | tr -s ' ' | cut -d ' ' -f7`" = "?" ]; then

or

Code:

if [ "`ps -ef  | grep  \"ibiaud\" | grep -v grep | tr -s \" \" | cut -d \" \" -f7`" =  "?" ]; then

@methyl
It happens. No worries
This old shell appears to not support the $() syntax, and seems to process double quotes within a double-quoted backtick command substitution before executing it (like ksh). If I'm mistaken and these suggestions don't work, hopefully you can knock it out of the park.

Regards,
Alister

I don't think this is the source of the problem, but there is something i noticed:

Code:

cut -d " " -f7

as far as the documentation on my system (AIX 5.3) goes the delimiter is expected immediately after the "-d", not separated from that by a blank. The command should IMHO read:

Code:

cut -d' ' -f7

regardless of using double or single quotes, which shouldn't make no difference here.

I hope this helps.

bakunin

Nah. It has nothing to do with cut's option processing. If that were the case, there would be an error message from cut containing "cut: ".

I can replicate the issue on ksh, since it exhibits the same behavior when using obsolete backtick command substitution within a double-quoted string (it doesn't behave that way with the non-obsolete $() syntax, or if the command substitution is not double-qutoed).

The issue is that that this shell processes double quoted strings before invoking the command substitution, so a double-quote within the command substition must be escaped, otherwise it terminates the double-quoted string. Surprisingly (at least, to me), is that the end of a token terminates an open backtick command substitution that began within a double-quoted string. A matching backtick later on in the command line is not looked for; instead, when found, it will trigger another instance of command substitution.

When parsing the following command ...

Code:

[ "`ps -ef  | grep  "ibiaud" | grep -v grep | tr -s " " | cut -d " " -f7`" =  "?" ]

... the shell generates 5 tokens in parsing ['s arguments:

Code:

1: "`ps -ef  | grep  ibiaud | grep -v grep | tr -s "
2: " | cut -d "
3: " -f7`"
4: "="
5: "?"

1: Even though this token does not contain a closing backquote, its end delimits the command substitution; tr is the final command in the pipeline (note that cut is not part of it).

2: This token is the second argument to [ and generates the "./killscrp.sh: test: unknown operator | cut -d " error message, because obviously [ doesn't know what to do with it.

3: A short string which ends in what was intended to be the matching backtick to the backtick in token 1. This backtick begins another command substitution which is immediately terminated since it occurs at the end of the token, and it began within double-quotes. This attempt to execute a null command line is the source of the "./killscrp.sh: : execute permission denied" error message.

4 and 5: Two more strings passed as arguments to [

Here's a trace (only change I made was dropping the ps options which are incorrect on test system):

Code:

$ ksh --version
  version         sh (AT&T Labs Research) 1993-12-28 p
$ set -x
$ [ "`ps  | grep  "ibiaud" | grep -v grep | tr -s " " | cut -d " " -f7`" =  "?" ]
+ ps
+ grep ibiaud
+ tr -s ''
+ grep -v grep
+ ''
ksh: : cannot execute [Is a directory]
+ [ '' ' | cut -d ' ' -f7' = '?' ]
ksh: [:  | cut -d : unknown operator

I learned a bit about how `` command substitution within a double-quoted string works, and, I must say, I'm very grateful to have $() available on every shell that I use .

Cheers,
Alister