Skip Menu |

This queue is for tickets about the Config-General CPAN distribution.

Report information
The Basics
Id: 39814
Status: resolved
Priority: 0/
Queue: Config-General

People
Owner: Nobody in particular
Requestors: grandpa [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Important
Broken in: 2.53
Fixed in: (no value)



Subject: chop instead of chomp causes continuation line bug
If a configuration file containing Windows line ends (CRLF) uses a trailing \ as a continuation character the chop in line 591 of version 2.38 of General.pm removes the CR but leaves the LF causing incorrect parsing of the configuration. Changing the chop to a chomp will allow correct operation with configuration files using the OS's native line endings.
sorry for the delay. In line 539 (version 2.40) there is already a chomp(). The chop() in line 591 removes the trailing \.
short update (after 6 years, haha): had I known, that the underlying issue of this report was http://www.perlmonks.org/index.pl?node_id=715307, then I had better answered like so: Empty lines in C::G are ignored. Thus, if a config contains this: foo = 1\ bar = 2 then the parser would first remove empty lines, which results in: foo = 1\ bar = 2 Since there's a continuation, it would result after parsing in: 'bar' => '1bar = 2' So, the real "error" in the perlmonk question is that the last line of continuation must not contain a \. While this might be valid Makefile syntax (didn't test), it's not valid for C::G configs. Maybe I could change this, but such a problem never occurred since then. So...
Subject: Re: [rt.cpan.org #39814] chop instead of chomp causes continuation line bug
Date: Thu, 1 May 2014 10:12:53 +1200
To: <bug-Config-General [...] rt.cpan.org>
From: "Peter Jaquiery" <peter.jaquiery [...] ihug.co.nz>
Hi, Show quoted text
> short update (after 6 years, haha)
yep, that's a pretty amazing "follow up" time :-D. Show quoted text
> had I known, that the underlying issue of this report was > http://www.perlmonks.org/index.pl?node_id=715307, then I had better > answered like so: ...
Show quoted text
> So, the real "error" in the perlmonk question is that the last line of > continuation must not contain a \. While this might be valid Makefile > syntax (didn't test), it's not valid for C::G configs.
Looking over the history of the bug I could have given a much better bug report and including a link to the Perlmonks node would have been smart! Show quoted text
> Maybe I could change this, but such a problem never occurred since then. > So...
There is a difference between "never occurred" and "hasn't been reported". It's sufficiently long ago that I raised the issue that I don't remember exactly what problem I was trying to solve, although I feel a vague echo of the pain felt while trying to figure out the problem. Saving someone else that pain would be good thing to do if you have time. At least a description of continuation character processing rolled into the POD for the next release of the module could be a heads up. Cheers, Peter
Well, actually, you're right. But hey, at least I tried :) Ok, the underlying cause of this is, how I parse files. I do it in 2 stages. In stage 1 I remove comments, empty lines and pull in includes. In stage 3 actual option parsing happens. Both stages work independently from each other, so the 2nd stage doesn't know what the 1st did. Therefore, since in the 1st stage the empty line following the line with the continuation marker have been removed, it looks for the 2nd stage as if the next non-empty line following it shall be appended to the line before. This is the fault. So, in order to fix this, I'd need to modify the 1st stage parser and handle line continuations there. Then the issue would be fixed. I'll look into it during the next days. regards, Tom
Now that was easy :) In fact I already did the continuation handling in the 1st stage (_read()). I just had to move the line in which I remove empty lines a little bit further down (just after continuation concatenation). That's it. I also added a unit test for it, just in case. Fixed in 2.54. best regards, Tom