Hey.
Ralph Corderoy <[email protected]> wrote:
|>> I think you've broken my password starting with `#'? netrc(5) from
|>> Debian's ftp and ftp-ssl packages don't document a comment
|>> character. The traditional way to comment a .netrc is with `machine
|>> fake-name-as-comment-here'.
|>
|> Sorry! You're right, the fetchmail-based parser works line-wise and
|> only seems to support comments starting at the beginning of the line,
|> after possible whitespace. I'm looking into it.
|
|fetchmail's code doesn't define netrc(5)'s format. It only pokes about
|it for bits of interest, skipping macro definitions, for example. The
|file format does not support comments. That ad hoc parsers have added
|support for them over the years without considering how they're breaking
|existing content is not a reason to expand this mistake.
|
|I've just looked at /usr/share/perl5/core_perl/Net/Netrc.pm here and it
|doesn't support comments. That's not a bug.
|
|Eric Schmidt cooked up ~/.netrc as part of the Berkeley Network, and it
|has no comment character. Neither has MH's ~/.mh_profile, for example,
It's all true what you say, but fetchmail set that standard, other
projects reuse that parser, so what i'm gonna do about it? You're
a poweruser with knowledge that increased over decades, that is
not the norm.
Just see how S-nail bails on their .netrc and they, threatened by
misguided, armed terrorists, socialists and other such minorities
that try to disturb their cozy conception of the world, or short,
spoil their lives, that of the good guys!, and get angry about it.
I really can't take the responsibility for that.
|with an email header called `#' being a convention there, but
|necessitating the syntax
|
| pick: -sequence lp
| #: the header's value
| is the comment
| including normal continuation line rules.
Yeah.., yeah, now this really looks as it should be on-topic in
Bruce Schneier's next Crypto-Gram. I'll thus see it again.
And then see how such illness spreads: Gmane's loom very rarely
(seems to) produce invalid base64 encoded messages (i'll have
a test box with four of them) which break up base64 tuples over
multiple lines, and then use header-continuation rules to mark
that. In a mail part, not header.
|Support it isn't fixing a bug, but extending the reach of one. :-)
Yes. But no: also because it is explicitly documented as
· As a non-portable extension some widely-used programs support shell-
style comments: if an input line starts, after any amount of white‐
space, with a number sign ‘#’, then the rest of the line is ignored.
I would possibly accept patches that extend this text with
something like "Was this help text useful for you? (1) Yes! (2)
Sure! (3) Yay!!"
Get your motor runnin'
P.S.: i currently have some problems regarding localopts and such
because of the major rewrite of the variable handling. Sorry!
--steffen
------------------------------------------------------------------------------
Mobile security can be enabling, not merely restricting. Employees who
bring their own devices (BYOD) to work are irked by the imposition of MDM
restrictions. Mobile Device Manager Plus allows you to control only the
apps on BYO-devices by containerizing them, leaving personal data untouched!
https://ad.doubleclick.net/ddm/clk/304595813;131938128;j
__________________________________
[email protected]
