Skip Menu |
 

This queue is for tickets about the File-Slurp CPAN distribution.

Report information
The Basics
Id: 103986
Status: resolved
Priority: 0/
Queue: File-Slurp

People
Owner: cwhitener [...] gmail.com
Requestors: ROBINS [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Critical
Broken in: (no value)
Fixed in: (no value)



Subject: JSON::PP is unable to decode JSON with newlines between tokens
Download (untitled) / with headers
text/plain 589b
The file pretty.json below does not parse, but compact.json parses. This is tested on both perl 5.18.2 and perl 5.20.2 on Ubuntu 14.04 (64-bit). The 5.18.2 perl version is system perl. 5.20.2 is perlbrewed with --thread --multi arguments. $ cat pretty.json { "a":"b", "c":1 } $ cat compact.json {"a":"b","c":1} $ perl -MFile::Slurp -MJSON::PP -E 'say decode_json read_file shift' compact.json HASH(0xa06d18) $ perl -MFile::Slurp -MJSON::PP -E 'say decode_json read_file shift' pretty.json , or } expected while parsing object/hash, at character offset 1 (before "\n") at -e line 1. $
Download (untitled) / with headers
text/plain 198b
It seems this is actually a bug with File::Slurp. $ perl -MIO::All -MJSON::PP -E 'say decode_json io->file(shift)->all' pretty.json HASH(0x10b2350) Can someone move it over to File::Slurp's queue?
Download (untitled) / with headers
text/plain 394b
Actually, adding in an explicit "scalar" before read_file solves the problem. The question is: Has JSON::PP's decode_json() ever had a prototype to enforce scalar context? Because if you have JSON::XS installed you don't need the "scalar". It seems it JSON::XS::decode_json has a prototype to enforce scalar context. This is confusing... Maybe it it is a bug belonging to JSON::PP after all...
Subject: Re: [rt.cpan.org #103986] JSON::PP is unable to decode JSON with newlines between tokens
Date: Sun, 26 Apr 2015 14:46:04 -0400
To: bug-File-Slurp [...] rt.cpan.org
From: Uri Guttman <uri [...] stemsystems.com>
Download (untitled) / with headers
text/plain 686b
On 04/26/2015 02:23 PM, Robin Smidsrød via RT wrote: Show quoted text
> Queue: File-Slurp > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=103986 > > > Actually, adding in an explicit "scalar" before read_file solves the problem. The question is: Has JSON::PP's decode_json() ever had a prototype to enforce scalar context? Because if you have JSON::XS installed you don't need the "scalar". It seems it JSON::XS::decode_json has a prototype to enforce scalar context. > > This is confusing... Maybe it it is a bug belonging to JSON::PP after all...
it is absolutely a bug in json::pp. read_file has a well defined and stable api with regard to scalar vs list context. thanx, uri
Download (untitled) / with headers
text/plain 522b
On 2015-04-26 14:23:57, ROBINS wrote: Show quoted text
> Actually, adding in an explicit "scalar" before read_file solves the > problem. The question is: Has JSON::PP's decode_json() ever had a > prototype to enforce scalar context? Because if you have JSON::XS > installed you don't need the "scalar". It seems it > JSON::XS::decode_json has a prototype to enforce scalar context.
See here: https://metacpan.org/source/MLEHMANN/JSON-XS-3.01/XS.xs#L2201 Show quoted text
> This is confusing... Maybe it it is a bug belonging to JSON::PP after > all...
Download (untitled) / with headers
text/plain 369b
The problem is with how the file is loaded from disk, in its handling of utf8-encoded characters. Basically, if there is any UTF-8 *anywhere* in the document, the entire file is decoded to characters and utf8-flagged, and that breaks uses of substr() in perl 5.8.6 and below. It is a mistake to try to infer the encoding of the document by inspecting its contents.
Download (untitled) / with headers
text/plain 599b
On 2015-05-21 23:37:41, ETHER wrote: Show quoted text
> The problem is with how the file is loaded from disk, in its handling > of utf8-encoded characters. > > Basically, if there is any UTF-8 *anywhere* in the document, the > entire file is decoded to characters and utf8-flagged, and that breaks > uses of substr() in perl 5.8.6 and below. > > It is a mistake to try to infer the encoding of the document by > inspecting its contents.
Sorry, this was a response to the wrong ticket (which has the same error result -- I was describing the issue that was fixed here -- https://github.com/makamaka/JSON-PP/pull/9)
Download (untitled) / with headers
text/plain 960b
On Sun Apr 26 14:46:19 2015, uri@stemsystems.com wrote: Show quoted text
> On 04/26/2015 02:23 PM, Robin Smidsrød via RT wrote:
> > Queue: File-Slurp > > Ticket <URL: https://rt.cpan.org/Ticket/Display.html?id=103986 > > > > > Actually, adding in an explicit "scalar" before read_file solves the > > problem. The question is: Has JSON::PP's decode_json() ever had a > > prototype to enforce scalar context? Because if you have JSON::XS > > installed you don't need the "scalar". It seems it > > JSON::XS::decode_json has a prototype to enforce scalar context. > > > > This is confusing... Maybe it it is a bug belonging to JSON::PP after > > all...
> it is absolutely a bug in json::pp. read_file has a well defined and > stable api with regard to scalar vs list context. > > thanx, > > uri
I concur. ##### $ cat pretty.json { "a":"b", "c":1 } $ perl -MFile::Slurp -MJSON::PP -E 'my $str = read_file shift; chomp $str; say $str' pretty.json { "a":"b", "c":1 } #####
Download (untitled) / with headers
text/plain 654b
Hi Everyone, Since `read_file` uses wantarray to detect context, it returns @lines in list context or $text in scalar context. You can't simply embed the function call in another function because that assumes list context. The function `decode_json` accepts a byte string, not a list of byte strings. I don't think we can do anything about this, as Uri said, the interface for `read_file` has long been defined and thus cannot easily be altered for use in this manner. I'm going to close this ticket out as the appropriate means to accomplish the goal is to make the call to `read_file` in scalar context before calling `decode_json`. Thanks, Chase


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.