Init script behaving differently when run on machines in the UK vs US

BrianK · 07-19-2011, 06:44 PM

I have an initscript that behaves slightly differently in the UK than it does in the US. Not a huge issue, but I'd like to know why and how to fix it. I imagine it has something to do with localization, but I'm at a loss as to what it could be, as it's just bash.

in the UK:

Code:

[root@server ~]# /etc/init.d/worker 
status}

in the US:

Code:

[root@Fedora-14x64-01 ~]$ /etc/init.d/worker 
Usage: /etc/init.d/worker {start|stop|restart|status}

the script is pretty typical:

Code:

<snip>
# See how we were called.
case "$1" in
  start)
	start
	;;
  stop)
	stop
	;;
  restart|reload)
	stop
	start
	RETVAL=$?
	;;
  status)
	status worker
	RETVAL=$?
	;;
  *)
	echo $"Usage: $0 {start|stop|restart|status}"
	exit 1
esac

exit $RETVAL

Any ideas why this would be happening? This is on Fedora 14, FWIW.

Nominal Animal · 07-19-2011, 07:17 PM

If you used #!/bin/sh then it is possible you use different shells (as /bin/sh is usually just a symlink to some other shell). I know for a fact that for example dash does not support the rather quirky quoting ($"string") you used for the echo command; why you did not use standard double quotes (just dropping the first $) is a mystery to me. Perhaps you want the script to only work if you use bash or its variants?

(dash version 0.5.5.1-7ubuntu1 does not fail in any spectacular fashion, it interprets the initial $ just as if it was \$. Earlier versions might handle this differently.)

I cannot see how localisation could affect this. The only possible cause for the output I can think of -- assuming your description of the situation is exact -- is that the other shell does not support that quoting mechanism, and eats everything up to the final | as part of the bit it does not understand, only echoing the rest of the string.

BrianK · 07-19-2011, 07:45 PM

Thanks for the response.

This is a bash script - #!/bin/bash

The $' ... ' quoted string-expansion construct is a mechanism that uses escaped octal or hex values to assign ASCII characters to variables, e.g., quote=$'\045'. You'll find that many init scripts do this:

Code:

wpa_supplicant:		echo $"Usage: $0 {start|stop|status|restart|try-restart|reload|force-reload}"
xend:	echo $"Usage: $0 {start|stop|status|restart|reload|force-reload}"
xendomains:	echo "Usage: $0 {start|stop|restart|reload|status}"
xfs:	echo $"Usage: $prog {start|stop|status|restart|reload|condrestart}"
xinetd:	echo $"Usage: $0 {start|stop|status|restart|condrestart|reload}"
ypbind:	echo $"Usage: $0 {start|stop|status|restart|condrestart}"
yppasswdd:	echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
ypserv:	echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
ypxfrd:	echo $"Usage: $0 {start|stop|status|restart|reload|condrestart}"
yum-updatesd:	echo $"Usage: $0 {start|stop|status|restart|reload|force-reload|condrestart}"

It's paranoid, certainly, but so should one be when root is running something unattended.

catkin · 07-20-2011, 12:33 AM

Quote:

Originally Posted by BrianK

The $' ... ' quoted string-expansion construct is a mechanism that uses escaped octal or hex values to assign ASCII characters to variables, e.g., quote=$'\045'.

Correct but bash ANSI-C quoting is not what Nominal Animal wrote about or what is used in the script. The script uses Locale Translation ($" ... ") which could behave differently in different locales such as US and UK.

BrianK · 07-20-2011, 11:41 AM

Ahhh. I was not aware of the locale translation. Thanks for that!

I'm working with someone (in the UK) who did a little more digging:

Quote:

It looks like there's a mistake in the en_GB.po file, line 1706:

#: /etc/rc.d/init.d/clvmd:136 /etc/rc.d/init.d/cman:450
#: /etc/rc.d/init.d/i8k:98 /etc/rc.d/init.d/kannel:110
#: /etc/rc.d/init.d/qdiskd:59
msgid "Usage: $0 {start|stop|restart|status}"
msgstr "status}"

This is ... a Fedora bug it would seem, and one that's still present in Fedora15.

Mystery solved.

Thanks all.

Nominal Animal · 07-20-2011, 10:34 PM

I did not know Bash used that for locale translation either.

It was originally added for Bash 2.0, according to the CHANGES file. ksh93 seems to support the same.

The $"..." implementation is also a problem for users of certain character sets (BIG5, BIG5-HKSCS, GBK, GB18030, SHIFT_JIS, JOHAB); some of their glyphs cannot be used in localised strings at all, or Bash will execute parts of the strings as commands. The reason is the order of evaluation. First, Bash looks up the string in a message catalog. Then, the resulting string is evaluated just as if it was in normal double quotes, including commands ($(..) and `..`).

This means that an unescaped exclamation point (!) in the translated string will produce rather surprising results, if history substitution happens to be enabled (set -H or interactive shell).

None of this will work in a generic POSIX shell (#!/bin/sh) at all, so don't be fooled by the examples you might see on the web. A lot of us have /bin/sh symlinked to something other than /bin/bash. In fact, I kind of assumed a service script to use /bin/sh and not /bin/bash, since service scripts are supposed to be portable between systems; that's why I didn't check the Bash documentation before replying.

While the $"..." localisation method is in my opinion quite useful (certainly simpler than using the gettext shell command), it should be used with care; noting at least the portability issues and the quoting rules for the translated messages, especially '!'. It is unfortunate that the Bash manual does not bother to explain any of the caveats.

catkin · 07-21-2011, 12:04 AM

Thanks for reporting an in-depth investigation, Nominal Animal