My interpretation is that Dumper is dumping you a string that was produced from the stringization of a hash reference. Note the single-quotes surrounding the body of the dumped output and the embedded newline.

Win8 Strawberry 5.8.9.5 (32)  Fri 05/07/2021 19:46:25
C:\@Work\Perl\monks
>perl -Mwarnings

use Data::Dumper;

my $hr = { qw(one uno  two dos) };

my $request = "$hr\n"; # stringize a hash ref, end in newline

print Dumper $request;
print Dumper %$request;

^Z
$VAR1 = 'HASH(0x333824)
';
[download]

As to the

print Dumper %$request;

$VAR1 = '4/8
';
[download]

Win8 Strawberry 5.8.9.5 (32)  Fri 05/07/2021 20:03:42
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings

use Data::Dumper;

my $hr = { qw(one uno  two dos) };

my $bins = '' . %$hr;

print Dumper $bins;

^Z
$VAR1 = '2/8';
[download]

Win8 Strawberry 5.8.9.5 (32)  Fri 05/07/2021 20:15:42
C:\@Work\Perl\monks
>perl -Mstrict -Mwarnings

my %hash = qw(one uno  two dos);

print '' . %hash;

^Z
2/8
[download]

G'day AnomalousMonk,

"Note that details of this behavior changed somewhere between versions 5.8 and 5.30.)"

I suspect that's 5.26.0: "perl5260delta: scalar(%hash) return signature changed". I don't have a pre-5.26 version handy to test that.

However, there's other things probably going on prior to the code shown in the OP:

• Why is there a newline appended to the hashref? I'd guess there's some sort of suspect code near where that happens.
• Lack of strict as you already noted.
• Other things we can't see any code for.

I'm able to test this much (on 5.32.0):

# The sort of result that was no doubt expected:
$ perl -e 'use Data::Dumper; my $hr = bless {a=>1}, "H::R"; my $r = $h
+r; print Dumper $r'
$VAR1 = bless( {
                 'a' => 1
               }, 'H::R' );

# Reproduce output with stringification and embedded newline:
$ perl -e 'use Data::Dumper; my $hr = bless {a=>1}, "H::R"; my $r = "$
+hr\n"; print Dumper $r'
$VAR1 = 'H::R=HASH(0x800003b78)
';

# No bucket allocation ratio for me; also no strict to advise of probl
+em:
$ perl -e 'use Data::Dumper; my $hr = bless {a=>1}, "H::R"; my $r = "$
+hr\n"; print Dumper %$r'

# Problem advice when strict is used:
$ perl -e 'use strict; use Data::Dumper; my $hr = bless {a=>1}, "H::R"
+; my $r = "$hr\n"; print Dumper %$r'
Can't use string ("H::R=HASH(0x800003b78)
") as a HASH ref while "strict refs" in use at -e line 1.
[download]

Bod, address the dot points above: there may be a solution in there. If that solves nothing, provide more code. Also, what Perl version are you using? (I seem to recall you had different versions on your local machine and your hosted server.)

— Ken

address the dot points above: there may be a solution in there

Yes - sorry guys...I was doing something very silly
See Re^2: Data::Dumper output

To answer the version question, I am using v5.16.3. I do have 5.32 locally but this is being written and tested on the webserver as that's where the code will ultimately run and I cannot see the Perl version changing anytime soon.

Update: So I'd say that the unkosher '(' comes from the opening paren in 'HTTP::Request=HASH(0x1c23960)'

You were spot on with the stringification causing the problem. I was trying to put some whitespace between the various Dumper outputs so wrote a rather stupid line of code:

print Dumper %$request . "\n";
[download]

Culprit found!!! Sorry for the senior moment!

I think you are right about the source of the opening parenthesis. But I am using an existing module, LWP::Authen::OAuth2 that works. I am only adding a Dumper statement to it to try and understand what it needs that I am not giving it. It should take a hashref. This is the code I am using to call it:

open my $fh, '<', "linkedin.json";
my $json;
{
    local $/;
    $json = <$fh>;
}
close $fh;

$params = decode_json($json);

my $header = {
    'X-Restli-Protocol-Version:' => '2.0.0',
};

print Dumper $params;
print "\n\n============\n\n";
my $res = $linkedin->post('https://api.linkedin.com/v2/ugcPosts', $par
+ams, $header);
if ($res) {
    print Dumper $res;
    exit 0;
}
[download]

There is an external JSON file so that I can use exactly the example given in the LinkedIn API documentation without introducing data structure errors. The only thing that's changed from that example is the person:id value.

I'm beginning to think that the LinkedIn API is sufficiently recalcitrant to warrant writing a module from scratch for posting to it. Just use the LWP::Authen::OAuth2::ServiceProvider subclass for authentication and not for posting.

Short reply from my mobile...I will reply more fully when I get to a proper keyboard...

Both strict and warnings are enabled. The Dumper line is added to the existing code of the OAuth2 module as suggested on another node. I've checked that the module has strict and warnings turned on. So it is strange that the dereference isn't throwing an error or warning.

I'm using Perl 5.16.3

... the module has strict and warnings turned on. So it is strange that the dereference isn't throwing an error or warning.

strict and warnings both support lexical scoping, so it's possible that strict has been locally disabled.

(And it's good to know the version of Perl you're using! :)

---

Give a man a fish:  <%-{-{-{-<

Your $request is not what you think (or hope) it to be. Here is a trivial demo:

#!/usr/bin/env perl 
use strict;
use warnings;
use HTTP::Request;
use Data::Dumper;

my $request = HTTP::Request->new;
print "Object:\n", Dumper $request;
print "Hash:\n", Dumper %$request;
[download]

This will produce (versions depending) something like:

Object:
$VAR1 = bless( {
                 '_uri' => undef,
                 '_content' => '',
                 '_headers' => bless( {}, 'HTTP::Headers' ),
                 '_method' => undef
               }, 'HTTP::Request' );
Hash:
$VAR1 = '_uri';
$VAR2 = undef;
$VAR3 = '_content';
$VAR4 = '';
$VAR5 = '_headers';
$VAR6 = bless( {}, 'HTTP::Headers' );
$VAR7 = '_method';
$VAR8 = undef;
[download]

It is therefore highly probable as everyone else has surmised that you have accidentally stringified $request at some point in the code you have not shown. The Basic Debugging Checklist may help you to pinpoint where that happens.

It is therefore highly probable as everyone else has surmised that you have accidentally stringified $request at some point in the code you have not shown.

Stupid, Stupid, Stupid me!!!

I was trying to print with:

print Dumper %$request . "\n";
[download]

Removing the concatenated return character gives...

$VAR1 = '_content';
$VAR2 = 'visibility=HASH(0x26db708)&specificContent=HASH(0x26c2398)&li
+fecycleState=PUBLISHED&author=urn%3Ali%3Aperson%3AGKiAGefMOA';
$VAR3 = '_uri';
$VAR4 = bless( do{\(my $o = 'https://api.linkedin.com/v2/ugcPosts')}, 
+'URI::https' );
$VAR5 = '_headers';
$VAR6 = bless( {
                 'content-type' => 'application/x-www-form-urlencoded'
+,
                 'content-length' => 121,
                 'hash(0x26db3a8)' => undef,
                 '::std_case' => {
                                   'hash(0x26db3a8)' => 'HASH(0x26db3a
+8)'
                                 }
               }, 'HTTP::Headers' );
$VAR7 = '_method';
$VAR8 = 'POST';
[download]

Sorry for having a senior moment...

It is therefore highly probable as everyone else has surmised that you have accidentally stringified $request at some point in the code you have not shown.

...

I was trying to print with:

print Dumper %$request . "\n";
[download]

Removing the concatenated return character gives...

...

To continue to use \n, use a list with print ...

# Need to use "Dumper()" else "\n" will be swallowed by "Dumper ... ;"
+ 
print Dumper( ... ), qq[\n];
[download]

G'day Bod,

I provided some suggestions earlier.

On reviewing "Subs calling themselves", I see that ++roboticus posted some code that included Data::Dumper and $request.

If your current problem stems from implementing that suggestion, I'd look for typos there. It could be as simple as a '.' instead of a ',' in a list; e.g. you've concatenated a newline to another value in the list, rather than adding it separately to the list.