Hi,

hansbkk AT gmail DOT com wrote on 2011-09-09 20:09:02 +0700 [Re: 
[BackupPC-users] Round-tripping config.pl between hand-coding and the web 
interface]:
> On Fri, Sep 9, 2011 at 7:30 PM, Holger Parplies <wbppc AT parplies DOT de> 
> wrote:
> > A comma at the end of a Perl list without following elements is a *purely
> > cosmetic* thing. If you want one there, fine, put it there.
> 
> If you are addressing me, I wasn't proposing that at all. I believe
> Bowie was simply pointing the fact that it's tolerated as a "more
> valid" workaround (kludge if you prefer) solving the issue I was
> speculating was behind someone using that incorrect syntax.

you misunderstood me there. A comma at the end of a Perl list is fine. No
problem. Perfectly valid. It has no effect, as far as Perl is concerned. I
leave them there too, because it's easier to add list elements later on.
Without the comma, I (and probably many others) have the tendency to forget
adding it when I need it later on. So, for *me*, it has an effect (a positive
one), even though for Perl it doesn't.

The point is that an extraneous empty string ('') is *not* valid. It *has* an
effect, both as far as Perl is concerned and as far as I am. Even if it turns
out to "work" in some places (as far as Perl is concerned) it will always
confuse me if I try to understand the construct, because I have to question
whether it's an obscure workaround for something or a plain mistake. This is
the kludge, not the comma (or rather, it would be, if it would actually work
around something, which it doesn't).

> My intention was simply to post the cause of my problem in the interest of
> helping others. I'm not sure where I got the error-causing snippet, but
> since it's "out there" somewhere, it could cause the same problem for
> someone else.

Ok, I understand your reasoning. It's really very similar to mine, except that
I'm trying to correct something *on this list* which - in my opinion - has
gone wrong *here*. Without the context of the previous thread - which you
deliberately removed (*) (not in the intention of causing trouble, I'm sure,
but, nevertheless, on purpose) - I read your message at the start of this
thread as saying "hey, you can also use an empty value '' at the end of the
list, that will prevent the web interface from removing the comma". Which is
pure nonsense. Read your message again. And try to imagine how someone will
read it who *hasn't* read the long thread, but instead found this one at the
end of a Google search.

And that's the point that really makes me angry. The issue had been resolved
(in the old thread). Now you create a new thread simply to speculate over how
the issue came into existance in the first place - only you forget to mention
that it *is* an issue and not a recommendation. Thus, you create a new
potential issue. I can either waste my time reading the message and then
ignore it, or I can waste more time correcting you.

(*) You might say that you provided the pointer to the long thread. But what
    is the point of the pointer, rather than staying in the thread, if not
    to *discourage* actually reading the context? After all, new thread means
    independant topic.

> Now that you mention it, it "would be nice" if there were an error
> logged with more information as to the cause,

I already answered that. BackupPC cannot tell the cause. This is *one special
case* of a misspellt share name. Or a usage error of the web interface. Maybe
even a bug of the web interface related to the use of unexpected characters in
the share name.

Yes, some error messages could be more specific or list possible common
causes.

> > The *solution* would be to *patch the code* to retain the comma at the end
> > of a list.
> 
> I agree, but wouldn't presume to request such an enhancement myself.

My point wasn't that you should request it. My point was that whoever finds
the matter important enough should provide a patch. That's what I would do,
except that I simply don't *use* the GUI for configuration management, and
it doesn't seem to be in any way important.

> > If you can come up with an implementation that can retain the comments
> > within the block, [...]
> 
> [...] I was simply posting a factual observation, sharing my experience in
> the interest of furthering fellow noob's knowledge, helping them avoid
> making the same mistakes.

Too much documentation is only slightly better than not enough documentation.
I would assume it's mentioned in the documentation somewhere (if not, it
should be added). Posting dozens of minor observations about what can go wrong
is simply going to drown others in irrelevance. To most people, 99.9% don't
apply. Making a Wiki page with a *concise* list of *frequent* issues,
structured and sorted in a way that a new user can actually find a mention of
his problem (and then a link to a solution somewhere), now that would make
sense.
Currently, I can't seem to imagine getting around to doing that, *ever*.

> > I believe, using both the BackupPC web GUI and a text editor to modify your
> > configuration files is not officially supported. You do that at your own
> > risk and shouldn't complain about problems it causes.
> 
> I realize that, and thought my posting details on my precautionary
> procedures would sufficiently demonstrate my awareness of the fact
> that I'm "living on the edge".

Again, if something is *not officially supported*, please refrain from telling
others how it works for you, as long as you don't understand the *basic* issue
why it isn't supported (which is Perl code in the config file). What link
should a new user googling for the matter get: the documentation saying "it's
not supported" or your message "it works for me like this ..."? If you realize
that it's not supported, then *point that out*. If you are targetting readers
that don't know the web interface may delete their comments, you can't assume
they know they shouldn't *have* comments if they are using the web interface.

Oh, and posting elsewhere won't really make the matter any better. At least
here we'll know which misconceptions are "out there" somewhere and what
reports of problems to expect.

Regards,
Holger

------------------------------------------------------------------------------
Why Cloud-Based Security and Archiving Make Sense
Osterman Research conducted this study that outlines how and why cloud
computing security and archiving is rapidly being adopted across the IT 
space for its ease of implementation, lower cost, and increased 
reliability. Learn more. http://www.accelacomm.com/jaw/sfnl/114/51425301/
_______________________________________________
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/