Git development
 help / color / mirror / Atom feed
* [RFC] send-email quote issues
       [not found] <387683965.505610.1434366660032.JavaMail.zimbra@ensimag.grenoble-inp.fr>
@ 2015-06-15 11:16 ` Remi Lespinet
  2015-06-15 11:32   ` Matthieu Moy
  0 siblings, 1 reply; 5+ messages in thread
From: Remi Lespinet @ 2015-06-15 11:16 UTC (permalink / raw)
  To: git
  Cc: Remi Galan, Antoine Delaite, Louis-Alexandre Stuber, Matthieu Moy,
	Guillaume Pages

Hi,

I'm currently working on git send-email to allow passing names
containing commas. I would like to specify that the comma
shouldn't be interpreted as a delimiter when there's quotes
around:

  "Jane, Katarina Doe" <jdoe@example.com>

This changes the behavior of the double quote. For example
when passing:

  --to='"Jane" Doe <jdoe@example.com>'

to git send-email, the line produced was:

  To: "\"Jane\" Doe" <jdoe@example.com>

With this modification, it would be:

  To: Jane Doe <jdoe@example.com>
    or
  To: "Jane Doe" <jdoe@example.com>

And this will not be possible to use quote in a name anymore.
Is this a problem ?

Currently, git send-email contains a function which splits at commas
with respect to quotes (parse_address_line introduced by
5012699d9840fe34fe0838ea0d529c2f32f76b82). It is used to parse user
input when there's no recipient specified. I would like to use this
function to parse --to, --cc and --bcc options, but the execution of
this function depends on whether the user has the Perl library
Mail::Address or not. This introduce a change in the behaviour:

Output1 represents lines produced with the Mail::Address library
Output2 represents lines produced without the Mail::Address library

 1) Simple quote are not interpreted the same way:

   Input : 'Doe, "Jane' <jdoe@example.com>
      Output1 : 'Doe,
                "\" Jane'" <jdoe@example.com>
      Output2 : "'Doe, \"Jane'" <jdoe@example.com>

   Input : 'Jane 'Doe' <jdoe@example.com>
      Output1 : 'Jane 'Doe' <jdoe@example.com>
      Output2 : ERROR

 2) Mail::Address adds a space when using a quote or a backslash in a name

   Input : "Jane Do"e <jdoe@example.com>
      Output1 : "\"Jane Do\" e" <jdoe@example.com>
      Output2 : "\"Jane Do\"e" <jdoe@example.com>

   Input : \Jane Doe <jdoe@example.com>
      Output1 : "\ Jane Doe" <jdoe@example.com>
      Output2 : "\Jane Doe" <jdoe@example.com>

 3) Mail::Address works when quote is not closed

   Input : "Jane Doe <jdoe@example.com>
      Output1 : "\" Jane Doe" <jdoe@example.com>
      Output2 : ERROR

 4) Mail::Address splits the string when there's no comma

   Input : Jane "Doe <jdoe@example.com>"
      Output1 : Jane,
   	"\"Doe" <jdoe@example.com>
      Output2 : "Jane \"Doe" <jdoe@example.com>

The following doesn't work for both:

   Input : "Jane Doe <jdoe@example.com>" <jdoe@example.com>
      Output1 : ERROR
      Output2 : ERROR

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] send-email quote issues
  2015-06-15 11:16 ` [RFC] send-email quote issues Remi Lespinet
@ 2015-06-15 11:32   ` Matthieu Moy
  2015-06-15 13:03     ` Remi Lespinet
  0 siblings, 1 reply; 5+ messages in thread
From: Matthieu Moy @ 2015-06-15 11:32 UTC (permalink / raw)
  To: Remi Lespinet
  Cc: git, Remi Galan, Antoine Delaite, Louis-Alexandre Stuber,
	Guillaume Pages

Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> writes:

> Currently, git send-email contains a function which splits at commas
> with respect to quotes (parse_address_line introduced by
> 5012699d9840fe34fe0838ea0d529c2f32f76b82).

It seems I had missed this one, but indeed, it should probably be used
instead of split_at_commas in your series.

> It is used to parse user input when there's no recipient specified. I
> would like to use this function to parse --to, --cc and --bcc options,
> but the execution of this function depends on whether the user has the
> Perl library Mail::Address or not. This introduce a change in the
> behaviour:

I would say that using parse_address_line is good for consistancy in Git
anyway. If the behavior of parse_address_line is broken on some
corner-cases, then it should be fixed anyway.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [RFC] send-email quote issues
  2015-06-15 11:32   ` Matthieu Moy
@ 2015-06-15 13:03     ` Remi Lespinet
  2015-06-15 13:52       ` Matthieu Moy
  0 siblings, 1 reply; 5+ messages in thread
From: Remi Lespinet @ 2015-06-15 13:03 UTC (permalink / raw)
  To: Matthieu Moy
  Cc: git, Remi Galan, Antoine Delaite, Louis-Alexandre Stuber,
	Guillaume Pages

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes

> I would say that using parse_address_line is good for consistancy in Git 
> anyway. If the behavior of parse_address_line is broken on some 
> corner-cases, then it should be fixed anyway. 

Ok, but I don't know what fixed means in these particular cases.
Actually the problem when we have a quote in a name is: Is this a
delimiter or is this an ascii char?

Currently the problem is solved by saying : it's an ascii char
unless there is two quotes aroung all the name (modulo minor
things). So if I write:

--to='"Jane, Kararina" Doe <jdoe@example.com>'

they are considered characters. Which means that this is
different than:

--to='"Jane, Kararina Doe" <jdoe@example.com>'

Is this expected?

^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: [RFC] send-email quote issues
  2015-06-15 13:03     ` Remi Lespinet
@ 2015-06-15 13:52       ` Matthieu Moy
  2015-06-15 14:10         ` Remi Lespinet
  0 siblings, 1 reply; 5+ messages in thread
From: Matthieu Moy @ 2015-06-15 13:52 UTC (permalink / raw)
  To: Remi Lespinet
  Cc: git, Remi Galan, Antoine Delaite, Louis-Alexandre Stuber,
	Guillaume Pages

Remi Lespinet <remi.lespinet@ensimag.grenoble-inp.fr> writes:

> Ok, but I don't know what fixed means in these particular cases.
> Actually the problem when we have a quote in a name is: Is this a
> delimiter or is this an ascii char?

To me, the answer should be: do whatever the RFC says in email headers.
I'd expect anything that works in the To: header to work in the --to
option of git send-email.

If I read correctly, this is address-list in RFC 2822.

Now, when the address list is invalid wrt the RFC, we can either reject
it or try to guess.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

^ permalink raw reply	[flat|nested] 5+ messages in thread

* [RFC] send-email quote issues
  2015-06-15 13:52       ` Matthieu Moy
@ 2015-06-15 14:10         ` Remi Lespinet
  0 siblings, 0 replies; 5+ messages in thread
From: Remi Lespinet @ 2015-06-15 14:10 UTC (permalink / raw)
  To: Matthieu Moy
  Cc: git, Remi Galan, Antoine Delaite, Louis-Alexandre Stuber,
	Guillaume Pages

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes

> To me, the answer should be: do whatever the RFC says in email headers. 
> I'd expect anything that works in the To: header to work in the --to 
> option of git send-email. 

Ok sounds good to me !

^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2015-06-15 14:09 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [not found] <387683965.505610.1434366660032.JavaMail.zimbra@ensimag.grenoble-inp.fr>
2015-06-15 11:16 ` [RFC] send-email quote issues Remi Lespinet
2015-06-15 11:32   ` Matthieu Moy
2015-06-15 13:03     ` Remi Lespinet
2015-06-15 13:52       ` Matthieu Moy
2015-06-15 14:10         ` Remi Lespinet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox