Before, if a non-`undef` value was in `%recap` and the corresponding
value in `%config` became `undef`, the `%recap` value would remain
untouched. Now it is deleted to match `%config`.
Also, any `%recap` values without a corresponding recap variable
declaration are deleted.
Currently the semantics of recap variables are that values are updated
in `%config` and propagate to `%recap`. Before this commit,
`warned-min-interval` and `warned-min-error-interval` were set in
`%recap` instead of `%config`, meaning if they followed the semantics
they would be overwritten or deleted when synced with `%config`. Now
the values are set in `%config` to match the behavior of other recap
variables.
When a legacy protocol implementation returns, move its `status` and
`ip` results to the new `status-ipv4` and `ipv4` (or `status-ipv6` and
`ipv6`) properties.
Also remove the now-unused `status` variable definition, and remove
`ip` from the recap.
Rather than check whether `use`, `usev4`, or `usev6` is a non-disabled
value, check that `wantip`, `wantipv4`, or `wantipv6` is a defined
value. This is preparation for removing the `status` variable in a
future commit.
* Delete values from `$config{$h}` and `$recap{$h}` when resetting
values (as opposed to setting a falsy value).
* Delete values from `$config{$h}` and `$recap{$h}` when they are no
longer needed.
This is mostly done to improve the tests in `t/update_nics.pl`.
Now that the default changes depending on `usev4` and `usev6`, this is
no longer necessary. Removing it simplifies the code a bit and makes
the behavior of unit tests match the overall behavior a bit better.
This is mostly to simplify tests, but it also improves readability.
The infrastructure changes in this commit also make it possible to
introduce a new `url` variable that defaults to `opt('server', $h)`
concatenated with `opt('script', $h)` so that we can start migrating
away from those user-unfriendly variables.
This doesn't add any new command-line arguments, but it does mean that
a new command-line argument can be added for any variable, not just
those in `$variables{'global-defaults'}`, and its value will be copied
to `%globals`.
My main motivation for this commit is to make it possible to remove
the redundant variable declarations between
`$variables{'global-defaults'}` and
`$variables{'protocol-common-defaults'}`.
The `opt` function falls back to global/default if the value is
undefined, even if it is explicitly set to `undef`. `group_hosts_by`
should behave the same.
The alternative is to "fix" the code to match the original intention,
but users haven't been complaining so it's better to avoid the risk of
introducing a new bug in the fix.
Different protocols can have different default values for a particular
variable. Grab the protocol-specific variable definition if given a
hostname when looking up the variable's default.
Allow newlines to be in values, but stop searching for assignments
once an unescaped/unquoted newline is discovered. This is preparation
to using `parse_assignments` to process the `--options` command-line
argument, which might have embedded newlines.
Variable declarations already have a `required` flag, which makes the
type confusing. What would it mean for a variable to be a required
`T_OFQDN`? And how would an optional `T_FQDN` differ from an optional
`T_OFQDN`?
This does not affect the `--help` command-line argument.
The `help` setting didn't do anything useful, and it didn't make sense
to set `help=1` in the config file (or pass `--options=help=1`), so
this removal is unlikely to affect anyone. If the setting does exist,
the user will get a warning and the setting will be ignored.
Removed the min-interval set to 5 minutes in changeip, because according to my tests, changeip has no problem updating every 30 seconds, which is the default min-interval value in ddclient
Previously, `nochg` responses were treated as failures and the logged
message for all responses was incorrect (either `undef` or "Unknown
reply from Infomaniak").
Background: Hash values are always scalars, so lists of values can
only be stored in hashes in arrayref form.
The following is legal but does not do what one might expect:
my %h = (
a => (1, 2),
b => (3, 4),
);
The `=>` operator is just a variant of the comma operator, and lists
in list context are flattened, so the above is equivalent to:
my %h = ('a', 1, 2, 'b', 3, 4);
which is equivalent to:
my %h = (
a => 1,
2 => 'b',
3 => 4,
);
which is obviously not what was intended.
Before, the returned JSON wasn't even parsed -- the error handling
code was reusing the parsed response from the earlier `GET`. Also, it
was reading object properties that were not documented in the Gandi
API documentation.
