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)

History Show all quoted text
  Sun Apr 26 13:23:20 2015 ROBINS [...] cpan.org - Ticket created
Subject: JSON::PP is unable to decode JSON with newlines between tokens
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. $
  Sun Apr 26 13:35:50 2015 ROBINS [...] cpan.org - Correspondence added
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?
  Sun Apr 26 13:48:35 2015 ether [...] cpan.org - Queue changed from JSON-PP to File-Slurp
  Sun Apr 26 14:23:57 2015 ROBINS [...] cpan.org - Correspondence added
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...
  Sun Apr 26 14:46:19 2015 uri [...] stemsystems.com - Correspondence added
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>
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
  Sun Apr 26 14:46:20 2015 The RT System itself - Status changed from 'new' to 'open'
  Mon Apr 27 14:21:29 2015 SREZIC [...] cpan.org - Correspondence added
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...
  Fri May 22 02:37:41 2015 ether [...] cpan.org - Correspondence added
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.
  Fri May 22 02:38:59 2015 ether [...] cpan.org - Correspondence added
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)
  Wed Oct 10 12:08:46 2018 jkeenan [...] cpan.org - Correspondence added
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 } #####
  Wed Oct 10 13:58:35 2018 cwhitener [...] gmail.com - Taken
  Wed Oct 10 14:05:10 2018 cwhitener [...] gmail.com - Correspondence added
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
  Wed Oct 10 14:06:02 2018 cwhitener [...] gmail.com - Status changed from 'open' to 'resolved'