On 05/07/2021 15:27, Steffen Nurpmeso wrote:
Hello.
Dominic Raferd wrote in
<322b2796-edbe-6675-6966-8612ef6e0...@timedicer.co.uk>:
...
|because of its support for mailing attachments and for the -t option.
The -t option is rudimentary until the long planned MIME rewrite
is going to happen. It cannot be compared with "sendmail"'s -t,
because that can swallow an email message, whereas mail's -t can
only swallow a plain text template with some leading headers.
|One small issue I have with it (which may well be because of my lack of
|understanding) is that when used with -t, it does not seem to work
|correctly with a source file with lines terminating with CR+LF
|(Windows-style).
|
|Example (environment: bash on Linux [Ubuntu 20.04]):
|
|1. Send e-mail with CR+LF line-endings using sendmail (postfix v3.4.13)
|(outcome perfect):
|
|# echo -e "To: Jeremy Fisher <$(id -un)@localhost>\nSubject: Testing
|$(date +"%F %T")\n\nTesting"|sed 's/$/\r/'|sendmail -t
|
|2. Send same with s-nail v14.9.15, 2019-08-17 (built for Linux):
Yes, pretty old and unfortunately distant from unbuggy.
This is the version in Ubuntu 20.04. Is there a safe/easy way to install
latest'n'greatest s-nail in place of it?
|# echo -e "To: Jeremy Fisher <$(id -un)@localhost>\nSubject: Testing
|$(date +"%F %T")\n\nTesting"|sed 's/$/\r/'|s-nail -t
|s-nail: Not a header line, skipping: $'Testing\r'
|
|- we get the above warning message and, worse, the email appears at the
|other end with bad format 'To:' header:
|
|To: "Jeremy Fisher =?us-ascii?B?DSI=?= <user@localhost>"@mydomain.tld
|
|3. If we send the same email via s-nail with LF line endings instead of
|CR+LF (i.e. remove the sed command from the above example) there is no
|warning and it appears perfect at the other end.
|
|Am I doing something wrong? I realise that CR+LF line endings are not
|'normal' in Linux environment but I think that s-nail should handle them
You are feeding in a data file, POSIX says
3.403 Text File
a file that contains characters organized into zero or more
lines. The lines do not contain NUL characters and none can
exceed {LINE_MAX} bytes in length, including the <newline>
character. Although POSIX.1-2017 does not distinguish between
text files and binary files (see the ISO C standard), many
utilities only produce predictable or meaningful output when
operating on text files. The standard utilities that have such
restrictions always specify ``text files’’ in their STDIN or
INPUT FILES sections.
I would use printf 'bla\r\n' and avoid the sed(1). Or use tr(1).
Hm.
|perfectly, seamlessly and silently (like postfix's sendmail).
It is far from perfect, seamless and silent.
It seems utter rubbish as it enables this attitude.
|My workaround is to remove CRs from header lines and the succeeding
|blank line before passing source file to s-nail, but this is ugly.
Not creating those sequences at first to turn valid text files
into Windows 8-bit aka DOS ones at first glance may be a better
option. Earlier there were dos2unix and unix2dos programs iirc.
Having said that, and since i am totally opposed to mutilating
user data, we now at least keep the line ending type intact for -a
ttachments, for example, after the v15 rewrite we have a different
code flow and might be able to not only preserve newline type when
saving edited files. But i will not hack it into the current
state of affairs. Sorry.
OK understood. Just to explain: the reason I have CR+LF line endings in
real life (unlike the reproducible example I gave in my message) is that
such text files come from Windows (or even DOS) machines.
I will continue with my workaround.
