build softraid(4) in powerpc64 RAMDISK
powerpc64 already has bio(4) and bioctl(8) like macppc, but lacks softriad(4), which looks like an oversight. Neither architecture has boot support, but they still ought to be able to access softraid volumes during install/upgrade. distrib/powerpc64/ramdisk builds and fits; I did not have a free disk (partition) to run-test, but completing the config should be fine. Feedback? Objection? OK? Index: sys/arch/powerpc64/conf/RAMDISK === RCS file: /cvs/src/sys/arch/powerpc64/conf/RAMDISK,v retrieving revision 1.12 diff -u -p -r1.12 RAMDISK --- sys/arch/powerpc64/conf/RAMDISK 26 Jun 2022 20:05:06 - 1.12 +++ sys/arch/powerpc64/conf/RAMDISK 16 Sep 2023 16:32:42 - @@ -25,6 +25,7 @@ optionCRYPTO config bsd root on rd0a swap on rd0b mainbus0 at root +softraid0 at root cpu0 at mainbus? opal0 at fdt? opalcons* at fdt?
Re: man 9 intro - improvements [and learning for me]?
--- Original Message --- On Tuesday, September 19th, 2023 at 7:03 PM, Theo de Raadt wrote: > > > Ingo, that's a bit cynical. > > > As long as the process is slow, step by step, adding one or two manuals at > a time, and focusing on being ACCURATE, then it will be good. > > It would be wrong to add inaccurate pages. A lack of documentation is slightly > better than inaccurate documentation. > > So if you really want to do this, I suggest you start with the simplest ones > first, get them correct, listen to the feedback you receive and figure out > who has knowledge in each area, and adapt your review process along the way. > > Ingo is very familiar with this process, but perhaps also a bit jaded because > he has done some very big documentation uplifts (and in each case, had the > big plan to update a big area). Done in small bits, small but valuable > improvements are not that difficult. > I appreciate the course correction with my approach and train of thought. Instead of just updating something for the sake of updating it, ensure it is solid as you go and useful. So, for example, if I'm diving into some portion of the kernel and find the documentation lacking in some manner, best to call that out with a proposed change (which I'm sure will not be good enough the first go around). I am fortunate in that I have a perspective of being new to this space, so I can see it from a different POV than you seasoned vets here. No one likes doc-rot and I don't want to be a problem-maker in that area. I've maintained enough technical documentation over the years, it is a beast of a burden, and at the end of it all you question why you even started. I've reoriented myself to just focus on one portion [perhaps of a portion] to focus on and learn at a time. Not trying to be the world's greatest kernel developer and documentation expert. Just learning to learn and have fun by working on dope stuff you all built. My coding in C is rusty at best (though I used to code it for a living) and I certainly know little about writing and editing man pages. Appreciate the guidance and advice. It is helpful to be aligned properly with you all and your expectations of how quality work is done and approached. > Ingo Schwarze schwa...@usta.de wrote: > > > Hi Christoff, > > > > of course you are free to work on whatever interests you, but if you are > > looking for advice, i'd respectfully recommend that you try to work on > > specifics rather than on generalities first, in particular when you > > feel as if your experience in contributing isn't above average. > > That applies even in the domain of documentation. > > > > Christoff Humphries wrote on Mon, Sep 18, 2023 at 12:21:48PM +: > > > > > I went searching for documentation about the kernel internals and was > > > used to the intro(9) man page from NetBSD > > > https://man.netbsd.org/intro.9 that had a lot more details. Would it > > > be a worthwhile project to attempt to do the same for OpenBSD? > > > > Doing something like that may sound simple at first, but actually, > > i can think of few documentation changes that would be harder to get > > right and harder to get committed. > > > > Unless i'm totally off track, getting that right requires > > > > 1) a solid understanding of all areas of the kernel and > > 2) a good understanding of what our kernel developers > > actually need to know for their everyday work. > > > > If you have that knowledge, it's still much easier to improve > > individual pages that are lacking in quality than improving the top-level > > overview. Note that item 2 above tells you which of the pages are > > probably most worthy of attention. > > > > Besides, the NetBSD intro(9) page does not strike me as particularly > > convincing. If the lines in that page agree with the .Nd one-line > > descriptions in the indivual pages, then it provides almost nothing > > of value - but causes a maintenance burden because it needs to be > > edited whenever any .Nd line changes. If the lines mismatch, then > > the .Nd lines in the indivifual pages can likely be improved. > > I did not check which is the case - possibly both are. > > > > We did have a few pages like that in the past, but most of those > > got deleted because they provided little value. For example, > > compare these two: > > > > https://man.openbsd.org/OpenBSD-5.6/string.3 > > https://man.openbsd.org/OpenBSD-current/string.3 > > > > A very small number still exists, perhaps most notably > > > > https://man.openbsd.org/crypto.3 and > > https://man.openbsd.org/ssl.3 > > > > The benefit of those is not that they exhaustively list everything - > > indeed, apropos(1) is better at that job than a manually maintained > > table of contents - but that they provide some high-level information > > how the libraries as a whole are intended to be used that is hard to > > figure out from individual pages. Also, these pages do not duplicate > > .Nd lines. > > > > > I
Re: man 9 intro - improvements [and learning for me]?
Ingo, that's a bit cynical. As long as the process is slow, step by step, adding one or two manuals at a time, and focusing on being ACCURATE, then it will be good. It would be wrong to add inaccurate pages. A lack of documentation is slightly better than inaccurate documentation. So if you really want to do this, I suggest you start with the simplest ones first, get them correct, listen to the feedback you receive and figure out who has knowledge in each area, and adapt your review process along the way. Ingo is very familiar with this process, but perhaps also a bit jaded because he has done some very big documentation uplifts (and in each case, had the big plan to update a big area). Done in small bits, small but valuable improvements are not that difficult. Ingo Schwarze wrote: > Hi Christoff, > > of course you are free to work on whatever interests you, but if you are > looking for advice, i'd respectfully recommend that you try to work on > specifics rather than on generalities first, in particular when you > feel as if your experience in contributing isn't above average. > That applies even in the domain of documentation. > > Christoff Humphries wrote on Mon, Sep 18, 2023 at 12:21:48PM +: > > > I went searching for documentation about the kernel internals and was > > used to the intro(9) man page from NetBSD > > https://man.netbsd.org/intro.9 that had a lot more details. Would it > > be a worthwhile project to attempt to do the same for OpenBSD? > > Doing something like that may *sound* simple at first, but actually, > i can think of few documentation changes that would be harder to get > right and harder to get committed. > > Unless i'm totally off track, getting that right requires > > 1) a solid understanding of all areas of the kernel and > 2) a good understanding of what our kernel developers > actually need to know for their everyday work. > > If you have that knowledge, it's *still* much easier to improve > individual pages that are lacking in quality than improving the top-level > overview. Note that item 2 above tells you which of the pages are > probably most worthy of attention. > > Besides, the NetBSD intro(9) page does not strike me as particularly > convincing. *If* the lines in that page agree with the .Nd one-line > descriptions in the indivual pages, then it provides almost nothing > of value - but causes a maintenance burden because it needs to be > edited whenever any .Nd line changes. If the lines mismatch, then > the .Nd lines in the indivifual pages can likely be improved. > I did not check which is the case - possibly both are. > > We did have a few pages like that in the past, but most of those > got deleted because they provided little value. For example, > compare these two: > > https://man.openbsd.org/OpenBSD-5.6/string.3 > https://man.openbsd.org/OpenBSD-current/string.3 > > A very small number still exists, perhaps most notably > > https://man.openbsd.org/crypto.3 and > https://man.openbsd.org/ssl.3 > > The benefit of those is *not* that they exhaustively list everything - > indeed, apropos(1) is better at that job than a manually maintained > table of contents - but that they provide some high-level information > how the libraries as a whole are intended to be used that is hard to > figure out from individual pages. Also, these pages do not duplicate > .Nd lines. > > > I understand the annoyance of folks talking about what they intend or > > are going to do with no actual fruit, but wanted to check that the > > intro(9) is lacking and the information is not just stored somewhere > > else (other than "apropos -s 9 ."). > > Sorry, i lack the experience in kernel development that would be > required to judge whether any information could usefully be added > to intro(9). > > Yours, > Ingo > > > > I want to learn the internals of the OpenBSD kernel, too, and will do > > as mulander (and friends) did by learning a bit of code daily > > https://blog.tintagel.pl/2017/09/10/openbsd-daily-recap.html. > > > > Seeking the learn and contribute, especially in the uvm, vmd/vmm, and > > possibly filesystem subsystems. >
Re: Send international text with mail(1) - proposal and patches
On Tue, Sep 19, 2023 at 05:48:01PM +0200, Ingo Schwarze wrote: > Hi Walter, > > i did not look closely at the patch yet, and i did not dig for standards > documents, which one should almost certainly do before committing such > a patch unless one knows all the relevant standards by heart (which i > do not), so i'm not saying this must be done differently, but instead > i am merely asking questions. Today I came from having a biopsy of a tumor that appeared in my leg in "February" of this year and thanks to the bureaucracy and the fact that nowadays nobody takes anything seriously, I still don't know if the tumor is malignant. The apathy and irresponsibility of the people (especially here in Spain) is such that I am thinking of buying a scalpel and operating my tumor myself. I explain this because, you can't imagine, dear Ingo, how happy it would make me if at least 10% of the people in this world were half as responsible as you are. :-) > > 1. Are you really sure that a header like > MIME-Version: 1.0 >is not needed when you add Content-*: headers? > > 2. Are you really sure that a header like > Content-Disposition: inline >is not needed? Thanks for the info. :-) > > 3. What is the reason for not simply hardcoding > Content-Transfer-Encoding: 8bit >when sending UTF-8 mail? Yeah, I thought about it. >Are there really still MTAs that choke on that in 2023? >quoted-printable is definitely a PITA no matter the context, >so in my book, if it can be avoided, avoiding it would be a plus. I always try to choose what, from my ignorance, I suspect will cause the least problems. In this case I take into account that when sending a file to the Internet its health no longer depends only on what *my system* supports or not, out there it'll have to survive different environments. Many people still send messages in iso-latin and use MSWin which still doesn't use utf-8: I send a message utf-8 encoded and I get the response in iso-latin. So, from my ignorance, I feel that ASCII has more chances of surviving. > > 4. What's the motivation for the -y flag taking an argument >and not simply hardcoding "text/plain;charset=utf-8"? I also thought about that. >OpenBSD does not support any other charset and does not plan to >change that in the future. >I hope your next patch isn't going to be support for text/html. =:-S Believe me, I try to do everything in my life in the simplest way, while others allow me. But as with everything you have to be careful not to overdo it, for example, in the case that concerns us here, if you notice that every time you need some job done you have to install and use the bloated version of the tools, you should ask yourself if you haven't gone too far with your simplifications. I'm more in favor of the traditional "Keep it simple..." and "If ain't broken..." rather than "simplifying". Simplifying is dangerous, amputating a leg simplifies your body as a system but not your life. > > 5. What's the motivation for supporting -y without -e >and for supporting -e without -y ? Right, that's an inconsistency. > > In general, we want as few options as possible and as little > configurabity as possible. If there is a sane use case for something - > in this case, sending UTF-8 mail - *one* option is possibly warranted. > But adding more than one option would need a very robust justification, > and so would adding an option that takes an argument. > > Note that mail(1) is not mail/swaks. Its purpose is reading and > sending mail in a *simple* way, not low-level testing or protocol > debugging. > > I'll postpone code review and testing, maybe you can simplify this > first? Well, as you have done with me on many occasions, your intention is to kindly educate me, on this occasion you're making me notice that publishing "sketches" instead of a finished work I'm wasting the developers' time. Thanks Ingo! What saddens me is that I'm too old to hope that one day I will win your approval in something. :-) > > Yours, > Ingo -- Walter
Re: Send international text with mail(1) - proposal and patches
Hi Walter, i did not look closely at the patch yet, and i did not dig for standards documents, which one should almost certainly do before committing such a patch unless one knows all the relevant standards by heart (which i do not), so i'm not saying this must be done differently, but instead i am merely asking questions. 1. Are you really sure that a header like MIME-Version: 1.0 is not needed when you add Content-*: headers? 2. Are you really sure that a header like Content-Disposition: inline is not needed? 3. What is the reason for not simply hardcoding Content-Transfer-Encoding: 8bit when sending UTF-8 mail? Are there really still MTAs that choke on that in 2023? quoted-printable is definitely a PITA no matter the context, so in my book, if it can be avoided, avoiding it would be a plus. 4. What's the motivation for the -y flag taking an argument and not simply hardcoding "text/plain;charset=utf-8"? OpenBSD does not support any other charset and does not plan to change that in the future. I hope your next patch isn't going to be support for text/html. =:-S 5. What's the motivation for supporting -y without -e and for supporting -e without -y ? In general, we want as few options as possible and as little configurabity as possible. If there is a sane use case for something - in this case, sending UTF-8 mail - *one* option is possibly warranted. But adding more than one option would need a very robust justification, and so would adding an option that takes an argument. Note that mail(1) is not mail/swaks. Its purpose is reading and sending mail in a *simple* way, not low-level testing or protocol debugging. I'll postpone code review and testing, maybe you can simplify this first? Yours, Ingo
Re: Send international text with mail(1) - proposal and patches
I'd forgotten that adding a "charset" specification to the Content-Type
header is also needed. In the *new* set of patches below, besides I
corrected some other errors, I added a '-y' option to specify utf-8
character set:
$ mail -s Hello -e quoted-printable -y "text/plain;charset=utf-8" \
recipi...@example.com < message.txt
Index: collect.c
===
RCS file: /cvs/src/usr.bin/mail/collect.c,v
retrieving revision 1.34
diff -u -p -r1.34 collect.c
--- collect.c 17 Jan 2014 18:42:30 - 1.34
+++ collect.c 19 Sep 2023 13:30:14 -
@@ -87,7 +87,7 @@ collect(struct header *hp, int printhead
* refrain from printing a newline after
* the headers (since some people mind).
*/
- t = GTO|GSUBJECT|GCC|GNL;
+ t = GTO|GSUBJECT|GENCODING|GTYPE|GCC|GNL;
getsub = 0;
if (hp->h_subject == NULL && value("interactive") != NULL &&
(value("ask") != NULL || value("asksub") != NULL))
@@ -208,7 +208,7 @@ cont:
/*
* Grab a bunch of headers.
*/
- grabh(hp, GTO|GSUBJECT|GCC|GBCC);
+ grabh(hp, GTO|GSUBJECT|GENCODING|GTYPE|GCC|GBCC);
goto cont;
case 't':
/*
@@ -328,7 +328,7 @@ cont:
*/
rewind(collf);
puts("---\nMessage contains:");
- puthead(hp, stdout, GTO|GSUBJECT|GCC|GBCC|GNL);
+ puthead(hp, stdout,
GTO|GSUBJECT|GENCODING|GTYPE|GCC|GBCC|GNL);
while ((t = getc(collf)) != EOF)
(void)putchar(t);
goto cont;
Index: def.h
===
RCS file: /cvs/src/usr.bin/mail/def.h,v
retrieving revision 1.17
diff -u -p -r1.17 def.h
--- def.h 28 Jan 2022 06:18:41 - 1.17
+++ def.h 19 Sep 2023 13:30:14 -
@@ -158,12 +158,14 @@ struct headline {
#defineGSUBJECT 2 /* Likewise, Subject: line */
#defineGCC 4 /* And the Cc: line */
#defineGBCC8 /* And also the Bcc: line */
-#defineGMASK (GTO|GSUBJECT|GCC|GBCC)
+#defineGMASK (GTO|GSUBJECT|GENCODING|GTYPE|GCC|GBCC)
/* Mask of places from whence */
#defineGNL 16 /* Print blank line after */
#defineGDEL32 /* Entity removed from list */
#defineGCOMMA 64 /* detract puts in commas */
+#defineGENCODING 128 /* Content-Transfer-Encoding: line */
+#defineGTYPE 256 /* Content-Type: line */
/*
* Structure used to pass about the current
@@ -173,6 +175,8 @@ struct header {
struct name *h_to; /* Dynamic "To:" string */
char *h_from; /* User-specified "From:" string */
char *h_subject;/* Subject string */
+ char *h_encoding; /* Content-Transfer-Encoding string */
+ char *h_type; /* Content-Type string */
struct name *h_cc; /* Carbon copies string */
struct name *h_bcc; /* Blind carbon copies */
struct name *h_smopts; /* Sendmail options */
Index: extern.h
===
RCS file: /cvs/src/usr.bin/mail/extern.h,v
retrieving revision 1.29
diff -u -p -r1.29 extern.h
--- extern.h16 Sep 2018 02:38:57 - 1.29
+++ extern.h19 Sep 2023 13:30:14 -
@@ -163,7 +163,7 @@ void load(char *);
struct var *
lookup(char *);
int mail(struct name *, struct name *, struct name *, struct name *,
- char *, char *);
+ char *, char *, char *, char *);
voidmail1(struct header *, int);
voidmakemessage(FILE *, int);
voidmark(int);
Index: mail.1
===
RCS file: /cvs/src/usr.bin/mail/mail.1,v
retrieving revision 1.83
diff -u -p -r1.83 mail.1
--- mail.1 31 Mar 2022 17:27:25 - 1.83
+++ mail.1 19 Sep 2023 13:30:15 -
@@ -45,6 +45,8 @@
.Op Fl c Ar list
.Op Fl r Ar from-addr
.Op Fl s Ar subject
+.Op Fl e Ar transfer-encoding
+.Op Fl y Ar content-type
.Ar to-addr ...
.Ek
.Nm mail
@@ -77,6 +79,8 @@ Causes
.Nm mail
to output all sorts of information useful for debugging
.Nm mail .
+.It Fl e Ar encoding
+Add a Content-Transfer-Enconding header on command line.
.It Fl E
Don't send messages with an empty body.
.It Fl f
@@ -133,6 +137,8 @@ except that locking is done.
Verbose mode.
The details of
delivery are displayed on the user's terminal.
+.It Fl y Ar content-type
+Add a Content-Type header on command line.
.El
Re: Buffer overflow in /usr/bin/deroff
On Tue, Sep 19, 2023 at 09:48:25AM -0300, Crystal Kolipe wrote: > deroff chokes when given lines > 2048 bytes, and produces non-deterministic > output on little endian archs. > > Reproducer: > > $ jot -s '' -b blah 513 > /tmp/blah > $ for i in 1 2 3 4 ; do deroff /tmp/blah | md5 ; done > 2d8f4eebd61ed2a07101419169fc9997 > ae19be78a09e6b371787003bf76f5937 > 82b4bcea8510605bea2723ffc70c99b4 > 0ea7b0ddc76d2a280dd30cff6a69574e Since you went to the trouble of reproducing the issue, it would be great if you could turn that into a non-regression test (deroff has none so far, but creating a new Makefile would be comparatively easy, you just need to massage this into a Makefile target that doesn't error our when the bug is fixed) That might even entice people into writing more non-regression tests :) Thank you. -- Marc
Buffer overflow in /usr/bin/deroff
deroff chokes when given lines > 2048 bytes, and produces non-deterministic
output on little endian archs.
Reproducer:
$ jot -s '' -b blah 513 > /tmp/blah
$ for i in 1 2 3 4 ; do deroff /tmp/blah | md5 ; done
2d8f4eebd61ed2a07101419169fc9997
ae19be78a09e6b371787003bf76f5937
82b4bcea8510605bea2723ffc70c99b4
0ea7b0ddc76d2a280dd30cff6a69574e
This happens because regline() writes one byte past the end of line[], and
typically this will be the first byte of *lp.
On little-endian archs this makes lp jump a few bytes backwards or forwards,
meaning that we write the terminating null in slightly the wrong place,
usually resulting in some garbage characters at the end of each output line,
(long lines > LINE_MAX are supposed to be split at LINE_MAX in the output).
Big-endian will almost always just crash immediately, as the pointer is
completely trashed.
Fix below.
Note that on each iteration of the loop, we've already read the next character
from the input stream at the end of the previous iteration, so we have to
increase lp by one before breaking out, to avoid overwriting the last
character of any line that is formed by splitting an overly long one with the
null terminator.
Further note that since the null terminator is stored in line[], we can only
read up to LINE_MAX - 1, so long input lines will be split at 2047 characters.
If this is an issue, then the size of line[] can always be bumped to
LINE_MAX + 1.
Whilst here, fix a compiler warning when FULLDEBUG is defined.
Oh, and since deroff is called by /usr/bin/spell, this can cause unexpected
behaviour when running spell against files with long lines too.
--- deroff.c.dist Wed Mar 8 01:43:10 2023
+++ deroff.cTue Sep 19 09:31:29 2023
@@ -484,6 +484,10 @@
}
if (c == '\n')
break;
+ if (lp - line == sizeof(line) - 2) {
+ lp++;
+ break;
+ }
if (intable && c == 'T') {
*++lp = C;
if (c == '{' || c == '}') {
@@ -968,7 +972,7 @@
#ifdef FULLDEBUG
{
char*p;
- printf("[%d,%d: ", argno, np - cp);
+ printf("[%d,%ld: ", argno, np - cp);
for (p = cp; p < np; p++) {
putchar(*p);
}
Send international text with mail(1) - proposal and patches
Hello everyone,
Years ago I made a suggestion here about this, now that I am a little
less ignorant in C I dared with the patches below, they add a '-e'
option to mail(1) to pass a Content-Transfer-Encoding on the command
line. First you convert the text in "message.txt" to quoted-printable
or base64 (a simple shell script would do the job) and then you're able
to send international text doing this:
$ mail -s Hello -e quoted-printable recipi...@example.com < message.txt
Index: collect.c
===
RCS file: /cvs/src/usr.bin/mail/collect.c,v
retrieving revision 1.34
diff -u -p -r1.34 collect.c
--- collect.c 17 Jan 2014 18:42:30 - 1.34
+++ collect.c 19 Sep 2023 11:40:29 -
@@ -87,7 +87,7 @@ collect(struct header *hp, int printhead
* refrain from printing a newline after
* the headers (since some people mind).
*/
- t = GTO|GSUBJECT|GCC|GNL;
+ t = GTO|GSUBJECT|GENCODING|GCC|GNL;
getsub = 0;
if (hp->h_subject == NULL && value("interactive") != NULL &&
(value("ask") != NULL || value("asksub") != NULL))
Index: def.h
===
RCS file: /cvs/src/usr.bin/mail/def.h,v
retrieving revision 1.17
diff -u -p -r1.17 def.h
--- def.h 28 Jan 2022 06:18:41 - 1.17
+++ def.h 19 Sep 2023 11:40:29 -
@@ -158,12 +158,13 @@ struct headline {
#defineGSUBJECT 2 /* Likewise, Subject: line */
#defineGCC 4 /* And the Cc: line */
#defineGBCC8 /* And also the Bcc: line */
-#defineGMASK (GTO|GSUBJECT|GCC|GBCC)
+#defineGMASK (GTO|GSUBJECT|GENCODING|GCC|GBCC)
/* Mask of places from whence */
#defineGNL 16 /* Print blank line after */
#defineGDEL32 /* Entity removed from list */
#defineGCOMMA 64 /* detract puts in commas */
+#defineGENCODING 128 /* Content-Transfer-Encoding: line */
/*
* Structure used to pass about the current
@@ -173,6 +174,7 @@ struct header {
struct name *h_to; /* Dynamic "To:" string */
char *h_from; /* User-specified "From:" string */
char *h_subject;/* Subject string */
+ char *h_encoding; /* Content-Transfer-Encoding string */
struct name *h_cc; /* Carbon copies string */
struct name *h_bcc; /* Blind carbon copies */
struct name *h_smopts; /* Sendmail options */
Index: extern.h
===
RCS file: /cvs/src/usr.bin/mail/extern.h,v
retrieving revision 1.29
diff -u -p -r1.29 extern.h
--- extern.h16 Sep 2018 02:38:57 - 1.29
+++ extern.h19 Sep 2023 11:40:29 -
@@ -163,7 +163,7 @@ void load(char *);
struct var *
lookup(char *);
int mail(struct name *, struct name *, struct name *, struct name *,
- char *, char *);
+ char *, char *, char *);
voidmail1(struct header *, int);
voidmakemessage(FILE *, int);
voidmark(int);
Index: mail.1
===
RCS file: /cvs/src/usr.bin/mail/mail.1,v
retrieving revision 1.83
diff -u -p -r1.83 mail.1
--- mail.1 31 Mar 2022 17:27:25 - 1.83
+++ mail.1 19 Sep 2023 11:40:29 -
@@ -45,6 +45,7 @@
.Op Fl c Ar list
.Op Fl r Ar from-addr
.Op Fl s Ar subject
+.Op Fl s Ar encoding
.Ar to-addr ...
.Ek
.Nm mail
@@ -77,6 +78,8 @@ Causes
.Nm mail
to output all sorts of information useful for debugging
.Nm mail .
+.It Fl e Ar encoding
+Specify a Content-Transfer-Enconding on command line.
.It Fl E
Don't send messages with an empty body.
.It Fl f
Index: main.c
===
RCS file: /cvs/src/usr.bin/mail/main.c,v
retrieving revision 1.35
diff -u -p -r1.35 main.c
--- main.c 26 Jan 2021 18:21:47 - 1.35
+++ main.c 19 Sep 2023 11:40:29 -
@@ -103,6 +103,7 @@ main(int argc, char **argv)
struct name *to, *cc, *bcc, *smopts;
char *fromaddr;
char *subject;
+ char *encoding;
char *ef;
char nosrc = 0;
char *rc;
@@ -136,7 +137,8 @@ main(int argc, char **argv)
smopts = NULL;
fromaddr = NULL;
subject = NULL;
- while ((i = getopt(argc, argv, "EINb:c:dfinr:s:u:v")) != -1) {
+ encoding = NULL;
+ while ((i = getopt(argc, argv, "EINb:c:de:finr:s:u:v")) != -1) {
switch (i) {
case 'u':
/*
@@ -158,6 +160,10 @@ main(int argc, char **argv)
case 'd':
debug++;
break;
+ case 'e':
+ /* Set
