bug#22081: 24.5; netrc.el fails parsing authinfo items spread over multiple lines

[Ted Zlatanov]

On Fri, 04 Dec 2015 14:25:00 +0000 Andy Moreton <andrewjmoreton@gmail.com> 
wrote: 

AM> RFCs describe wire-protocols and interchange data formats, so I would
AM> not expect an RFC for this. The .netrc file format is from BSD UNIX.

For instance, https://tools.ietf.org/html/rfc1035 defines the format of
master zone files, and https://tools.ietf.org/html/rfc4180 defines CSV
files. The closest RFC in spirit is https://tools.ietf.org/html/rfc4155
which defines the mbox format but says

    "The mbox database format is not documented in an
    authoritative specification, but instead exists as a well-known output
    format that is anecdotally documented, or which is only authoritatively
    documented for a specific platform or tool."

Sounds familiar? :) I'm sure we can argue for a while about the nuances
of RFCs, but I hope this is enough to explain why I looked for an RFC.

My more important point was that there's no standard (or library) for
parsing netrc files. In particular, quoting is not specified as I
mentioned. The BSD spec is ambiguous and allowing multi-line entries
would not serve any practical purpose.

I did a quick survey. I first remember using netrc files with ncftp. The
documentation at http://cng.seas.rochester.edu/CNG/docs/man/ncftp.html
shows examples of the "macdef" keyword that make it clear that it just
doesn't make sense across multiple programs:

       machine wuarchive.wustl.edu
                macdef init
                      cd /graphics/gif
                      ls -lt
                (mandatory blank line to end the macro)

Note that quoting is not shown, so it's up to the user to figure it out.

The most used implementation is probably
http://curl.haxx.se/docs/manual.html but they don't specify the syntax
and from looking at their netrc.c don't support "default" or "macdef"
keywords either.

wget just says to consult "your system manuals" but does support
"default" and "macdef" in its netrc.c so it's a bit more compliant.

I hope this was useful to illustrate my original statements.

AM> Support for arbitrary keywords, and omission of the machine token mean
AM> that emacs will parse a .netrc file that other programs reject as
AM> ill-formed. That is unhelpful: either be compatible with other programs
AM> that read .netrc, or define  a new file format with a different name.

Do you have an actual example? Can you be more specific about what broke
and how? Otherwise I think it's OK to leave things as they are.

Ted