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. |# 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. --steffen | |Der Kragenbaer, The moon bear, |der holt sich munter he cheerfully and one by one |einen nach dem anderen runter wa.ks himself off |(By Robert Gernhardt)