| Summary: | net-misc/vde: bashisms in init.d script | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Alexander Tsoy <alexander> |
| Component: | Current packages | Assignee: | Nico Baggus <mlspamcb> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jmbsvicetto, proxy-maint |
| Priority: | Normal | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | checkbashism doesn't complain about this file. | ||
Please explain what tool produced the message... Also i cannot exactly match the message to the line involved... == is a concept/argument of the '[' (test) program. (In reply to comment #1) > Please explain what tool produced the message... It's a dev-util/checkbashisms > > Also i cannot exactly match the message to the line involved... > > == is a concept/argument of the '[' (test) program. '[' is a builtin in shells like bash, dash, etc. bash: $ [ "$TERM" == "xterm" ] && echo 1 1 dash: $ [ "$TERM" == "xterm" ] && echo 1 dash: 1: [: xterm: unexpected operator So for posix compliance '==' should be replaced by '=' By the way if checkbashisms is available then portage generate this QA warning. I had to put it in comment 0 instead of direct checkbashisms output. * QA Notice: shell script appears to use non-POSIX feature(s): * possible bashism in /etc/init.d/vde line 13 (should be 'b = a'): * [ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe tun * possible bashism in /etc/init.d/vde line 23 (should be 'b = a'): * [ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe -r tun (In reply to comment #1) > Please explain what tool produced the message... > > Also i cannot exactly match the message to the line involved... > > == is a concept/argument of the '[' (test) program. dev-util/checkbashisms See "/usr/lib/portage/bin/misc-functions.sh" for more details: QA Notice: shell script appears to use non-POSIX feature(s) My take on this:
checkbashism needs un update....
Shell:
if ePROGRAM
then
tPROGAM
else
fPROGRAM
fi
if ePROGRAM returns 0, then tPROGRAM is run
if ePROGRAM returns >0 then fPROGRAM is run
so ePROGRAM can be any program like grep cat etc.
there is a special program named test which has an alias '['
Shells also have an option to conditional run a list of program on one line.
using ; just run the command before ; and if that returns run the next....
using & run the previous command, don't wait for completion (ie. bg job).
using && if the first returns 0 (=true, success) run the one after it.
using || if ther first returns >0 (false) run the 2nd one.
[ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe tun
if short for:
if [ "${VDE_MODPROBE_TUN}" == "yes" ] ; then modprobe tun
the == is part of the evaluation expression of the [ ... ] command.
not a bash global assignment.
Here is the context diff.
*** vde.1 Wed Dec 19 21:02:25 2012
--- vde.2 Wed Dec 19 21:05:27 2012
***************
*** 10,16 ****
start() {
ebegin "Starting vde"
! [ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe tun
start-stop-daemon --start --quiet \
--exec /usr/bin/vde_switch -- ${VDE_OPTS}
eend $? "Failed to start vde"
--- 10,16 ----
start() {
ebegin "Starting vde"
! [ "${VDE_MODPROBE_TUN}" = "yes" ] && modprobe tun
start-stop-daemon --start --quiet \
--exec /usr/bin/vde_switch -- ${VDE_OPTS}
eend $? "Failed to start vde"
***************
*** 20,26 ****
stop() {
ebegin "Stopping vde"
- [ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe -r tun
start-stop-daemon --stop --quiet --exec /usr/bin/vde_switch
eend $? "Failed to stop vde"
}
--- 20,26 ----
stop() {
ebegin "Stopping vde"
start-stop-daemon --stop --quiet --exec /usr/bin/vde_switch
+ [ "${VDE_MODPROBE_TUN}" = "yes" ] && modprobe -r tun
eend $? "Failed to stop vde"
}
There actualy is a bug in the start script... it tries to unload the tun module BEFORE stopping the vde server. that's fixed too, i modified == -> = too. Check bashisms now complains it isn't a shell script... so are we better off? checkbashisms vde.2 script vde.2 does not appear to be a /bin/sh script (In reply to comment #6) > the == is part of the evaluation expression of the [ ... ] command. > not a bash global assignment. No, [ ... ] is a shell builtin Also there is no operand "s1 == s2" in standard: http://pubs.opengroup.org/onlinepubs/009695399/utilities/test.html and it doesn't work in dash: $ if [ "$TERM" == "xterm" ] ; then echo 1 ; fi dash: 1: [: xterm: unexpected operator Of course, this way it works: $ /usr/bin/\[ "$TERM" == "xterm" ] && echo 1 1 (In reply to comment #9) > Check bashisms now complains it isn't a shell script... use "checkbashism -f <script>" Someone needs to attach a proper patch otherwise this bug will not be fixed Created attachment 342868 [details]
checkbashism doesn't complain about this file.
New start/stop script/.
Thanks. Comitted + 29 Mar 2013; Markos Chandras <hwoarang@gentoo.org> files/vde.init: + Drop bashisms from init script. Thanks to Nico Baggus + <mlspamcb@noci.xs4all.nl>. Bug #447240 + |
Please fix bashisms in init.d script possible bashism in /usr/portage/net-misc/vde/files/vde.init line 13 (should be 'b = a'): [ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe tun possible bashism in /usr/portage/net-misc/vde/files/vde.init line 23 (should be 'b = a'): [ "${VDE_MODPROBE_TUN}" == "yes" ] && modprobe -r tun Reproducible: Always