>
> Hi Alan,
>
> You mean ini.get right?
Ah, is that what I called it? Must be.
> One issue I've discovered is that ini.set will happily write multiline
> content into a value, while ini.get will only return the first line
> of the same value.
I use the standard win32 API functions to get and retrieve ini values;
that sounds very much like what they would do. They're not widly
intelligent.
> It seems to me that "get" should be able to return anything that "set"
> will put there. As such, perhaps "set" should give an error on
> multiline content. Otherwise, "set" (or an alternate function) should
> automatically alter multiline content before writing it to the ini, to
> conform to whatever multiline standard is adopted.
Or, you can adopt your own convention: e.g.
-- replace all instance of newline with something else
before writing something to ini, reverse the replacement
on read back.
-- check out vars plugin. Use it to save/restore single
variables when you need them. I intended that anything
that can occur in a variable be savable to/recoverable from
an ini file, and I think that's what it does.
> I would like to point out that the Config::Inifiles Perl module uses
> Unix "here document" format for this purpose. If you update an ini
> value named "Parameter" with multiline content containing
>
> Line 1
> Line 2
>
> it ends up in the ini file looking like this:
>
> Parameter= <<EOT
> Line 1
> Line 2
> EOT
Same old problem. Suppose you're unlucky and Parameter just happens
to have the value " <<EOT"?
> There is a way to designate use of another string instead of EOT, but
> the beginning always gets the "<<" in front of it. When a multiline
> value is retrieved, the markers are not included.
>
> Maybe this would have been a good suggestion for Bruce as well.
Let me know if vars plugin doesn't float your boat.
