perl-diddler:

I don't see a problem with split. Perhaps P is the problem?

$ cat t.pl
#!/usr/bin/perl
use strict; use warnings;
use Data::Dumper;

my $fmt="prod\t006\t2.13\tx86_64\trpm";
my @flds = split /\t/,$fmt;
print "<",join("|",@flds),">\n";

$ perl t.pl
<prod|006|2.13|x86_64|rpm>
[download]

...roboticus

When your only tool is a hammer, all problems look like your thumb.

P isn't the prob in the actual program, though it might be doing a conversion on the single datum in my examples.

The problem was the line was getting sent across a pipe in line oriented fashion and being reread in.

Had an rpm query:

my @rpmcmd = qw{rpm
  --queryformat=%{N}\t"%{V}"\t"%{R}"\t%7{ARCH}\t%7{SOURCERPM}\t%9{NOSO
+URCE}\n
  -qp };
[download]

That was printed in a child and read in a parent with:

      while (<$pfrs>) {
        $package_p->split_n_cmp_vers($_);
[download]

That split the fields to do compares. It was in splitting them into separate vars and trying to use them that they got converted from string->num before I could isolate it -- if I put it back together immediately into a string and do nothing to the parts, like you have done, that obviously works, but I was trying to compare the parts separately. I guess P was bad for my example as it introduces it's own example of the bug:

 perl -e '#!/usr/bin/perl
use strict; use warnings;use P;
use Data::Dumper;

my $fmt="prod\t006\t2.13\tx86_64\trpm";
my @flds = split /\t/,$fmt;
printf "%s, %s", $flds[1],"<".join("|",@flds).">\n";
P "%s, %s", $flds[1],"<".join("|",@flds).">\n";
'
006, <prod|006|2.13|x86_64|rpm>
6, <prod|006|2.13|x86_64|rpm>
[download]

But since the original code was trying to compare the parts, it ended up with a similar problem -- might be able to figure a better way around it than what I ended up with... since looking at the printf -- it doesn't force a convert -- not sure why it doesn't and P does, but if I figure that out, I might be able to stop it from happening in the compare code.

P wasn't used in the main dataflow of the other prog, as it was performance sensitive -- it was used in error messages and debug messages.

My ugly solution...I kept the quotes in until it converted it from individual parts back into a string:

  sub rec2rpm_name () {
    my $p    = shift;
    my ($n, $v, $r, $arch) = ($p->N, $p->V, $p->R, $p->arch);
    chomp $arch;
    my $q = P "%s-%s-%s.%s.rpm", $n, $v, $r, $arch;
    $q=~s/-"(\S+)"-"(\S+)"/-$1-$2/;
    $q;
  }
[download]

It's a utility I rarely run...but I tried it yesterday, as I wanted to measure the timing difference between using 1 proc vs. multiple (default was 75%#CPU) and noticed the problem... previous 'testbase' had no version #'s with leading zero's ... yippee! Now it does...better yippee...

(FWIW, perf diffs of 1 vs. 9 procs:
hot-cache: the 9 procs saved 42% over the 1
cold-cache: the 9 procs saved 55% over the single cpu case)...

Now to go see if I can fix P w/strings w/o turning it inside out. ;-<
(hey, it can print to a string from an array or to output w/o batting an eyelash, and no extra LF's, unlike printf sprintf).

The problem in 'P' was introduced a few days ago in 1.0.9 when I tried to pretty up some formatting. I was mainly trying to curtail the verbose output of floating point numbers in structures

 perl -e 'my @a=(1/3, 1/4, 1/5, 1/6, 1/7);
print "[".join(", ",@a)."]\n"'
[0.333333333333333, 0.25, 0.2, 0.166666666666667, 0.142857142857143]
-----------
vs.
--------------
> perl -e 'use P;my @a=(1/3, 1/4, 1/5, 1/6, 1/7);
P "%s", \@a;'
[0.33, 0.25, 0.20, 0.17, 0.14]
[download]

Not as numerically accurate, but when doing dev/debug, easier on the eyes. I hoped it wasn't due to undef detection, but it had nothing to do w/that:

> perl -e 'use P;my @a=(1/3, 1/4, $x, 1/6, 1/7);     
P "%s", \@a;'   
[0.33, 0.25, (undef), 0.17, 0.14]
[download]

As usual, thanks pointing me in the right direction!

Pe "%s \x83", "$_";
[download]

%03d
[download]