in reply to Re: is split suppose to drop 0's from strings?
in thread is split suppose to drop 0's from strings?

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 };
That was printed in a child and read in a parent with:
while (<$pfrs>) { $package_p->split_n_cmp_vers($_);
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>
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; }
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).

Replies are listed 'Best First'.
Re^3: is split suppose to drop 0's from strings?
by perl-diddler (Chaplain) on Mar 06, 2013 at 03:08 UTC
    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]
    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]
    As usual, thanks pointing me in the right direction!