Bsd-mailx

[Karren Bangura]

Im getting a warning from this executable along with /usr/bin/mail. Apparently, the latter is a symbolic link to /etc/alternatives/mail which in turn is a symbolic link to the former. Is it part of the official Ubuntu package?

The symlinks are a normal part of the "alternatives" system used by the packaging system. In some cases, the same commands are provided by multiple packages. To handle this, each package installs their version of the command with a unique name and the common command name is symlinked to one of the versions. The symlinks can be updated using the update-alternatives utility.

Now rather than directly symlinking from /usr/bin/mail to /usr/bin/bsd-mailx, the connection is made through a second symlink in /etc/alternatives. This allows different systems that share a common /usr but separate /etc to pick different alternatives.

I tried apt-get remove bsd-mailx and apt-get purge bsd-mailxto see if with apt-get install bsd-mailxI would get the default configuration screen of it, but don't get it. How might I get to completely remove bsd-mailx to get once again the configuration screen, or how to toggle the configuration screen somehow as when it is first installed to apply a different configuration.

Search in specific suite:[focal][focal-updates][focal-backports][jammy][jammy-updates][jammy-backports][mantic][mantic-updates][mantic-backports][noble][noble-updates][noble-backports][oracular]Limit search to a specific architecture: [i386] [amd64] [powerpc] [arm64] [armhf] [ppc64el] [riscv64] [s390x] You have searched for packages that names contain bsd-mailx in all suites, all sections, and all architectures.Found 1 matching packages.

The old bsd-mailx (same as RHEL 5) package is available (unsupported) for RHEL 6 via EPEL; however, note that any scripts that require the old bsd-mailx package should be updated to use the new mailx (bsd-mailx will not be available in RHEL 7 and later)

I have begun acquainting myself with cron jobs in Linux, and I want to be

able to send myself local emails inside Linux Mint/VirtualBox if the

cron job was successful or not. It is actually quite easy, but not so easy

to find all the correct information! But I finally did!

At first I thought that I should send an email from Linux Mint Terminal to my

actual Gmail email. I installed postfix and then mailutils because I was

trying out the mail command and needed to install mailutils if I wanted to

use it.

After some investigation, I found it to be too complicated and not even

necessary. There is a simple built-in Linux (Mint)

mail user agent program called mailx. According to

Geeks for Geeks,

The mailxutility is an enhanced version of the mail command. Along with

the functionality provided by the original mail command, it provides extra

features like the ability to send attachments by using the -a (-A actually)

flag. The mailx command is available from a variety of different packages:

bsd-mailx, heirloom-mailx, and mailutils.

I ended up using the mail command, but mailx is used in the same way. They

are both available with the mailutils package, which is what I installed in

order to be able to use the mail command. What is interesting is that mail and

mailx are two separate commands, and they have their own bin. But according to

Geeks for Geeks,

In other words, they can be interchangeable. When I did try to send an email

to my Gmail account, of course it did not work. I don't think I could

accomplish that these days from a local email address inside my

Linux Mint/VirtualBox instance. So that's why I decided to stick with this

approach since I am working inside of a virtual machine anyway. It will be

interesting to find out if I can send an email to Gmail in macOS when I set up

cron jobs there. That's for another time!

It is also possible to send emails to other users on the system. For

example, I could send an email to user magdala. Then I could take

advantage of things like attaching a file to the email. Let's say I run

the following in Terminal:

Since I am sending the email via Terminal, and it is being received by

user magdala also via Terminal, I have to stick to what the CLI

(Command Line Interface or Terminal) understands. So for the Terminal

(bash specifically) to interpret the contents of my history.txt file

properly, I use the cat command which then becomes the stdout of the

mailx command, thereby redirecting the stdin

cat /home/maria/Desktop/history.txt of mailx as stdout of mailx to

magdala@maria-VirtualBox.

And if the user magdala wants to save the contents to a file, she can

copy it from the email body and paste it into a new .txt file. It is

not perfect on the receiving end, but for cron job notification purposes,

for example, it would work just fine. As well as .txt files containing

log information, for example, that are not too lengthy.

3a8082e126