Yes, I know you want to know how to implement your solution...
... but what's the problem for which you think that's the right solution?
TLDR: Stop trying to over-engineer the configuration and use the sodding defaults - it'll do what you're trying to get it to do.
The following conversation, while anonymised somewhat, is more-or-less verbatim and was over an IM client
[after interrupting me with "Hello" followed immediately by:
Project engineer: How do I get the internal IP address of the server [my firmware] is using?
command_to_get --internal_IP_address of --currently_selected_server | grep internal_ip
That? I'd've suggest
other_commandbut it doesn't support
PE: Thanks - but that's no sodding use in
[self-evidently - static means it doesn't change - PJH]
Me: What are you trying to do?
section_of_static_config/option = $dynamic_internal_ip
Me: No - that's what you think your solution is to what you're trying to do.
What are you trying to do? [strike 1]
PE: Nothing, since I know anything I try won't work
[well - I realised that over a minute ago; your solution is broken... - PJH]
Me: What are you trying to do? [strike 2]
What problem do you have that requires
$dynamic_internal_ipis dynamic and sent by
Me: [duh..] Indeed. Why do you need to know it? [strike 3]
PE: Well I need
$dynamic_internal_ipso I can tell
internally_written_program_1where to send its data.
Me: Well if you don't tell
internally_written_program_1where to send its data, then it will default automatically to
$dynamic_internal_ip- that's the default behaviour. The override is if the data needs to go elsewhere.
Don't override that config item and it'll work (a) as originally designed and (b) as you want it to.
PE: What about
_3stop telling them where to send data as well, and they'll default to where you're trying to send data. As for
program_my_dept_had_no_say_in- your team chose that over our heads; you're on your own with that but you could use [command given st the start] to obtain the address.
How you use that is your problem.
Oldest story in the book. Boy meets problem. Boy mis-solves problem. Problem not solved.
Here's the sequel: Government official meets problem. Government official mis-solves problem. Problem gets worse. Government official gets increased budget.
He sounds like a dick.
A British dick.
I wouldn't even venture to guess.
incidentally - the reason the defaults were overridden is because that particular department do their configs cargo-cult fashion.
They take the config from the previous project (for a different customer) and simply tweak it for this project (current customer.)
This config will then be used to form the base of the next customer's project....
Sometime in the past one project had to override that parameter. Everyone (over there) has continued to do it ever since.
And someone in my department (we gave up pointing them in the direction of the documentation yonks ago) will come across one of them 2 years, and strip out all the
- deprecated, and
- "overriding the default with the default'
lines, reducing the config down to 50%-25% of it's former size.
My daughter tittered when we saw some at the grocery store.
but what's the problem for which you think that's the right solution?
I get this one regularly
User: How do I connect [long_obsolete_physical_protocol] to [brand_new_device]
Me: You'd need to buy [expensive_box] to convert it to Ethernet.
However, are you sure you need to? [brand_new_device] supports lots of different protocols, you could get the same result some other way.
What's at the other end and what are you trying to do?
User: That [box] is really expensive. You are all horrible and I hate you.
Usually they could get the same result by using UDP. Often to localhost so no hardware at all.
You are all horrible and I hate you.
Your users are all blakeyrat? Dang, son, that must suck.