Giters

pixelb / crudini

A utility for manipulating ini files

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Merging sections uses wrong values

erhhung opened this issue · comments

commented

Consider these two ini files:

"old_ini":

[section1]
foo = old1foo
bar = old1bar
baz = old1baz

[section2]
foo = old2foo
bar = old2bar
baz = old2baz

"new_ini":

[section2]
foo = new2foo
bar = new2bar
baz = new2baz

[section3]
foo = new3foo
bar = new3bar
baz = new3baz
qux = new3qux

And running the following --merge operation to update section2 values from new to old:

$ crudini --merge --output=- old_ini section2 < new_ini

[section1]
foo = old1foo
bar = old1bar
baz = old1baz

[section2]
foo = new3foo
bar = new3bar
baz = new3baz
qux = new3qux

Why are values from section3—or, rather, the very last set of values from the second file—being used to update values in the specified section: section2?

Expected Behavior

The merge operation should use values only from the specified section, resulting in:

[section1]
foo = old1foo
bar = old1bar
baz = old1baz

[section2]
foo = new2foo
bar = new2bar
baz = new2baz

Version: crudini 0.9.3

commented

I agree this is confusing, but also most flexible.
To do what you want (i.e. only consider a single section for merging) you can:

crudini --get --format=ini new_ini section2 | crudini --merge --output=- old_ini section2

As originally written (and as documented in crudini tests),
when you specify a section to merge, then crudini will merge params from all sections to the specified one

commented

Thanks for the "workaround" approach, but I still think the default behavior should be different.

when you specify a section to merge, then crudini will merge params from all sections to the specified one

Even if this is "mechanically" possible based on current behavior, I'm having a hard time thinking of real world use cases where one might actually want to merge params from all sections into a specific one.

An app should, by default, cater to the most common use case with the most logically expected behavior, and use other options or compound "piping workarounds" to support non-standard use cases so that reading documentation isn't a requirement.