Dominic Raferd wrote in <[email protected]>: |On 05/07/2021 15:27, Steffen Nurpmeso wrote: |> Dominic Raferd wrote in |> <[email protected]>: ... |>|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?
Oh sorry, i have no idea of Ubuntu. I know Paride does a good job and even supports backporting on Debian (thought the last update he did not backport i think). If you have make and compiler it is just "make tangerine". Google says Enabling Backports Manually Make sure the following line is in your /etc/apt/sources.list (substituting your release for trusty): deb http://archive.ubuntu.com/ubuntu trusty-backports main restricted universe multiverse There is also something graphical, but i really do not know. ... |>|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 ... |>|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. It sounded mysterious with headers in Windows format and Body in Linux format. Otherwise i would claim the program backing your sendmail(1) is broken, since it silently converts a Windows text file into a Unix one. I really had to look into the standard, i wonder wether the truly right thing would be to convert to MIME and use a content-transfer-encoding in order to be able to restore to DOS format or not. ..Thinking about it, likely not. It may be ok to simply treat this as a mail message and therefore just ensure lines remain lines. Well. I mean for -t and only -t we could do this without too many hurts, adding one more flag to this already-too-big input consuming code would not be that dramatical. Should maybe not be more than a twenty line patch, all in all. |I will continue with my workaround. Well if you use this MUA until at least v14.10 you really have to, then. Ciao. --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)
