[Bug]: Fails to read ini file if line-endings are `CRLF` instead of `LF` and fails to read value if not followed by empty line

Question

[Bug]: Fails to read ini file if line-endings are `CRLF` instead of `LF` and fails to read value if not followed by empty line

Closed this issue 13 days ago · 10 comments

What happened?

I tried to read the following ini as test:

[general]
value=1

but I couldn't get it working - it was telling me no section was detected etc - then I changed the line-ending from CRLF to LF and it started working, partially... I needed to add an empty line after the value to get it to read it.

Expected behavior

Simply said, just work or give a warning about line-endings

How do we reproduct the bug?

Use following content for ini encoded with CRLF:

[general]
value=1

Relevant log output

No response

Screeenshots

No response

Additional information

No response

Code of Conduct

I agree to follow this project's Code of Conduct

Answer 1 · 2024-08-17T12:33:29.000Z

Thank you for raising your first issue - all contributions to this project are welcome!

Answer 2 · 2024-08-17T21:27:06.000Z

What operating system are you using the script on?
What version of bash do you have installed?

I am trying to replicate the issue, but on my MacOS and Debian machines it works as expected.

If you can let me know more about your setup, I can setup something to help test/debug the issue.

Answer 3 · 2024-08-18T13:17:42.000Z

ThaDaVos commented a month ago

Answer 4 · 2024-08-18T13:17:59.000Z

It's inside WSL2 btw

Answer 5 · 2024-08-18T16:21:32.000Z

Ok, the WSL2 part is very useful to know about, Windows historically uses CRLF whereas Unix/Linux uses LF, so that explains the issue you are using, I will see what I can do to replicate that, but I will also take a look for a nice clean generic way to strip CRLF and LF from the lines before processing.

As you may notice from the code I have not done that, but that's because everything worked as expected.

I haven't touched a windows machine since Windows XP :D so it isn't something I test on or develop against if I am honest, but give me a day or 2 and I will see what I can come up with.

Answer 6 · 2024-08-19T09:23:08.000Z

Can I also add a small feature request - that is, ignore empty entries, now it throws an error - for example:

[GENERAL]
VAL1=1
VAL2=2
VAL3=
VAL4=4

This should leave $GENERAL_VAL3 unset

Also you've got support to ignore case sensitivity by lowercasing them - but can it also add an uppercase version? I prefer to keep my global/external variables uppercase

Answer 7 · 2024-08-19T11:43:43.000Z

I will take a look when I get some free time, I have a week off work next week, so should have some time to look into these for you.

Answer 8 · 2024-08-19T12:01:19.000Z

Ok, I have pushed a new version to a branch (based off your name) - if you can help with testing to make sure it does what you need that would really help. This current commit should do the following:

Handle CR+LF correctly (by remove any offending CR)
No longer warn or error when a key has no value.

I will work on the other parts later.

Answer 9 · 2024-08-19T12:39:18.000Z

I have now added the code to handle defaulting to uppercase for keys and sections.

Answer 10 · 2024-09-12T12:35:39.000Z

Code has now been merged into master.