BackupPC-users

Re: [BackupPC-users] Parity (par2) command running on archives even though set to 0

2012-05-31 16:33:06
Subject: Re: [BackupPC-users] Parity (par2) command running on archives even though set to 0
From: "Jeffrey J. Kosowsky" <backuppc AT kosowsky DOT org>
To: "General list for user discussion, questions and support" <backuppc-users AT lists.sourceforge DOT net>
Date: Thu, 31 May 2012 16:31:41 -0400
Timothy J Massey wrote at about 12:05:02 -0400 on Thursday, May 31, 2012:
 > Pascal Mosimann <pascal.mosimann AT alternatique DOT ch> wrote on 05/31/2012 
 > 11:12:54 AM:
 > 
 > >  > Why does BackupPC run the parity command if I've told it not to by 
 > > passing
 > >  > it a 0?  And how do I return to the 3.1 behavior?  According to the
 > >  > documentation, setting it to 0 should disable it, not cause it to run 
 > 
 > > with
 > >  > a parameter of 0...  And if for some reason we would *want* the 
 > > parity to
 > >  > run with a parity of 0, could we have a parameter that disables it? 
 > > Maybe
 > >  > -1?  How do you calculate *negative* parity!  :)
 > > 
 > > Hi Tim,
 > > 
 > > Same situation here: I don't want to run par2. Because the archive is 
 > > done on USB drives and it takes too long.
 > > 
 > > It looks between version 1.16 and 1.17 of BackupPC_archiveHost (see 
 > > http://backuppc.cvs.sourceforge.net/viewvc/backuppc/BackupPC/bin/
 > > BackupPC_archiveHost?r1=1.16&r2=1.17), 
 > > the condition to run par2 has changed on line 157
 > >  From
 > >    ...
 > >    if ( $parfile != 0 ) {
 > >    ...
 > > 
 > > to
 > >    ...
 > >    if ( length($parfile) ) {
 > >    ...
 > > 
 > > I've modified the condition back to "if ( $parfile != 0 )" and now it 
 > > skips the par2 execution.
 > 
 > Thank you for the followup!  I actually changed it to:
 > 
 >  if ( length($parfile) && $parfile != 0 ) {
 > 
 > (and sent a patch to the list that was seemingly ignored).
 > 
 > My perl-fu is not the greatest;  the reason why I changed it to the above 
 > is to be able to handle two conditions:  parfile set to 0, *and* the 
 > parfile parameter unset (which is the default, by the way) or set to an 
 > empty string.  Perl considers unset variables equal to an empty string, 
 > which also is equal to 0 in a comparison, but I don't like depending on 
 > such assumptions.  I'd rather the code be explicit about what it's trying 
 > to accomplish.  Maybe that makes me inelegant.

Well, Perl "purposely" does such casting to simplify the type of test
you are attempting to accomplish since it is often awkward to test if
a variable is defined, empty string or zero, so it's not only legal
but in a sense the right way to do things.

Indeed, your code is in a sense not only *inelegant* but *wrong* since
it will spit out a nasty warning about $parfile being uninitialized if
$parfile is unset and you use the (recommended) '-w' flag, since
neither 'length' nor comparisons are expected to operate on
uninitialized variables. Thus, your code is almost certainly less
preferable to the simpler: 
                   if($parfile) 

I think that most Perl coders would understand and expect the above to
only return true if the variable $parfile is set to a
non-zero/non-empty string value.

 > 
 > Of course, if you want elegant you could use:
 > 
 >  if ( $parfile ) {

Not just elegant but *working* --- your code spits out warnings with
the '-w' flag and it's sloppy programming to write Perl code that
doesn't work with -w flag (indeed, the Perl manpage goes so far as to
say that not making '-w' mandatory is a *bug* in Perl -- i.e., all
Perl code should be written to pass the '-w' (warning) tests).

 > 
 > because Perl will evaulate an undefined value as an empty string, and an 
 > empty string as a false, and a zero as a false.  It's certainly concise...
 > 
 > But like I said, my perl-fu is not the greatest, and I prefer explicit to 
 > implicit.  If this is somehow offensive to the sense of style of Perl 
 > hackers, then so be it.

It's not about explicit/implicit, it's about code that works, is
transportable, and is (relatively) understandable. I think just about
any non-totally novice PERL programmer understands how undefined
variables are evaluated (and when they give errors) -- it's one of the
key benefits of Perl.
 > 
 > And let me know:  I'd truly like to know the "right" way to construct an 
 > if statement that handles a variable that is unset, set to a null string 
 > or set to zero.  Bonus points for avoiding the warning when using
 > -w... 

As above, simpler is actually better code and avoids the -w warnings.
i.e, just use:
         if($parfile)

 > The only way I've been able to handle this in other projects is something 
 > like:
 > 
 > $variable=0 if not defined $variable;
 > if ( $variable != 0 ) {
 > 
Not sure this is necessary and it will give warning if $variable is
non-numeric i.e. a string.

------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
BackupPC-users mailing list
BackupPC-users AT lists.sourceforge DOT net
List:    https://lists.sourceforge.net/lists/listinfo/backuppc-users
Wiki:    http://backuppc.wiki.sourceforge.net
Project: http://backuppc.sourceforge.net/

<Prev in Thread] Current Thread [Next in Thread>