Yes, I know you want to know how to implement your solution...

PJH

... 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?

Me: command_to_get --internal_IP_address of --currently_selected_server | grep internal_ip

That? I'd've suggest other_command but it doesn't support --required_option

PE: Thanks - but that's no sodding use in static_config_file

[self-evidently - static means it doesn't change - PJH]

Me: What are you trying to do?

PE: 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_ip?

PE: Well $dynamic_internal_ip is dynamic and sent by that_server

Me: [duh..] Indeed. Why do you need to know it? [strike 3]

PE: Well I need $dynamic_internal_ip so I can tell internally_written_program_1 where to send its data.

Me: Well if you don't tell internally_written_program_1 where 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 internally_written_program_2, internally_written_program_3 and program_my_dept_had_no_say_in

Me: For _2 and _3 stop 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.

boomzilla

Oldest story in the book. Boy meets problem. Boy mis-solves problem. Problem not solved.

antiquarian

Here's the sequel: Government official meets problem. Government official mis-solves problem. Problem gets worse. Government official gets increased budget.

blakeyrat

He sounds like a dick.

A British dick.

boomzilla

@blakeyrat said:

A British dick.

Is it spotted?

blakeyrat

I wouldn't even venture to guess.

PJH

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

obsolete,
deprecated, and
"overriding the default with the default'

lines, reducing the config down to 50%-25% of it's former size.

boomzilla

My daughter tittered when we saw some at the grocery store.

another_sam

@boomzilla said:

tittered

uh huh huh huh huh huh

lightsoff

@PJH said:

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.
[click]

Usually they could get the same result by using UDP. Often to localhost so no hardware at all.

DaveK

@blakeyrat said:

He sounds like a dick.

A British dick.

Quick as a flash - and witty with it.

FrostCat

@lightsoff said:

You are all horrible and I hate you.

Your users are all blakeyrat? Dang, son, that must suck.