Change read_ini.sh to use associative arrays.

[jcass77]

Allows special characters to be used in section names of settings.ini.

Adds support for configuring extensions like [local-sqlite] properly.

Note that support for the search_limit parameter requires Mopidy-Local-SQLite >= 0.9.2 (run pip install --upgrade Mopidy-Local-SQLite to upgrade)

This is a rebase of #234 on to /upstream/develop.

[kingosticks]

Thanks for doing this. My only concern is that we are about to release v0.6 and I really don't want to get a bug in such a fundamental piece of Muiscbox.

[kingosticks]

Well, I should rephrase, "another, different bug"

[jcass77]

Yes I think we should hold off incorporating this in the v0.6 release to see if we can find a permanent solution. At this stage my take on this is that:

1. the current release is 'broken' in that it does not handle special characters in section headers properly. This limits the Mopidy extensions that we'll be able to include in the Pi MusicBox distribution.
2. this proposed implementation does not work for some of the local-sqlite configuration parameters, but I haven't been able to verify that they are well formed to begin with based on my reading of the Python INI file specification.

Perhaps we can circle back to this after 0.6 has been released?

[jcass77]

We should be able to align the behaviour of the script with Python's RawConfigParser by just using the same regular expressions (see source code for details).

It looks like this will be something like (?P<option>.*?)\s*(?:\s*(?P<vi>=|:)\s*(?P<value>.*))?$.

[kingosticks]

Ok then that's great you agree. It's a real shame as the bug it's fixing
it's a pain, but having just shipping a bugged release (100% my fault) I
don't want to do another.

I like your idea to leverage Rawconfigparser. I was considering hacking up
a bash test suite but that's the complete opposite way I intend to go with
this stuff and not worth the time.
On 23 Mar 2015 05:43, "John Cass" notifications@github.com wrote:

We should be able to align the behaviour of the script with Python's
RawConfigParser by just using the same regular expressions (see source
code http://svn.python.org/projects/python/tags/r32/Lib/configparser.py
for details).

It looks like this will be something like
(?P.?)\s(?:\s_(?P=|:)\s_(?P.*))?$.

—
Reply to this email directly or view it on GitHub
#253 (comment)
.

[jcass77]

I've revamped the script to behave more like Python's RawConfigParser.

Please take a look at this fork to the bash_ini_parser project. I'm not sure if it will be merged there as it changes quite a few aspects of the original implementation.

The script can be tested by running ./test.sh. This also covers the examples specified in the Python INI file specification (at least as far as I can tell).

I suggest that we work on it there until we are happy and then we can merge it back into Pi MusicBox when all requirements have been satisfied?

[jcass77]

@kingosticks, now that 0.6 is out of the way do you think we can take another look at changing this ini file parser script?

I've re-based on the current 'develop' branch so should be ready for merging - would you be willing to give it a go?

[kingosticks]

Hi, sorry for the delay in getting back to you. Yes indeed, let me try out a couple of tests tonight/tomorrow and get this in.

[kingosticks]

So the parsing looks fine but the problems are in startup.sh where the quotes around the keys are messing up the quoted string output e.g.
echo "root:${INI["musicbox__root_password"]}" | chpasswd

There are a few similar cases throughout the script and one in setsound.sh too. Can we use single quotes? Or move it into a temporary variable and then use that in the quoted output?

[jcass77]

Thank you for the feedback. Could you elaborate a little on the problem that you are encountering please? My scripting skills aren't that great, but I get the output of the above as root:my_pass where 'my_pass' is specified in settings.ini.

[kingosticks]

Yeh... I'm not sure how I managed to convince myself that was a problem as it seems to work just fine. I'll resurrect my test files and try and see what I did wrong.

In other news, I came across this neat solution using python which is bit annoying as I it's so much simpler.

[jcass77]

Using the built-in Python parser will be much better as it is one less thing that we need to maintain.

Are you going to take a shot at integrating?

[kingosticks]

I think it makes sense to do so. I'm sorry that it means we don't need your
parser fixes then. I'm out of town this weekend but I'm going to spend time
on all of this next week.
On 30 May 2015 06:52, "John Cass" notifications@github.com wrote:

Using the built-in Python parser will be much better as it is one less
thing that we need to maintain.

Are you going to take a shot at integrating?

—
Reply to this email directly or view it on GitHub
#253 (comment)
.