On Fri, May 22, 2015 at 8:12 AM, Allen Hubbe <allenbh@xxxxxxxxx> wrote:
> On Fri, May 22, 2015 at 12:29 AM, Eric Sunshine <sunshine@xxxxxxxxxxxxxx> wrote:
>> On Thu, May 21, 2015 at 11:40 PM, Allen Hubbe <allenbh@xxxxxxxxx> wrote:
>>> +If the format is 'simple', then the alias file format is described below.
>>> +Descriptions of the other file formats to the following formats can be found in
>>> +the documentation of the email program of the same name.
>>
>> The second sentence probably needs some proof-reading.
>
> Could you be more specific?
Unable to parse "of the other file formats to the following formats".
I'm guessing that the "to the following formats" portion doesn't
belong.
> It depends what we want to do with this parser: accept existing
> sendmail aliases files in git, or enforce that git alias files are
> usable for sendmail.
Aside from these possibilities (likely or unlikely), there is also the
issue of breaking expectations. Precedence for this style 'aliases'
format was set decades ago by sendmail. People are familiar with it
and understand its strengths and weaknesses. Even if documented as not
being sendmail-compatible, because it's so similar to sendmail
'aliases', people will expect it to work the same way, thus unless
there's a good reason to diverge from that standard format, it makes
sense to be compatible with it (even if only as a proper subset).
> I really don't expect the second to ever happen.
> The first, maybe, but only if the alias file is edited to remove
> aliases of pipes and maildirs etc. The second may not work if we have
> comments to the right, or aliases of aliases, which sendmail does not
> claim to support.
It's not clear why you say that sendmail does not claim to support
aliases of aliases. Although it's true that some sources, such as [1],
fail to mention support explicitly, other more authoritative sources
do[2]. Moreover, the 1993 "sendmail" book by Bryan Costales, with
contributions from Eric Allman (the creator of sendmail), talks
explicitly about expansion of aliases on the right-hand-side. Finally,
since time immemorial (at least the early 1980's), every /etc/aliases
file has contained the following mandatory entries:
postmaster: root
MAILER-DAEMON: postmaster
which indicates clearly that alias expansion on the RHS is supported.
[1]: http://www.feep.net/sendmail/tutorial/intro/aliases.html
[2]: https://www.freebsd.org/cgi/man.cgi?query=aliases&sektion=5
> I don't know what sendmail would actually do with a '#' elsewhere. It
> only talks about having '#' at the beginning of a line, or in the
> alias name in quotes (which is not supported by this parser - proper
> handling of quoted strings is not easy). It doesn't say what sendmail
> does with '#' if the name is not quoted, and it doesn't define a
> meaning for '#' in the definition of an alias. If these other cases
> would be errors for sendmail, so what if they are not errors here?
All the more reason to stick with the documented standard. When you
diverge from it, you paint the format into a corner, thus closing the
door on someone who wants to bring it more in line with the standard.
>> For the same reason, I'm not convinced that "simple" is a good name.
>> "sendmail" may indeed be a more appropriate name, even if it means
>> that this early implementation documents it as (currently) a subset of
>> the richer sendmail/postfix 'aliases' format. By doing so, we leave
>> the door open so a future person can implement additional features to
>> bring it closer to that format.
>
> Or, a future person can write a sendmail parser that is closer to that format.
Yes, but git maintainers must continue to support your "simple" format
even if someone comes along later and adds a more proper sendmail-like
format alongside. That's why these questions and observations are
being raised now: not to string you along and not because your
proposal is necessarily undesirable, but because once such support
lands in git, then it remains indefinitely and must be supported for
the life of the project. Long-term project health is important, which
is why it's desirable to consider these issues early, and to avoid
painting ourselves into a corner.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html