Mailinglist Archive: opensuse-packaging (130 mails)
| < Previous | Next > |
Re: [opensuse-packaging] Proposal for a shell scripting policy
- From: Guido Berhoerster <guido+opensuse.org@xxxxxxxxxxxxxxxx>
- Date: Wed, 24 Mar 2010 12:44:57 +0100
- Message-id: <20100324114457.GG7496@xxxxxxxxxxxxxxxxxx>
* Stephan Kulow <coolo@xxxxxxx> [2010-03-24 10:58]:
I'd have preferred putting it in a separate package in the Tools
repo, but if you think its better to bundle it with dash that'll
be fine, too, there are not many upstream changes.
I have a list of potentially problematic scripts and I'd take a
look if that's actually welcome.
Now that upstart is in Factory is there actually any intention to
use its native format in the forseeable future?
Most of the above is fairly trivial to convert to SUSv3 compliant
constructs without impeding readability.
You'll encounter == quite often because people are used to it
from other languages and it works in bash although it doesn't
offer any advantages.
[[ is for example another popular candidate which actually has an
advantage over [ since it doesn't do word splitting and pathname
expansion, but you can achieve tha same by just putting test
arguments inside quotes.
For more complicated scripts with lots of functions it makes
sense to use bash or ksh93 since they allow local variable scope.
It's really a matter of using common sense and good judgement.
Debian only allows echo -n as an extension to the SUSv3. But
don't use echo, use printf. echo has many problems, see the
rationale at
http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html
and
http://www.in-ulm.de/~mascheck/various/echo+printf/
for the ugly details.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx
How about putting it into the dash package for now?
I'd have preferred putting it in a separate package in the Tools
repo, but if you think its better to bundle it with dash that'll
be fine, too, there are not many upstream changes.
To give the list an idea about what we're talking in practise I ran
it over my 11.2 init scripts (those we need to have fixed urgently if we
I have a list of potentially problematic scripts and I'd take a
look if that's actually welcome.
Now that upstart is in Factory is there actually any intention to
use its native format in the forseeable future?
want to make dash an option) - only examples below:
possible bashism in /etc/init.d/ypbind line 86 (should be >word 2>&1):
ypwhich &>/dev/null && { notfound=0 ; break; };
possible bashism in /etc/init.d/xinetd line 88 ('$(< foo)' should be '$(cat
foo)'):
pid=$(<$XINETD_PIDFILE)
possible bashism in /etc/init.d/smartd line 80 ($"foo" should be eval_gettext
"foo"):
echo -n $"Reloading $prog daemon configuration: "
possible bashism in /etc/init.d/smbfs line 80 ('$[' should be '$(('):
timer=$[${timer}-1]
possible bashism in /etc/init.d/syslog line 90 (should be 'b = a'):
test "$1" == "stop" && exit 0
possible bashism in /etc/init.d/reboot line 175 (echo -e):
echo -e "$rc_done_up"
possible bashism in /etc/init.d/openvpn line 71 (shopt):
shopt -s nullglob
possible bashism in /etc/init.d/ntp line 88 ('function' is useless):
function ntpd_is_running() {
None of these cases are what Michael names "visually more pleasing". For many
of those
I would even argue that the "pure" version is easier to parse to the human
eyes.
There are surely some cases that are debatable, e.g. the function keyword is
nice to have,
but wouldn't justify a /bin/bash bang IMO. The shopt one (if really needed)
surely is.
Most of the above is fairly trivial to convert to SUSv3 compliant
constructs without impeding readability.
You'll encounter == quite often because people are used to it
from other languages and it works in bash although it doesn't
offer any advantages.
[[ is for example another popular candidate which actually has an
advantage over [ since it doesn't do word splitting and pathname
expansion, but you can achieve tha same by just putting test
arguments inside quotes.
For more complicated scripts with lots of functions it makes
sense to use bash or ksh93 since they allow local variable scope.
It's really a matter of using common sense and good judgement.
And the echo one I have no idea about: I wonder how debian handles this
problem.
Debian only allows echo -n as an extension to the SUSv3. But
don't use echo, use printf. echo has many problems, see the
rationale at
http://www.opengroup.org/onlinepubs/9699919799/utilities/echo.html
and
http://www.in-ulm.de/~mascheck/various/echo+printf/
for the ugly details.
--
Guido Berhoerster
--
To unsubscribe, e-mail: opensuse-packaging+unsubscribe@xxxxxxxxxxxx
For additional commands, e-mail: opensuse-packaging+help@xxxxxxxxxxxx
| < Previous | Next > |