powered by Jive Software

Wildfired: 50: Syntax error: "(" unexpected

Greetings Everyone,

Well I am making the jump to install Wildfire on a brand new Ubuntu Edgy server. My problem is that when I try to use the wildfired script, I get that error:

/wildfired: 50: Syntax error: “(” unexpected

I cannot for the life of me see what’'s wrong with it, line 50 is the execCommand() Function. Everything I can see seems fine, but I have been building this server just about all day so my eyes are a little glossed over. Any thoughts?

NOTE: For reference, I posted the full script here. (Even tho it’‘s the same, I haven’'t modified it except the $WILDFIRE_HOME directive.)


#!/bin/sh

  1. wildfired Stops and starts the wildfire XMPP service

  1. chkconfig: 2345 99 1

  2. description: Used to start and stop the wildfire XMPP server

  3. Script used to start wildfire as daemon

  4. The script has currently been tested on Redhat Fedora Core 3,

  5. but should theoretically work on most UNIX like systems

  1. before running this script make sure $WILDFIRE_HOME/bin/wildfire is

  2. executable by the user you want to run wildfire as

  3. (chmod +x $WILDFIRE_HOME/bin/wildfire)

  1. This script should be copied into /etc/init.d and linked into

  2. your default runlevel directory.

  3. You can find your default runlevel directory by typing:

  4. grep default /etc/inittab

  1. Link to the directory like follows

  2. cd /etc/rc.d

  3. ln -s …/init.d/wildfired $90wildfired

  1. Set this to tell this script where wildfire lives

  2. If this is not set the script will look for /opt/wildfire, then /usr/local/wildfire

export WILDFIRE_HOME=/usr/share/wildfire

  1. If there is a different user you would like to run this script as,

  2. change the following line

#export WILDFIRE_USER=jive

  1. If a wildfire home variable has not been specified, try to determine it

if ; then

if [ -d “/opt/wildfire” ]; then

WILDFIRE_HOME="/opt/wildfire"

elif [ -d “/usr/local/wildfire” ]; then

WILDFIRE_HOME="/usr/local/wildfire"

else

echo “Could not find Wildfire installation under /opt or /usr/local”

echo “Please specify the Wildfire installation location in environment variable WILDFIRE_HOME”

exit 1

fi

fi

function execCommand() {

OLD_PWD=pwd

cd $WILDFIRE_HOME/bin

CMD="./wildfire $1"

su -c “$CMD” $WILDFIRE_USER &

sleep 1 # allows prompt to return

cd $OLD_PWD

}

start() {

execCommand “start”

}

stop() {

execCommand “stop”

}

case “$1” in

start)

start

;;

stop)

stop

;;

restart)

stop

sleep 10 # since stop is backgrounded

start

;;

status)

retval=$(pgrep -u $WILDFIRE_USER -f $WILDFIRE_HOME/bin/wildfire > /dev/null ; echo $?)

if [ “$retval” = “0” ] ; then

echo “wildfire is running”

exit 0

else

echo “wildfire is not running”

exit 0

fi

;;

*)

echo “Usage $0 {start|stop|restart|status}”

exit 1

esac

exit 0


I just had this problem too. You have to change the first line to #!bin/bash (Apparently root user doesn’'t use a bash shell?)

sorry - should be #!/bin/bash

You’‘ll also need to amend line 53 and remove the .sh from wildfire.sh, and create the user jive (or whatever but change the script) before you’'ll see it work.

The solution suggested here (changing the first line to #!/bin/bash) will work, but it’‘s the wrong answer. I hope the Jive folks don’'t use this as a permanent fix.

The right answer is to make this shell script adhere to the POSIX standards for sh, and use #!/bin/sh on the first line. Not only is it The Right Thing To Do, but it means this script will work on any POSIX system (*BSD, Solaris, HPUX, AIX, etc.) and not just Linux.

Since most Linux distros have up until now shipped with /bin/sh as bash, people writing scripts have gotten very sloppy and included bash-specific features in scripts headed by /bin/sh, which is broken according to the standards. A number of newer distros (for example, Ubuntu is the best-known one), mainly in the interests of speeding up the system, are using a stripped down shell that only does POSIX and doesn’‘t have a lot of extra features as /bin/sh. That’'s why these sloppy scripts are now coming to light.

Fortunately, the wildfired script is not nearly as bad off as some I’‘ve seen, and it’'s very simple to fix. To do so:

Leave the start of the script as “#!/bin/sh”, and:

Change the line “function execCommand() {” to “execCommand() {” (remove the keyword “function”).

There is no “function” keyword in POSIX; that’‘s a bash-specific enhancement that’'s not necessary here…

As someone else mentioned, you also have to change the “./wildfire.sh $1” to “./wildfire $1” since the script in wildfire/bin changed from wildfire.sh to just wildfire.

Hey Paul,

I’'m not a *nix expert myself. Can you send me (gaston at jivesoftware.com) the modified scripts with your suggestions? I would like to include them for Openfire 3.3.0 to be out next week.

Thanks,

– Gato

Hi Gato,

Openfire 3.3.0 out next week … I did hope that you mean the gamma or delta release and not a final version. There are still 24 open issues which are not yet implemented - I wonder how one can release a 3.3.0 version without testing.

Wildfire 3.2.0 was a very buggy release so I’'m happy that 3.2.4 is available and much more stable.

And one may want to change Wildfire to Openfire also within the script and rename it.

LG

This problem is still present in OpenFire 3.3.1. I use Ubuntu which uses Dash and not Bash for /bin/sh. The openfired script assumes Bash and not POSIX shell. I guess this problem is not going to be fixed and so changing /bin/sh to /bin/bash is the only option?

In fact I always go in to edit OPENFIRE_HOME and OPENFIRE_USER anyway so it is no big deal really, just massively irritating.

Also irritating is that the OpenFire distribution unpacks into directory openfire and not openfire-x.y.z, but I guess I should open another thread for this irritation