Improve IPv4 and IPv6 address handling #104
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Motivation
Atoning for the sins I committed in #3, and addressing #71.
Summary of changes
sipcalc
, Python'sipaddress
module),sipcalc
, and native) agree with one another.Caveats and Reservations
Complexity
There is a significant quotient of incidental complexity here, especially around testing for whether Python/
ipaddress
and/orsipcalc
are available. This PR would be half as large if it were limited to just Bash-native address handling.Maybe any Python stuff should wait for #57?
Differences of opinion
sipcalc
does not like addresses in the form::1:2:3:4:5:6:7
or1:2:3:4:5:6:7::
, whereas Python'sipaddress
module likes them just fine. I've made the native expansion routine accept them as well. Not sure what the right call is, but it does seem wrong to me thatupdate-systemd-resolved
would accept an address in some system configurations (Python available, or neither Python norsipcalc
available) but not others (Python not available,sipcalc
available).