0

This is what I tried:

$ mailx -s "test email" cloud
Cc: 
"again and agina"
.
EOT

Or,

$ mailx -s "test email" cloud
Cc: 
"this is the first email"
<< EOT

But after pressing Enter nothing happens. Why?

Kusalananda
  • 333,661
Richard Rublev
  • 309

2 Answers2

6

There is nothing magical about the thee-letter-string EOT. You have probably seen it used as a delimiter in here-document redirections in shell scripts from time to time. Almost any word may be used as a delimiter for a here-document redirection, although it's customary to use a short-ish descriptive word written in all upper-case letters; so you could, for example, send a message with mailx by giving the utility the message on its standard input stream like so:

mailx -s 'test message' myself <<'END_MESSAGE'
This is the message.
Possibly on many lines.
END_MESSAGE

This would use mailx non-interactively to send an email consisting of two lines of text to the user myself. The body of the message is quoted, i.e., the shell won't try to expand variables etc., in it, due to the quoting of the initial delimiter ('END_MESSAGE').

However, from seeing the two commands in the question, you appear to want to use mailx interactively to type a message into the utility.

If you have had the dot option set in your ~/.mailrc file (set dot), then typing a single dot on a line by itself as you did in the first part of your question would end the message body and cause the email to be sent:

$ cat ~/.mailrc
set dot

$ mailx -s 'test message' myself
Cc:
This is the message.
Possibly on many lines.
.

Typing the lone dot and pressing Enter causes the message to be sent.

If you don't have the dot option set or if you have the nodot option set in ~/.mailrc, the message body is instead ended using Ctrl+D on an otherwise empty line.

Pressing Ctrl+D sends (commits, submits) the current line to the program waiting for input, and if the current line is empty, this will signal the end of input. This is true not just for mailx but for most programs reading interactive input from their standard input stream.

Using . on an empty line is also how you signal the end of user input in the ed editor when finishing entering text after issuing the i, a, or c command to insert, append or change the text in the current editing buffer. It wouldn't surprise me if mailx inherited this custom from ed.

Kusalananda
  • 333,661
2

As my unprivileged user I typed:

$ mailx -s "test email" root <<EOTx
> "this is the first email"
> EOTx
$

and a little while later:

Return-Path: <XXXXXX@XXXXXX.home>
X-Original-To: root
Delivered-To: root@XXXXXX.home
Received: by XXXXXX.home (Postfix, from userid 1000)
        id ADEF4C0CF994; Sat, 27 Aug 2022 20:32:56 +0100 (BST)
Date: Sat, 27 Aug 2022 20:32:56 +0100
To: root@XXXXXX.home
Subject: test email
User-Agent: Heirloom mailx 12.5 7/5/10
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20220827193256.ADEF4C0CF994@XXXXXX.home>
From: XXXXXX <XXXXXX@XXXXXX.home>
X-Evolution-Source: mbox:/var/spool/mail/XXXXXX

"this is the first email"

root's mail is directed to my unprivileged account.

Doneal's comment is accurate as far as it goes, however your final line of << EOT is the error in that case. It should have been EOT without the redirection.

  • 2
    Note that the three letters EOT are not special in any way other than that the "heredoc" is introduced and terminated with them. You could have more easily avoided the whole thing and used Ctrl/D to terminate mailx reading from stdin (the keyboard) – Chris Davies Aug 27 '22 at 19:47
  • 1
    Re. the last part, note that inserting a final line EOF wouldn't have helped them, since they didn't have the here-doc redirection in the command (despite a comment telling them to do that) – ilkkachu Aug 27 '22 at 20:09
  • "@doneal24 The same issue again", so it appears that they did try Doneal's first line. –  Aug 27 '22 at 20:12
  • 2
    I'm noting that the user is using mailx interactively in the question and that using a here-document would instead use the utility non-interactively (it would no longer prompt for the "carbon-copy" recipient list, for example, and variables etc. will be expanded by the shell if you don't quote the here-document). It may possibly be worth mentioning this. I don't know if it makes any difference whatsoever to the user. – Kusalananda Aug 27 '22 at 20:15
  • @Martin, perhaps they did try, but they're still missing the actual redirection. The comment suggests using mailx -s "test email" cloud << EOT, but the command they've added in the question is still mailx -s "test email" cloud. – ilkkachu Aug 27 '22 at 20:29
  • @ilkkach. The OP first gave the two examples. Then Doneal24 suggested putting the redirection in the right place. After which the OP replied to Doneal that it didn't work but didn't further edit the question. Hence I credited Doneal's response and moved from that position. Because you appeared confused I edited the sentence to clarify "in that case" for you. –  Aug 28 '22 at 10:54
  • @Martin, the initial revision (hover over the timestamps to see that actual times) of the question is timestamped 16:59, it only contained one example. doneal24's comment is timestamped 17:29, and the edit to the question that added the second example is timestamped 17:54 (and the reply comment at 17:53). Based on the timeline, it still seems to me that the edit was made in response to the suggestion in the comment. But the suggestion was implemented incorrectly. – ilkkachu Aug 28 '22 at 14:49
  • Regardless, just changing the << EOT to EOT in the second example in the question wouldn't help, as one would also have to add the here-doc redirection on the command line; it was missing from the sample run in the question. You added it here of course, but that statement in the last paragraph of this answer appears to ignore the other part of problem the attempt in the question had. – ilkkachu Aug 28 '22 at 15:01