Why do many of you not _attach_ patches instead of merging them with the
mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
attached to the mail which can be saved in an appropriate directory. Also,
the whitespace is always retained that way.
OTOH I don't have very deep knowledge of "diff" and "patch", so maybe I have
missed something here...
_____________________________________________________
| Martin Eriksson <[email protected]>
| MSc CSE student, department of Computing Science
| Ume? University, Sweden
- ABIT BP6(RU) - 2xCeleron 400 - 128MB/PC100/C2 Acer
- Maxtor 10/5400/U33 HPT P/M - Seagate 6/5400/U33 HPT S/M
- 2xDE-530TX - 1xTulip - Linux 2.4.17+ide+preempt
From: "Martin Eriksson" <[email protected]>
Date: Tue, 15 Jan 2002 18:44:58 +0100
Why do many of you not _attach_ patches instead of merging them
with the mail?
Because it allows people without mime decoders to read
the patch without feeding the email to external programs.
Martin Eriksson wrote:
>Why do many of you not _attach_ patches instead of merging them with the
>mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
>attached to the mail which can be saved in an appropriate directory. Also,
>the whitespace is always retained that way.
>
>OTOH I don't have very deep knowledge of "diff" and "patch", so maybe I have
>missed something here...
>
Don't worry - nothign prevents proper attached patches from beeing
applied - the FAQ is only a bit
zealous on this ;-)
On Tue, Jan 15, 2002 at 06:44:58PM +0100, Martin Eriksson wrote:
> Why do many of you not _attach_ patches instead of merging them with the
> mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> attached to the mail which can be saved in an appropriate directory. Also,
> the whitespace is always retained that way.
It is nice to have the patch to look at when looking at the mail, and
it is nice to have the mail to look at when looking at the patch.
One of the features of patch is that you can save the whole patch
e-mail to a file and use it directly; patch is willing to skip over
all the e-mail headers and regular looking text until it sees
something that looks like a patch. Handy, huh?
-kb
In article <005901c19dec$59a89e30$0201a8c0@HOMER>,
Martin Eriksson <[email protected]> wrote:
>Why do many of you not _attach_ patches instead of merging them with the
>mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
>attached to the mail which can be saved in an appropriate directory. Also,
>the whitespace is always retained that way.
Attached patches are _horrible_ once you have many patches that you want
to maintain in a sane way and apply in one go.
In particular, with in-line text patches, I can:
- see the patch easily when reading email, without the need to do
anything special to inspect the attachment, regardless of what email
client I happen to use.
- keep emails as emails, and save them to folders etc, without
losing any information of where the patch came from, while at the
same time the folders are _also_ the patch and work with standard
tools like "diffstat".
- easily just "reply" to the person, and quote the part of the patch
I have problems with.
- save all the emails I want to apply in one single email folder
("doit"), and do a simple
patch -p1 < ~/doit
to apply all of them at the same time.
Note that NONE of these are practical with attachments.
In short: if your mailer eats whitespace or causes similar corruption,
just FIX THE MAILER. There is no excuse for a mailer that corrupts the
mail.
And while attachments may _appear_ convenient, they most definitely are
not. They require special care and cannot be batched or edited with
normal tools.
That may not matter if you just have one or two patches a week to worry
about, but trust me - attachments are crap. Use them for binary data
that cannot be edited or combined, _not_ for stuff you expect to be able
to actually change and extract pieces of with regular tools.
Linus
In article <[email protected]>,
Martin Dalecki <[email protected]> wrote:
>
>Don't worry - nothign prevents proper attached patches from beeing
>applied - the FAQ is only a bit zealous on this ;-)
Wrong.
If I get a patch in an attachment (other than a "Text/PLAIN" type
attachment with no mangling and that pretty much all mail readers and
all tools will see as a normal body), I simply WILL NOT apply it unless
I have strong reason to. I usually wont even bother looking at it,
unless I expected something special from the sender.
Really. Don't send patches as attachments.
Linus
"Martin Eriksson" <[email protected]> writes:
> Why do many of you not _attach_ patches instead of merging them with the
> mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> attached to the mail which can be saved in an appropriate directory. Also,
> the whitespace is always retained that way.
>
> OTOH I don't have very deep knowledge of "diff" and "patch", so maybe I have
> missed something here...
Patches are often saved and applied later. In this case it is useful to have
the context of the mail message it was contained in around in the same
file, so that you later actually know what you apply if you happen to
not memorize it completely. Patch will ignore the mail part so it can be
still applied directly.
With saved attachments you usually just a patch and no description, or
it requires extra effort to save the description too.
-Andi
Linus Torvalds writes:
> In article <[email protected]>,
> Martin Dalecki <[email protected]> wrote:
> >
> >Don't worry - nothign prevents proper attached patches from beeing
> >applied - the FAQ is only a bit zealous on this ;-)
>
> Wrong.
>
> If I get a patch in an attachment (other than a "Text/PLAIN" type
> attachment with no mangling and that pretty much all mail readers and
> all tools will see as a normal body), I simply WILL NOT apply it unless
> I have strong reason to. I usually wont even bother looking at it,
> unless I expected something special from the sender.
>
> Really. Don't send patches as attachments.
Thanks for providing material I can quote :-) I've updated the FAQ
entry on this, and also included your sage words:
http://www.tux.org/lkml/#s1-14
"So let it be written, so let it be done!" :-)
Regards,
Richard....
Permanent: [email protected]
Current: [email protected]
> all tools will see as a normal body), I simply WILL NOT apply it unless
> I have strong reason to. I usually wont even bother looking at it,
> unless I expected something special from the sender.
>
> Really. Don't send patches as attachments.
BTW: If you are sending me anything DO use attachments. Especially if you
use any of the following, which seem to have some versions that mangle
inline diffs
Lotus Notes
Pine
Kmail
Mozilla
Netscape
MS Outlook
If you aren't sure if your mailer is ok then send yourself a block of text
that contains a line over 80 chars long, a line ending in space, and a line
with tabs in it
Check the tabs are still there, the space on the end of the line hasnt been
eaten (eg pine) and that the long line was not wrapped.
Alan
On Tue, 15 Jan 2002, Alan Cox wrote:
> > all tools will see as a normal body), I simply WILL NOT apply it unless
> > I have strong reason to. I usually wont even bother looking at it,
> > unless I expected something special from the sender.
> >
> > Really. Don't send patches as attachments.
>
> BTW: If you are sending me anything DO use attachments. Especially if you
> use any of the following, which seem to have some versions that mangle
> inline diffs
>
> Lotus Notes
> Pine
> Kmail
> Mozilla
> Netscape
> MS Outlook
Pine works fine here if you use ^R
- Davide
----- Original Message -----
From: "Kent Borg" <[email protected]>
To: "Martin Eriksson" <[email protected]>
Cc: <[email protected]>
Sent: Tuesday, January 15, 2002 6:57 PM
Subject: Re: Why not "attach" patches?
> On Tue, Jan 15, 2002 at 06:44:58PM +0100, Martin Eriksson wrote:
> > Why do many of you not _attach_ patches instead of merging them with the
> > mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> > attached to the mail which can be saved in an appropriate directory.
Also,
> > the whitespace is always retained that way.
>
> It is nice to have the patch to look at when looking at the mail, and
> it is nice to have the mail to look at when looking at the patch.
>
> One of the features of patch is that you can save the whole patch
> e-mail to a file and use it directly; patch is willing to skip over
> all the e-mail headers and regular looking text until it sees
> something that looks like a patch. Handy, huh?
Aaah.. DOH! That was just what was lurking in the back of my head, but the
thinking part of the brain didn't quite grasp it. Of course "patch" will
skip "no-patch" text instead of crapping out. Hell, if I'd designed the
"patch" program that behaviour would have been one of the first things to
implement.
Sorry for the LKML spam then =) but ain't it nice with one of these
"easy-to-answer" mails from time to time...?
/Martin Eriksson
PS. I really hate OE. Anyone care to recommend THE Windoze Mail+News reader
program, with EXTREME filtering capabilities AND not looking like crap?
Slightly off topic to lkml so replies off list please...
On Tue, 15 Jan 2002, Martin Eriksson wrote:
> PS. I really hate OE. Anyone care to recommend THE Windoze Mail+News reader
> program, with EXTREME filtering capabilities AND not looking like crap?
I use two:
Eudora 5 for mail
Forte Free Agent for news
IMO the best GUI clients full stop.
For sending inlined patches I use elm (on Solaris) which while basic gets
the job done guaranteed without messing up the precious white space...
Best regards,
Anton
--
Anton Altaparmakov <aia21 at cam.ac.uk> (replace at with @)
Linux NTFS maintainer / WWW: http://linux-ntfs.sf.net/
ICQ: 8561279 / WWW: http://www-stu.christs.cam.ac.uk/~aia21/
On Tue, 15 Jan 2002, Alan Cox wrote:
> BTW: If you are sending me anything DO use attachments. Especially if you
> use any of the following, which seem to have some versions that mangle
> inline diffs
>
> Lotus Notes
> Pine
> Kmail
> Mozilla
> Netscape
> MS Outlook
Pine always worked fine when patches are imported with ^R.
Nicolas
Some implementation-specific details people may find useful:
* For 4.xx versions of Netscape Mail, with standard mime types/prefs,
sending patches by MIME attachment results in a readable text/plain
message.
* The best way to mail patches is to pipe a header, patch description,
and contents to "/usr/sbin/sendmail -t" or some other MTA. When I spam
Linus or Marcelo with patches, my process looks like this:
1) create outgoing patches
2) change e-mail header template to reflect current kernel version
3) put template and blank space at top of each patch
4) "vi *.patch", manually insert descriptions and CC list from
MAINTAINERS
5) review each patch and description once again :)
6) pipe *.patch individually through "/usr/sbin/sendmail -t"
Here is the mail header template I use. Sendmail is smart and will
insert all other headers like message-id and date, since they are not
present. When using another MTA, make sure yours does this too.
> [jgarzik@rum g]$ cat ~/info/mail.linus
> From: Jeff Garzik <jgarzik at mandrakesoft.com>
> BCC: jgarzik at mandrakesoft.com
> To: Linus Torvalds <torvalds at transmeta.com>
> CC: akpm at zip.com.au, davem at redhat.com
> Subject: PATCH 2.5.2.9: net drvr
>
As always, read Documentation/SubmittingPatches. That's what it's there
for.
--
Jeff Garzik | Alternate titles for LOTR:
Building 1024 | Fast Times at Uruk-Hai
MandrakeSoft | The Took, the Elf, His Daughter and Her Lover
| Samwise Gamgee: International Hobbit of Mystery
On Tue, 15 Jan 2002, Nicolas Pitre wrote:
> On Tue, 15 Jan 2002, Alan Cox wrote:
>
> > BTW: If you are sending me anything DO use attachments. Especially if you
> > use any of the following, which seem to have some versions that mangle
> > inline diffs
> >
> > Lotus Notes
> > Pine
> > Kmail
> > Mozilla
> > Netscape
> > MS Outlook
>
> Pine always worked fine when patches are imported with ^R.
It doesn't at all. It silently removes extra white space at the end of
lines. It's been a "feature" since about 4.30 or so.
Does anyone recall exactly which version this changed in? Or, have any of
the vendors reversed this wart?
-pat
On Jan 15, 2002 14:09 -0800, Patrick Mochel wrote:
> On Tue, 15 Jan 2002, Nicolas Pitre wrote:
> > Pine always worked fine when patches are imported with ^R.
>
> It doesn't at all. It silently removes extra white space at the end of
> lines. It's been a "feature" since about 4.30 or so.
>
> Does anyone recall exactly which version this changed in? Or, have any of
> the vendors reversed this wart?
Well, it would be a feature if it knew enough to only remove whitespace
at the end of "+" lines in context diffs. Then we wouldn't have 200kB
of useless whitespace in the kernel sources.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Tue, 15 Jan 2002, Patrick Mochel wrote:
> It doesn't at all. It silently removes extra white space at the end of
> lines. It's been a "feature" since about 4.30 or so.
I am pretty sure that it works fine in RedHat's 4.33 version (or else
Linus would have dropped some of my patches ... er, more of my patches :).
But I haven't checked how that version differs from the original.
At the end is a simple ^R-ed file that works for me sending to myself.
But I don't think it is related to ^R ...
(should be 3 spaces after that line)
If you postpone a message it has a silly idea to add an empty line at the
end. But that shouldn't break patches.
/Urban
no space
tab
3 spaces
no space
"Martin Eriksson" <[email protected]> writes:
> ----- Original Message -----
> From: "Kent Borg" <[email protected]>
> To: "Martin Eriksson" <[email protected]>
> Cc: <[email protected]>
> Sent: Tuesday, January 15, 2002 6:57 PM
> Subject: Re: Why not "attach" patches?
>
>
> > On Tue, Jan 15, 2002 at 06:44:58PM +0100, Martin Eriksson wrote:
> > > Why do many of you not _attach_ patches instead of merging them with the
> > > mail? It's so much cleaner and easier to have a "xxx-yyy.patch" file
> > > attached to the mail which can be saved in an appropriate directory.
> Also,
> > > the whitespace is always retained that way.
> >
> > It is nice to have the patch to look at when looking at the mail, and
> > it is nice to have the mail to look at when looking at the patch.
> >
> > One of the features of patch is that you can save the whole patch
> > e-mail to a file and use it directly; patch is willing to skip over
> > all the e-mail headers and regular looking text until it sees
> > something that looks like a patch. Handy, huh?
>
> Aaah.. DOH! That was just what was lurking in the back of my head, but the
> thinking part of the brain didn't quite grasp it. Of course "patch" will
> skip "no-patch" text instead of crapping out. Hell, if I'd designed the
> "patch" program that behaviour would have been one of the first things to
> implement.
>
> Sorry for the LKML spam then =) but ain't it nice with one of these
> "easy-to-answer" mails from time to time...?
>
> /Martin Eriksson
>
> PS. I really hate OE. Anyone care to recommend THE Windoze Mail+News reader
> program, with EXTREME filtering capabilities AND not looking like
> crap?
dunno if you feel it looks like crap or not, but i recommend
gnus/emacs. it works great on both windows and linux. it can split
mail into buckets/folders. it has better than filtering, it has
SCORING.
i am not sure what to do about the ubiquitous sendmail/mailbox ^From
braindamage though. qmail using maildir doesn't suffer from it.
--
J o h a n K u l l s t a m
[[email protected]]
Patrick Mochel([email protected])@2002.01.15 14:09:27 +0000:
> Does anyone recall exactly which version this changed in? Or, have any of
> the vendors reversed this wart?
https://www.redhat.com/support/errata/RHBA-2001-118.html
"The current releases of PINE 4.33 contain a whitespace mangling bug that is
fixed in this release."
/B.
--
Sebastian Benoit <[email protected]>
GnuPG 0x5BA22F00 2001-07-31 2999 9839 6C9E E4BF B540 C44B 4EC4 E1BE 5BA2 2F00
Buy land. They've stopped making it. -- Mark Twain.
Andreas Dilger <[email protected]> writes:
>Well, it would be a feature if it knew enough to only remove whitespace
>at the end of "+" lines in context diffs. Then we wouldn't have 200kB
>of useless whitespace in the kernel sources.
apply patches. Run this. Rinse. Repeat. :-)
--- cut ---
mkdir /usr/src/linux.noblanks
(
cd /usr/src/linux
find . -type d -exec mkdir -p /usr/src/linux.noblanks/{} \;
for i in `find . -type f`; do
perl -ne 's/[ ]+$//; print;' < ${i} > /usr/src/linux.noblanks/${i}
done
)
diff -ur /usr/src/linux /usr/src/linux.noblanks | mail -s "blanks removed" [email protected]
rm -rf /usr/src/linux.noblanks
--- cut ---
(This is a TAB and a space in the square brackets above.
Don't use \s. Trust me.)
linux-2.2.20.tar.bz2: 15,751,285 bytes
linux-2.2.20-nbl.tar.bz2: 15,608,085 bytes
Patch Size (uncompressed): 17,815,166 bytes (yes this _is_ 17,4 MBytes)
(compressed, bzip2): 3,322,456 bytes
One mega-patch to shear off about 140 KBytes from the compressed (and
about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
would (while it may be the biggest single "reduce-size-of-kernel-tree
patch" in years :-) ) a little gross.
Regards
Henning
--
Dipl.-Inf. (Univ.) Henning P. Schmiedehausen -- Geschaeftsfuehrer
INTERMETA - Gesellschaft fuer Mehrwertdienste mbH [email protected]
Am Schwabachgrund 22 Fon.: 09131 / 50654-0 [email protected]
D-91054 Buckenhof Fax.: 09131 / 50654-20
At 12:11 AM 16/01/02 +0000, Henning P. Schmiedehausen wrote:
>Patch Size (uncompressed): 17,815,166 bytes (yes this _is_ 17,4 MBytes)
> (compressed, bzip2): 3,322,456 bytes
>
>One mega-patch to shear off about 140 KBytes from the compressed (and
>about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
>would (while it may be the biggest single "reduce-size-of-kernel-tree
>patch" in years :-) ) a little gross.
This 'sort' of thing would be a good idea for 2.5 IMHO (pref. asap), mainly
to get it out of the way! It would probably be a good idea to do this on a
tree just before it matures too (eg: when 2.5 migrates to 2.6/3.0/whatever).
The savings to other trees are probably not worth the effort involved for
what we gain back (at the moment anyway).
You'll probably find that there are other things about that might save a
few bytes here and there too (and at the same time might clean the code up
a bit and make it more readable).
Stuart Young - [email protected]
(aka Cefiar) - [email protected]
[All opinions expressed in the above message are my]
[own and not necessarily the views of my employer..]
Hi Linus,
On Tue, 15 Jan 2002, Linus Torvalds wrote:
> Wrong.
>
> If I get a patch in an attachment (other than a "Text/PLAIN" type
> attachment with no mangling and that pretty much all mail readers
> and all tools will see as a normal body),
So text/plain is ok for you? How about multiple cummulative patches
attached to one mail?
This is the case where I hate your strategy about attachments: You
want to have separate patches (what I clearly understand), but you do
not want attachments. That's fine most of the time as long as I send
it to you privately, but to public lists too many people miss the
important steps.
Greetings
Christoph
On Jan 16, 2002 00:11 +0000, Henning P. Schmiedehausen wrote:
> Andreas Dilger <[email protected]> writes:
> >Well, it would be a feature if it knew enough to only remove whitespace
> >at the end of "+" lines in context diffs. Then we wouldn't have 200kB
> >of useless whitespace in the kernel sources.
>
> (This is a TAB and a space in the square brackets above.
> Don't use \s. Trust me.)
>
> linux-2.2.20.tar.bz2: 15,751,285 bytes
> linux-2.2.20-nbl.tar.bz2: 15,608,085 bytes
>
> Patch Size (uncompressed): 17,815,166 bytes (yes this _is_ 17,4 MBytes)
> (compressed, bzip2): 3,322,456 bytes
>
> One mega-patch to shear off about 140 KBytes from the compressed (and
> about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
> would (while it may be the biggest single "reduce-size-of-kernel-tree
> patch" in years :-) ) a little gross.
Oh, I'm not advocating sending in a huge patch _just_ to remove the
useless whitespace (which includes trailing spaces/tabs and [space][tab]
combinations), but it would be nice if someone is setting up a patchbot
to remove such whitespace in new or modified lines in a patch.
Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/
On Wed, 16 Jan 2002, Christoph Rohland wrote:
>
> On Tue, 15 Jan 2002, Linus Torvalds wrote:
> > Wrong.
> >
> > If I get a patch in an attachment (other than a "Text/PLAIN" type
> > attachment with no mangling and that pretty much all mail readers
> > and all tools will see as a normal body),
>
> So text/plain is ok for you?
text/plain is fine - it has all the properties a non-attachment has.
> How about multiple cummulative patches attached to one mail?
Absolutely not. When I open my mail-client, and somebody has sent me 20
patches, I want to _see_ 20 mails. That way I can select from them, and
the mailreader clearly indicates which ones I've read, etc etc.
Multiple attachements have no advantages, and have several disadvantages.
> This is the case where I hate your strategy about attachments: You
> want to have separate patches (what I clearly understand), but you do
> not want attachments. That's fine most of the time as long as I send
> it to you privately, but to public lists too many people miss the
> important steps.
Sending large patches to public lists tends to be a mistake in the first
place. It just irritates the people who pay for bandwidth and do not want
to apply patches off the list.
Linus
On Wed, Jan 16, 2002 at 12:11:35AM +0000, Henning P. Schmiedehausen wrote:
> apply patches. Run this. Rinse. Repeat. :-)
>
> --- cut ---
>
> mkdir /usr/src/linux.noblanks
>
> (
> cd /usr/src/linux
> find . -type d -exec mkdir -p /usr/src/linux.noblanks/{} \;
> for i in `find . -type f`; do
> perl -ne 's/[ ]+$//; print;' < ${i} > /usr/src/linux.noblanks/${i}
> done
> )
>
> diff -ur /usr/src/linux /usr/src/linux.noblanks | mail -s "blanks removed" [email protected]
>
> rm -rf /usr/src/linux.noblanks
> --- cut ---
>
> (This is a TAB and a space in the square brackets above.
> Don't use \s. Trust me.)
>
> linux-2.2.20.tar.bz2: 15,751,285 bytes
> linux-2.2.20-nbl.tar.bz2: 15,608,085 bytes
>
> Patch Size (uncompressed): 17,815,166 bytes (yes this _is_ 17,4 MBytes)
> (compressed, bzip2): 3,322,456 bytes
>
> One mega-patch to shear off about 140 KBytes from the compressed (and
> about 170 k from the unpacked (94488 vs. 94316 KBytes ) kernel source
> would (while it may be the biggest single "reduce-size-of-kernel-tree
> patch" in years :-) ) a little gross.
Uh .. why not let Linus just run this program on *his* machine, and putting
up the patch again as a "program to be run"? ;-)
Saves Linus of the headache to check if there are any bugs in the patch
before applying ( and that too, with the funny label of "lossy something"
he's earned ... saves a lot of bandwidth! ;-) )
regards,
jaju
On January 15, 2002 08:28 pm, Alan Cox wrote:
> > all tools will see as a normal body), I simply WILL NOT apply it unless
> > I have strong reason to. I usually wont even bother looking at it,
> > unless I expected something special from the sender.
> >
> > Really. Don't send patches as attachments.
>
> BTW: If you are sending me anything DO use attachments. Especially if you
> use any of the following, which seem to have some versions that mangle
> inline diffs
>
> Lotus Notes
> Pine
> Kmail
> [...]
Kmail's patch-mangling problems seem to be all gone in kmail 2.2+. The only
thing to be careful about is that word wrap should be off. Since I forgot to
turn it off a couple of times I now leave it permanently off and turn it on
for individual mails as needed.
--
Daniel
Followup to: <[email protected]>
By author: Daniel Phillips <[email protected]>
In newsgroup: linux.dev.kernel
>
> Kmail's patch-mangling problems seem to be all gone in kmail 2.2+. The only
> thing to be careful about is that word wrap should be off. Since I
> forgot to
> turn it off a couple of times I now leave it permanently off and turn it on
> for individual mails as needed.
>
The common ground most people seems to be able to accept is:
a. Go ahead and make patches as attachments, if your MUA makes it easier;
b. Be bloody certain they're text/plain attachments.
-hpa
--
<[email protected]> at work, <[email protected]> in private!
"Unix gives you enough rope to shoot yourself in the foot."
http://www.zytor.com/~hpa/puzzle.txt <[email protected]>
[email protected] (H. Peter Anvin) wrote on 22.01.02 in <[email protected]>:
> The common ground most people seems to be able to accept is:
>
> a. Go ahead and make patches as attachments, if your MUA makes it easier;
> b. Be bloody certain they're text/plain attachments.
... and that they have Content-Transfer-Encoding: 7bit or 8bit.
*Not* quoted-printable or base64.
Which means that you lose if the patch contains chars whose 8th bit is
set, if any MTA between you and Linus/Alan/etc. doesn't like that. Which
is not quite unlikely. (But most MUAs won't allow you to send something
like that anyway.)
MfG Kai