I was trying to integrate a resolvconf call to do what it should, and it did... but the script always reported an error. After searching for the cause, I noticed that resolvconf actually exits with the wrong value. Nothing is mentioned in the man page about this and it is not intuitive if the whole system works in the opposite way. Reproducible: Always Steps to Reproduce: 1.echo "192.168.1.4" > fix-dns 2.resolvconf -a fix-dns < ./fix-dns ; echo $? Notice the exit state = 1 (error) 3.resolvconf -l Check that the file was added and /etc/resolv.conf changed No error occurred and was successful, still exit value was = 1 4.resolvconf -d fix-dns ; echo $? Again exit state = 1 (error) 5.resolvconf -l And again nothing went wrong and resolv.conf is correct. Now try something that should cause error: 6.resolvconf -a fix-dns < ./fix-dns ; echo $? exit = 1 (error as previously) 7.Repeat step 6. exit = 0 (success)?? Since the settings were already present, by the name fix-dns, the result should be and error and not success. Same goes if you do: 8.resolvconf -d fix-dns ; echo $? exit = 1 (error as previously) 9. Repeat step 8 exit = 0 (success). Since the configuration was not available and nothing was changed, the result should be the opposite, i.e. an error. 10. rm fix-dns This was tested with resolvconf-gentoo-1.2 and 1.4
Well you should use net-dns/openresolv in the first place, since this one is going away...
Since openresolv is still not marked as stable, and nothing is mentioned in the changelog, I had no idea it was going away. Thanks for the info.
Created attachment 142996 [details, diff] Fix return value openresolv suffers in a similar way. This patch to it should fix the exit codes though. Care to test it and let me know if it works?
The patch fixes the exit value for successful cases. The 1st ones. On the second cases I mentioned it still exits with value 0. Shouldn't 1 be expected?
Created attachment 142999 [details, diff] Error when deleting or listing a non extistant interface. But, we should not error when adding a config to a config that already exists. This patch should be used alongside the first one.
Works as expected. 1 + Error_msg on delete inexistent. 0 on other cases. I assume that reusing an existing config works as an update to that config. If so, this is fixed. Thanks for your quick fix :)
Changed summary to better fit the content
