Help with if-then-else bash script

Hi,

Following from other thread posted in this forum.

I'm trying to make a simple bash script to check for "php" process. If the spesific PHP script process (eg: cleanlog.php) does not run, it will then be executed from bash.

#!/bin/bash
var1=`ps -ef | grep -v grep | grep cleanlog| awk '{print $2}'`
echo $var1
if [ -n "$var1" ]
then
echo "Process running"
else
/usr/bin/php -q cleanlog.php
fi

When I tried to execute the bash script, it throws error:

line 9: syntax error near unexpected token `fi' line 9: `fi'

What is wrong with the above code, please help.

Thank you.

Hey,

I think, There is nothing wrong with the script,

May I know you system/OS..?

If you are created the shell script file in windows and transfer the file into *nix server for execution will hurt.

Any ways try,

dos2unix filename

Cheers,
Ranga:)

That could play a role if the script is not executed by using ./script , but for example sh script , otherwise the attempted use of the shell specified by the shebang would immediately throw an error on line 1... The script looks syntactically correct.

@rangarasan.
Sorry to not mention.

Yes, when I run that script above on Centos shell, it works fine.

But, when I tried to edit that script using notepad on Win32 and then upload it to Ubuntu server via webshell, it could not run.

I have using that command suggested "dos2unix [filename]", but it seems there's no dos2unix command. FYI, I'm not root user.

dos2unix: not found

So, I guess it might be an issue related with script editing on the webshell.

Could you post the output of cat -A bashscript.sh
Looks like the classic CR-LF problem. Try sed 's/<ctrl+v+m>$/\n/' bashscript.sh

tr -d '\r' < script > script.new

Hey,

The issue is, When you are editing the script in windows environment, It will put '\r' at the end with '\n' but *nix will not recognize these things.

Try this below,

tr -d '\r' script_name.sh >new_script_name.sh
./new_script_name.sh

That will do the trick for you.

Cheers,
Ranga:)

execute the below command

perl -pi -e 's/\r\n/\n/g' scriptname.sh

then try to run your command.

@ balajesuri
This is the cat -A mytest.sh:

#!/bin/bash^M$
var1=`ps -ef | grep -v grep | grep cleanlog| awk '{print $2}'`^M$
echo $var1^M$
if [ -n "$var1" ]^M$
then^M$
echo "Process running"^M$
else^M$
/usr/bin/php -q cleanlog.php^M$
fi

I tried using your command

sed 's/<ctrl+v+m>$/\n/' mytest.sh

It still doesnt work with /bin/bash mytest.sh

@Scrutinizer
Tried with this command:

tr -d '\r' < mytest.sh > mynewtest.sh

And then execute with

/bin/bash mynewtest.sh

Wow great !! It works !

@ Sangarasan
Thanks.

Thank you guys,, you are all great ! I'm learning lot from you all.

@franx47: I missed this: Not all seds support \n in its replacement.

In some tr also \r is problem, but using octal value has worked always.

cat file | tr -d '\015' > newfile

# or

tr -d '\015' < file > newfile

What tr has a problem with \r ? It is POSIX compliant and even default tr on Solaris supports it

even posix - :). Same as RFC, there is lot of code makers who has not read those pages, starting from Seattle.

I have used so many *nix system which we have used in the our customers environment. I don't remember which env it was and I'm not interested. I'm interested that our scripts works without any modification in the every our customers *nix systems. There is lot of mainframe *nix envs which has not updated. As we know standards has written after many tools has done. Ex. many *nix still use ksh88, not ksh93, even 1993 was some years ago.

With tr I have found problem using \-escape sequences in history => We use always octal format.

Here is what the POSIX spec says about this:

tr: Rationale
I am not sure why it says it is not portable..

It says using octal values is not portable because the octal values are codeset dependent. Since UNIX systems on mainframes usually use EBCDIC and UNIX systems on other boxes usually use a codeset that is a superset of ASCII, the octal character codes usually work on either EBCDIC based systems or on ASCII compatible systems, but not both. For example, the escape sequence representing the <newline> character ('\n') has the octal escape sequence value '\013' in ASCII, but '\045' in EBCDIC.

However, the octal code for the <carriage-return> character is the same in both ASCII and EBCDIC ('\015'), so (for the purposes of the above quote from the POSIX tr utility rationale) it is portable.

Note also that the quote goes all the way back to the original 1992 POSIX Shell and Utilities standard. I would have hoped that tr utilities on systems in use today all understand the \r escape sequence.