mail sends redirected text file as attachment, should be body
 

On our old RHEL 5 server, this line sends the file as the body:
Edit 1: sendmail-8.13.8-10.el5_11.x86_64

On our new Oracle Linux 6.6, the same line sends the file as an attachment. I specifically tried mailx with the same syntax, no joy. I found the thread "mail sends a .dat file instead of text in body", from which I tried dos2unix on a sample log file. The converted file was also sent as an attachment. (Actually, I'm not convinced dos2unix had to make any changes in the file.)
Edit 2: sendmail-8.14.4-9.el6 (x86_64)
Edit 3: Also tried this, no joy:
This arises from the behavior in a script, but my testing is at the command line, so I'm confident I know what the command contains.

That is the normal behaviour for both mail and mailx.

To send an attachment you need to format the mail to be using attachments, and that requires other tools.

Unfortunately every time I settle on using some tool to send files as attachments, a couple of years later I find that tool no longer readially available! I got so sick of it I wrote a script to attach files (text or binaries) to raw mails using plain test tools, and sent them using sendmail (or whatever is pretending to be sendmail). I would not however NOT like to inflict the resulting script hell on to anyone else!

Tools I have used in the past (found in obsoleted code blocks on my mailfile script)...
mhbuild
metasend
and others I no longer even try to use.

More manual tools used to create mime attachments
file (for mimetyping, but parsing normal output and directly using file -bi )
b64encode (to encode binary files)
uuencode (yes I have been mailing files around long before mime types or even the web existed)


Example from my script to send mail generated using mhbuild


Example using metasend (which calls sendmail itself), is much easer, if you can find a copy.

My plain text sender is much more complicated (though still very linear in processing) as it also has to generated content_id's and boundary lines, and b64encode binary files, if needed.


That should give you a start for your own mailfile script. And yes the scripted form does work!

it seems the problem of the OP is quite the opposite: he does not want attachment, but body.
Since incantation of mail and mailx both yield the same result, I can only assume this is somehow done with an option in /etc/mail.rc (or another config file)

See manpage of mailx(1)

Normally this is a problem with encoding. If the contents of the mail use characters from another charset, then mailx will assume it's binary and put it into an attachment instead.

Thank you all for the responses. Sorry to be slow getting back to you. Someone updated my priorities temporarily...

@Ramurd: You are correct. The problem is that we're getting an attachment. We need it to be the body.

@fmattheus: The content of the file seemed to me to be the logical problem. However, it is entirely the redirected output of the commands executed a shell script. I'll include the attachment content here:

I understand that including it doesn't necessarily answer the question of its encoding in the actual file, but shouldn't standard output redirected from shell commands all be the same? Or am I thinking too simplistically? If I open the log file in 'gedit' on the server, then do File->Save as..., it shows the Character Coding: as Unicode (UTF-8). Not sure that proves anything, either.

Attaching copy of the actual log file for the above listing, as well as the script (redacted).

Thanks again!

Turns out, the gedit in Oracle Linux isn't so hot at showing the actual characters. vi on the same machine showed the ^M carriage returns.

And the attempt to use dos2unix failed, apparently because it doesn't handle ^M^M. Unhappily, that's what's in the file in about 4 places. I know where they're originating, now that I found them, but root cause correction is dependent on a 3rd part.

Guess I'll have to add some 'tr' processing the script before the mail command.

Thanks very much to you all, and especially to fmattheus for reinforcing my original feeling that it was caused by bad characters.

Good job finding the problem!

Ya, gedit tries to be too smart sometimes :) Even vi can hide some similar problems. A great tool for finding special characters in files is 'cat -v'

You could even use the following command to find the difference vetween the file itself and the file ran through cat -v to only print the lines that have special characters.