Re: This maybe off topic, but could somebody tell me what i am doing wrong?

[Christian Kivalo]

On 2015-10-21 01:51, John Allen wrote:

I have not looked at the code, so I am guessing, but it seems that
mail/mailx hadle a continuous block of text differently to a
multi-line block. I am not competent to decide if the as it should be
or not.


I have a script that checks for various available updates and the 
results are written to a file whose contents i redirect to mailx and 
that works well with multiline text


mailx -n -s "Subject" -r f...@example.com t...@example.net <$file


I don't recall why i chose this approach but it could be that i was 
having the same issues with pipeing to mailx


Regards
Christian


thanks everyone
John A

Re: This maybe off topic, but could somebody tell me what i am doing wrong?

[John Allen]

That is in fact what is installed. Mail and mailx are symlinks to 
heirloom-mailx.

Re: This maybe off topic, but could somebody tell me what i am doing wrong?

[Christian Kivalo]

On 2015-10-20 12:38, John Allen wrote:

That is in fact what is installed. Mail and mailx are symlinks to
heirloom-mailx.


True, symlinked to the same binary.

Just tried your initial command. The resulting email has the text 
"message text" in the body when run as


echo "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r 
f...@example.com t...@example.net


but i get the same error as you when i run the command

echo -e "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r 
f...@example.com t...@example.net


mailx seems to base64 encode the message text because of the \r?

The difference between these two invocations in mail headers is:

echo without -e
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

echo with -e
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64


regards
christian

Re: This maybe off topic, but could somebody tell me what i am doing wrong?

[John Allen]

I did a few test today.
The results seem to show that its not the -e option in echo that changes 
things.
If I leave the -e parameter in place, but do not insert any escaped 
characters in the message - things works as I had expected and the 
message is sent "correctly".
If on the other hand I insert an escaped character into the message I 
get the error "This message has attachments which were lost".

Removing the -e option solves the problem in either case.
I have not looked at the code, so I am guessing, but it seems that 
mail/mailx hadle a continuous block of text differently to a multi-line 
block. I am not competent to decide if the as it should be or not.


thanks everyone
John A


On 2015-10-20 10:07 AM, Christian Kivalo wrote:

On 2015-10-20 12:38, John Allen wrote:

That is in fact what is installed. Mail and mailx are symlinks to
heirloom-mailx.


True, symlinked to the same binary.

Just tried your initial command. The resulting email has the text 
"message text" in the body when run as


echo "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r 
f...@example.com t...@example.net


but i get the same error as you when i run the command

echo -e "message text \r" | /usr/bin/mail -s "Server xxx - Alert" -r 
f...@example.com t...@example.net


mailx seems to base64 encode the message text because of the \r?

The difference between these two invocations in mail headers is:

echo without -e
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

echo with -e
Content-Type: application/octet-stream
Content-Transfer-Encoding: base64


regards
christian

Re: This maybe off topic, but could somebody tell me what i am doing wrong?

[John Allen]

That should say echo -e "message text \r" | 
Sorry about that

Re: This maybe off topic, but could somebody tell me what i am doing wrong?

[Christian Kivalo]

Am 20. Oktober 2015 02:58:43 MESZ, schrieb John Allen :
>That should say echo -e "message text \r" | 
>Sorry about that

I'd recommend you install the package heirloom-mailx, it's much more flexible 
in what you can do with it.

Regards
Christian