Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames

3 messages, 3 authors, 2016-06-15 · open the first message on its own page

Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames

From: Linus Torvalds <torvalds@osdl.org>
Date: 2016-06-15 22:42:08


On Wed, 12 Oct 2005, Paul Eggert wrote:
Your email message suggests that we need to be cautious here.
That message contained UTF-8 text but its header said "Content-Type:
TEXT/PLAIN; charset=ISO-8859-1".
Well, my email message was wrong and evil, because it _mixed_ two 
different encodings in the same text. No sane client could have shown them 
both at the same time - but especially with a stupid client, you could 
have changed your terminal to show either one or the other by switching 
from utf-8 to latin1 encoding and doing a refresh.

In other words, my email really was a nasty case of not one or the other, 
but both.

Now, I believe patches can actually be that way - it's not at all 
impossible to have a diff where the _filename_ is utf-8, but the content 
of the patch itself is some byte-encoding like latin1. Or the other way 
around.
If we're still having problems like this in 2005 then I guess we need
to deal with them.  This suggests we should be escaping every
non-ASCII byte, at least for patches designed to be emailed robustly.
I find that email is very robust - it's basically 8-bit clean. No 
character encoding, no crap. Just a byte stream. It really _is_ the most 
reliable format.

Now, a lot of email clients are really weak in _showing_ it, and as 
mentioned, the email that mixed both is fundamentally not something you 
really even _can_ show sanely. But who cares? What matters is not what it 
looks like, but what it _saves_ as. If you save the email message, it 
should come out as the same reliable 8-bit byte stream, or your client is 
actively corrupting messages rather than just showing them.

This is really what my argument boils down to: character set encoding 
should _not_ EVER affect the _transfer_ of the data. It doesn't matter if 
something is latin1 or utf-8, the only thing that matters is the byte 
sequence. Only when you _display_ it should you try to figure out what the 
byte sequence possibly means.

So I repeat: 
 - escape as little as possible
 - make the _viewer_ decide how to view it.

Yes, if people use "cat" to view patches, it can be dangerous. But that's 
_their_ problem.

		Linus

Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames

From: "H. Peter Anvin" <hpa@zytor.com>
Date: 2016-06-15 22:42:08

Linus Torvalds wrote:
Now, I believe patches can actually be that way - it's not at all 
impossible to have a diff where the _filename_ is utf-8, but the content 
of the patch itself is some byte-encoding like latin1. Or the other way 
around.
Or both.  Trivial example: a patch to change names in comments from ISO 
8859-1 to UTF-8.

	-hpa

Re: [PATCH] Try URI quoting for embedded TAB and LF in pathnames

From: Johannes Schindelin <hidden>
Date: 2016-06-15 22:42:08

Hi,

On Wed, 12 Oct 2005, Linus Torvalds wrote:
Yes, if people use "cat" to view patches, it can be dangerous. But that's 
_their_ problem.
No, that is the cat's problem. Sorry, couldn't resist.

Ciao,
Dscho
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help