Summary: | net-misc/netifrc-0.2.2 with /bin/sh -> dash - /lib64/rc/sh/runscript.sh: 106: local: ::192.88.99.1: bad variable name | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | OGINO Masanori <masanori.ogino> |
Component: | Current packages | Assignee: | netifrc Team <netifrc> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | bruce, kfm, sam |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: | https://bugs.gentoo.org/show_bug.cgi?id=891019 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 780573 | ||
Bug Blocks: | 526268 | ||
Attachments: |
/etc/conf.d/net with 6to4 settings
The output of `/etc/init.d/net.6to4 --debug start` The output of `/etc/init.d/net.6to4 --debug start`, with the patch suggested by robbat2 |
Description
OGINO Masanori
2014-11-05 12:59:39 UTC
Created attachment 388582 [details]
/etc/conf.d/net with 6to4 settings
This is copied from my configuration file, but removed unnecessary details (I think) such as the content of config_enp3s0. I use static IP(v4) addresses in them.
if this is still happening, please run: $ /etc/init.d/net.${6TO4} --debug start >& log and then attach that log here for us No response from user with needed debug output. Created attachment 456542 [details]
The output of `/etc/init.d/net.6to4 --debug start`
I'm sorry, I've missed notifications until now.
The original machine has gone, but the problem remains on my current machine.
The log on the current machine is attached.
Would you reopen this bug?
Great to hear back from you! Can you please check net/ip6to4.sh, and experiment with patching this, -local routes_ip6to4=$(service_get_value "routes_ip6to4_$IFVAR") +local routes_ip6to4="$(service_get_value "routes_ip6to4_$IFVAR")" If that does fix it, I need to confirm part of the POSIX SH spec on where quoting is required during assignment. (In reply to Robin Johnson from comment #5) > Great to hear back from you! > > Can you please check net/ip6to4.sh, and experiment with patching this, > -local routes_ip6to4=$(service_get_value "routes_ip6to4_$IFVAR") > +local routes_ip6to4="$(service_get_value "routes_ip6to4_$IFVAR")" > > If that does fix it, I need to confirm part of the POSIX SH spec on where > quoting is required during assignment. After applying the patch, 6to4 service starts successfully and I confirmed a 6to4 interface up via `ifconfig`! I will attach a log with the patch soon. Created attachment 456546 [details]
The output of `/etc/init.d/net.6to4 --debug start`, with the patch suggested by robbat2
The patch put in /etc/portage/patches/net-misc/netifrc before `emerge -1 netifrc`:
diff -ru netifrc-0.5.1.orig/net/ip6to4.sh netifrc-0.5.1/net/ip6to4.sh
--- netifrc-0.5.1.orig/net/ip6to4.sh 2016-12-18 10:39:37.570023202 +0900
+++ netifrc-0.5.1/net/ip6to4.sh 2016-12-18 10:40:46.450023440 +0900
@@ -103,7 +103,7 @@
ip6to4_start()
{
local config_ip6to4=$(service_get_value "config_ip6to4_$IFVAR")
- local routes_ip6to4=$(service_get_value "routes_ip6to4_$IFVAR")
+ local routes_ip6to4="$(service_get_value "routes_ip6to4_$IFVAR")"
# Now apply our config
eval config_${config_index}=\'"${config_ip6to4}"\'
In situations where word splitting would not otherwise affect the manner in which an assignment is parsed, quoting is most definitely not required by POSIX. For example, these are all correct: var=foo var=$othervar # identical to var="$othervar" var=$(some_command) # identical to var="$(some_command)" So what's the problem? Unfortunately, the problem is the use of the local keyword. Don't expect POSIX to explain this because local is a standards transgression to begin with. It is not documented by POSIX and, as such, no POSIX-confirming shell is obligated to implement local in the first place. Any script that purports to target #!/bin/sh and proceeds to use local is non-portable, by definition. That said, let's take a closer look at what's going on. Firstly, bash behaves exactly as we'd expect. $ code='f() { local a=$(printf %s "$1"); local b="$(printf %s "$1")"; printf "<%s>" "$a" "$b"; }; f "foo bar"' $ bash --posix -c "$code" <foo bar><foo bar> So does busybox ash. $ busybox sh -c "$code" <foo bar><foo bar> So does mksh, from the MirBSD project. $ mksh -c "$code" <foo bar><foo bar> And so does loksh, a port of the excellent incarnation to be found in OpenBSD. $ ksh -c "$code" <foo bar><foo bar> Unfortunately, things start to fall apart in other popular shells that may act as a valid /bin/sh. $ dash -c "$code" <foo><foo bar> $ posh -c "$code" # yes, even posh supports local <foo><foo bar> I tried several other candidates, such as ksh93, but found that most did not provide a local keyword. No surprises there. Even though POSIX can offer no guidance here, I would consider the behaviour of dash to be a bug. Still, as things stand, we must deal with the consequences. @William (and, indeed, any gentoo dev inclined to listen), if you are going to continue using local then, at the very least, I would recommend getting into the habit of not using local in conjunction with an assignment. That may sound unduly stringent but please keep in mind that local has other problems that can easily trap the unwary. Case in point: $ bash -c 'f() { local var=$(false) || exit; echo "still running"; }; f' $ bash -c 'f() { var=$(false) || exit; echo "still running"; }; f' One might reasonably assume that these are equivalent. However, one would be terribly wrong. Where using local, the exit status value of the command substitution is masked! Not only that, but dash inherits this design flaw. The simplest way to avoid all of these issues is to never declare a variable with local, while simultaneously assigning to it. Just to add that, whatever one may think of my recommendation, double-quoting the expansion of the command substitution is a valid way of working around the issue in dash and other shells that behave as dash does, on the condition that one fully understands - and accepts - the consequences of local squashing the exit status value to 0. (In reply to Kerin Millar from comment #9) > Just to add that, whatever one may think of my recommendation, > double-quoting the expansion of the command substitution is a valid way of > working around the issue in dash and other shells that behave as dash does, > on the condition that one fully understands - and accepts - the consequences > of local squashing the exit status value to 0. I don't think there's any spots in the codebase that presently depend on the exit status of a subshell command there (I did a quick review only). That said, part of this is never having a clear specification of exactly what the target dialect of Shell is. There was a GSOC project that contributed the systemd hooks and that started some of the test harness requirements for this project, but they need a LOT of additional work to be usable. It should ideally test with all different shells: - bash - busybox sh - mksh - dash - posh I don't think csh/ksh will be supported, they are just too far away from the rest in a few cases. This is patched for now Thanks, Robin. I'm sure you're right but I'll check again also. As an aside, there is actually a way to approximate the effect of local in POSIX sh, which is to use a different form of compound command to contain the function body. my_func() ( # This is a compound command that runs in a subshell. # The assignment to var will be undone upon finishing. var=$1 ) That works nicely, though it is obviously not suitable where intentionally manipulating variables that were defined in some other scope. Still, I tend to use this pattern in my own 'pure' sh code as of late. I concur that some of the problems stem from not being clear as to the target shell, or shells as the case may be. Presently, the project ostensibly feels as though it wants to target POSIX sh in principle, while not being committed to that requirement. As I remarked elsewhere, I've reached the conclusion - after many years of practice - that, more often than not, it pays to target bash other than for the most trivial programs. I think that the lack of arrays, in particular, is damaging to netifrc and the overall quality of openrc runscripts. One ends up outright relying on the unfortunate behaviour of word splitting (with set -f sadly nowhere to be seen), questionable eval usage and so on. For splitting strings pretending to be arrays, even just having read -ra would be useful. That's not to mention the various other features of bash that would make it easier to solve relevant problems tidily, without forking off and running external utilities which have their own issues of portability. All that said, the list of shells that you cited looks entirely reasonable, as concerns Gentoo's immediate needs. Actually, with one exception. I think that posh is useful for exploring certain portability concerns but that it's a waste of time specifically targeting it. I explain this view further in bug 720996. This has been open for a very long time now. Could the fix please be patched into 0.7.1 so that a working version with stable keywords is available? The bug could then be closed. Resolved by bug 780573. |