If e.g. /bin/sh is a symlink to /bin/dash then openresolv-3.3.2 fails with /lib/resolvconf/pdnsd: 629: [[: not found The reason is that /lib/resolvconf/pdnsd uses lots of bashisms (which is apparently OK, since the script starts with #!/bin/bash) but /sbin/resolvconf does not *execute* the scripts but sources them in a subshell (line 338); since /sbin/resolvconf claims to be POSIX (#!/bin/sh) this leads to a problem... Possible solutions: 1. Modify line 338 of /sbin/resolvconf from the original ( . "$script" "$cmd" "$iface" ) to "$script" "$cmd" "$iface" (i.e. simply execute instead of source the scripts; the braces for a subshell are then not needed, of course). 2. Make /sbin/resolvconf also #!/bin/bash 3. Rewrite /lib/resolvconf/pdnsd to avoid bashisms. I'd vote for 1. which appears to be easy and clean and keeps fast executing (and will also not break if other scripts in /lib/resolvconf require other shells). Of course, 3. would be even cleaner and faster from the viewpoint of execution time, but this seems to require a lot of work.
it means all variables being passed to the script need to be exported
pdnsd isn't from openresolv, so I guess it's a Gentoo addon Another option would be this if [ -x "$script" ]; then "$script" "$cmd" "$iface" else ( . "$script" "$cmd" "$iface" ) fi IIRC, all of the subscribers work being run directly as well - just slower.
(In reply to comment #1) > it means all variables being passed to the script need to be exported As I understand Roy's reply there are no such variables. (I also guessed so from the fact that the important data is passed as arguments, but I must admit that I did not check seriously and currently have no time to do so). I just found that possibility 3 is attempted in bug 248925 So if that script works, it is of course the better solution anyway... Should the bug be marked as a duplicate?
(In reply to comment #3) > (In reply to comment #1) > > it means all variables being passed to the script need to be exported > > As I understand Roy's reply there are no such variables. Actually there are variables :) resolvconf -v shows them To make it easier, I've implemented my idea above http://roy.marples.name/projects/openresolv/changeset/4a0b1dc10a0603ffdfc01cc708e008dc1d5dd09f And export these vars for subscribers so they don't have to call out resolvconf -v either. http://roy.marples.name/projects/openresolv/changeset/ca481488c61a959429212baabcf389e1c90820ee Of course, subscribers should still work without that information - like say they were called directly from outside resolvconf. > I just found that possibility 3 is attempted in bug 248925 > So if that script works, it is of course the better solution anyway... > Should the bug be marked as a duplicate? No, as the current resolvconf implementation requires POSIX shell which could be viewed as a bug. I know most Gentoo devs curse my name at times because I deny them the use of pointless bash features ;)
openresolv-3.3.4 has been released with the above patch
(In reply to comment #5) > openresolv-3.3.4 has been released with the above patch > in tree. thx
