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
MIME-Version: 1.0
X-Mailer: MIME-tools 5.426 (Entity 5.426)
Content-Type: text/plain
Charset: utf8
Content-Disposition: inline
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 357
Download (untitled) / with headers
text/plain 357b
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.
MIME-Version: 1.0
X-Mailer: MIME-tools 5.427 (Entity 5.427)
Content-Disposition: inline
Charset: utf8
Content-Type: text/plain
Message-ID: <rt-3.6.HEAD-19694-1229525616-1361.39814-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
Content-Length: 123
Download (untitled) / with headers
text/plain 123b
sorry for the delay. In line 539 (version 2.40) there is already a chomp(). The chop() in line 591 removes the trailing \.
MIME-Version: 1.0
In-Reply-To: <rt-3.6.HEAD-19694-1229525616-1361.39814-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <rt-3.6.HEAD-19694-1229525616-1361.39814-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-24783-1398862716-1545.39814-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 713
Download (untitled) / with headers
text/plain 713b
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...
X-Cloudmark-SP-Result: v=1.1 cv=Q6PcBmOJ9kS68hT6SaCMS3KQyTJLj6a+qRtQkqoKfyo= c=1 sm=2 a=QLN-vfoJgdQA:10 a=AC4b6R8PCdgA:10 a=IkcTkHD0fZMA:10 a=potJGypnAAAA:8 a=1Nxo0klZ813_AywLwWEA:9 a=QEXdDO2ut3YA:10 a=lL10QPni67sA:10
MIME-Version: 1.0
X-Spam-Status: No, score=-2.273 tagged_above=-99.9 required=10 tests=[BAYES_40=-0.001, FROM_OUR_RT=-2, RCVD_IN_DNSWL_NONE=-0.0001, RP_MATCHES_RCVD=-0.272] autolearn=ham
X-Mailer: Microsoft Outlook Express 6.00.2900.5931
X-Cloudmark-SP-Filtered: true
X-Spam-Flag: NO
X-RT-Interface: API
References: <RT-Ticket-39814 [...] rt.cpan.org> <rt-3.6.HEAD-19694-1229525616-1361.39814-6-0 [...] rt.cpan.org> <rt-4.0.18-24783-1398862717-950.39814-6-0 [...] rt.cpan.org>
X-Virus-Scanned: Debian amavisd-new at bestpractical.com
Message-ID: <A5BB9ECE45564736A0837FD7EE3365D5 [...] PeterLaptop>
Reply-To: "Peter Jaquiery" <peter.jaquiery [...] ihug.co.nz>
content-type: text/plain; charset="utf-8"; format="flowed"; reply-type="original"
X-RT-Original-Encoding: utf-8
X-Spam-Score: -2.273
X-Ironport-Av: E=Sophos;i="4.97,960,1389697200"; d="scan'208";a="118999182"
Received: from localhost (localhost [127.0.0.1]) by hipster.bestpractical.com (Postfix) with ESMTP id 7B744240026 for <cpan-bug+Config-General [...] hipster.bestpractical.com>; Wed, 30 Apr 2014 18:13:20 -0400 (EDT)
Received: from hipster.bestpractical.com ([127.0.0.1]) by localhost (hipster.bestpractical.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id M9j3MiFFZjus for <cpan-bug+Config-General [...] hipster.bestpractical.com>; Wed, 30 Apr 2014 18:13:16 -0400 (EDT)
Received: from la.mx.develooper.com (x1.develooper.com [207.171.7.70]) by hipster.bestpractical.com (Postfix) with SMTP id 23988240003 for <bug-Config-General [...] rt.cpan.org>; Wed, 30 Apr 2014 18:13:15 -0400 (EDT)
Received: (qmail 20570 invoked by alias); 30 Apr 2014 22:13:13 -0000
Received: from mailfilter13.ihug.co.nz (HELO mailfilter13.ihug.co.nz) (203.109.136.13) by la.mx.develooper.com (qpsmtpd/0.28) with ESMTP; Wed, 30 Apr 2014 15:13:10 -0700
Received: from 118-92-70-229.dsl.dyn.ihug.co.nz (HELO PeterLaptop) ([118.92.70.229]) by cust.filter4.content.vf.net.nz with SMTP; 01 May 2014 10:12:52 +1200
Delivered-To: cpan-bug+Config-General [...] hipster.bestpractical.com
Subject: Re: [rt.cpan.org #39814] chop instead of chomp causes continuation line bug
Return-Path: <peter.jaquiery [...] ihug.co.nz>
X-Msmail-Priority: Normal
X-Spam-Check-BY: la.mx.develooper.com
X-Original-To: cpan-bug+Config-General [...] hipster.bestpractical.com
X-RT-Mail-Extension: config-general
X-Priority: 3
Date: Thu, 1 May 2014 10:12:53 +1200
X-Spam-Level:
X-Mimeole: Produced By Microsoft MimeOLE V6.00.2900.6157
To: <bug-Config-General [...] rt.cpan.org>
Content-Transfer-Encoding: 7bit
From: "Peter Jaquiery" <peter.jaquiery [...] ihug.co.nz>
RT-Message-ID: <rt-4.0.18-25586-1398896001-516.39814-0-0 [...] rt.cpan.org>
Content-Length: 1201
Download (untitled) / with headers
text/plain 1.1k
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
MIME-Version: 1.0
In-Reply-To: <rt-4.0.18-25586-1398896001-516.39814-0-0 [...] rt.cpan.org>
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
References: <RT-Ticket-39814 [...] rt.cpan.org> <rt-3.6.HEAD-19694-1229525616-1361.39814-6-0 [...] rt.cpan.org> <rt-4.0.18-24783-1398862717-950.39814-6-0 [...] rt.cpan.org> <A5BB9ECE45564736A0837FD7EE3365D5 [...] PeterLaptop> <rt-4.0.18-25586-1398896001-516.39814-0-0 [...] rt.cpan.org>
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-3975-1398939285-1164.39814-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 772
Download (untitled) / with headers
text/plain 772b
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
MIME-Version: 1.0
X-Mailer: MIME-tools 5.504 (Entity 5.504)
Content-Disposition: inline
X-RT-Interface: Web
Content-Type: text/plain; charset="utf-8"
Message-ID: <rt-4.0.18-3975-1398943487-1952.39814-0-0 [...] rt.cpan.org>
Content-Transfer-Encoding: binary
X-RT-Original-Encoding: utf-8
X-RT-Encrypt: 0
X-RT-Sign: 0
Content-Length: 316
Download (untitled) / with headers
text/plain 316b
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


This service is sponsored and maintained by Best Practical Solutions and runs on Perl.org infrastructure.

Please report any issues with rt.cpan.org to rt-cpan-admin@bestpractical.com.