mailx(1) is a hard link to mail(1) in base system.

tembun

tembun

Hi everybody!

I'm running FreeBSD 13.4 and I see that /usr/bin/mailx is just a hard link for /usr/bin/mail:

$ ls -l /usr/bin/mail /usr/bin/mailx
-r-xr-xr-x 3 root wheel 105896 Sep 13 11:12 /usr/bin/mail
-r-xr-xr-x 3 root wheel 105896 Sep 13 11:12 /usr/bin/mailx

As far as I know, mailx (according to its port mail/mailx) is a mail(1) with some extra extensions. Piping messages (| command) is one of those I lack in mail(1). I checked out if mail(1), that is shipped as part of a base system, allows piping and doesn't. But, I found, that mailx is in the base system too, so I tried it and... it doesn't support piping either ('cause they're hard links). Well, according to mail(1) manpage (which is the same for mailx(1)): "Usually, mail is just a link to Mail and mailx, which can be confusing.". But if mail(1) is a link to mailx(1) then it should have a piping feature, shouldn't it?

OK, I just decided to install mailx from ports, but I encountered an issue: when I type `which mailx` it says me that it is in /usr/bin/mailx (which, as we've just seen, does not have mailx features somehow). I tried to invoke /usr/local/bin/mailx at it works fine.

So, guys, I got 2 questions actually, maybe some of you know the answers:

1. Why doesn't mailx(1), that is in the base system, actually have mailx features (piping at least)? In other words, why don't mail(1) and mailx(1) differ?

2. How shall I replace system mailx (/usr/bin/mailx) with one from ports (/usr/local/bin/mail) properly? I mean, would linking a system program to a local one be a good idea?
2.1 Sort of off-topic, but I also wonder about general idea of question 2: is it a (a proper, maybe) way to replace some base program (say, ed(1)) with its ports version or even with its version compiled from source? How would you guys do it?

Thank you!

Best,
Artem
 
Charlie_,

Thank you for useful links!

Well, I've tried mail/mailx and it works just fine for me, so I'm gonna to stick with it. Till I find it doesn't fit my needs.

I'm more like wondering why mailx, which is in the base doesn't have thoose extensions it ought to have as mail*x*? If it doesn't actually differ from ordinary mail(1), what's the matter of that "x" in the name then?

Artem
 
artembunichev said:
[…] If it doesn't actually differ from ordinary mail(1), what's the matter of that "x" in the name then? […]
Click to expand...
This is a question you better direct to the Sendmail people. Frequently if there is the same binary known by multiple file names, the executable binary changes its behavior based on the file name it was started as. Examples are /rescue/* or /usr/bin/[efr]grep vs. /usr/bin/grep.

In this particular case, though, I could not find anything conclusive in /usr/src/contrib/sendmail and the manual page of mail(1) actually lists it under § bugs (i. e. undesired behavior):
Usually, mail is just a link to Mail and mailx, which can be confusing.
Click to expand...
 
Kai, thanks for your reply!

Yeah, I also thought that mail(1) should treat this "x" in the end the same way egrep(1) does. But yeah, as you've said, it doesn't seem to be the case. Well, it's quite a funny situation; maybe lots of different standards and all that caused it.
 
Guys, I have one more question about all that.

As we've seen, even though this mail-mailx stuff is funny, but it is in the base system. And I want to replace /usr/bin/mailx with mailx, installed from ports (actually, want to make /usr/bin/mailx a symlink to /usr/local/mailx) and make the same with /usr/bin/mail (just to type "mail" instead of "mailx" every time).

But, this is a base system and I don't really want to "mess" with it, you know. Well, I can do the thing I want and have a original base system mail(1) source code in /usr/src, but if I rebuild the world from source it will replace my mail symlinks with mail original binaries back again, won't it? And the same thing with man pages: base system man pages are picked first than ones installed from ports, so I honestly don't know how to deal with this either (don't want to remove original mail(1) manual).

So, guys, could you please help me, maybe just give a basic idea what can be done in order to do what I want. Probably, some of you have already encountered similar issue or something? Any advise is really appreciated.

Artem

P.S. Probably, I should've posted this as a separate thread, but I wanted to preserve some original context of this topic.
 
artembunichev said:
Well, I can do the thing I want and have a original base system mail(1) source code in /usr/src, but if I rebuild the world from source it will replace my mail symlinks with mail original binaries back again, won't it?
Click to expand...
If you're building from source you could set WITHOUT_SENDMAIL in src.conf(5).

Code: 
       WITHOUT_SENDMAIL
	       Do not build sendmail(8)	and related programs.
Make sure to also do make delete-old or else the 'old' stuff is going to linger around.

Code: 
     delete-old           Delete obsolete base system files and directories
                          interactively.  When -DBATCH_DELETE_OLD_FILES is
                          specified at the command line, the delete operation
                          will be non-interactive.  The variables DESTDIR,
                          TARGET_ARCH and TARGET should be set as with “make
                          installworld”.
build(7)

On 13.x dma(8) was added and sendmail(8) was kept as the default. On 14.x this switched making dma(8) the default while sendmail(8) is still included. With 15 the plan is to remove sendmail(8) entirely. On your 13.x you could rip off the bandaid now, switch to dma(8) and remove sendmail(8).
 
SirDice said:
If you're building from source you could set WITHOUT_SENDMAIL in src.conf(5).
Click to expand...
Finally I did it :)

I set this option, it did remove all the sendmail(8) stuff, but /usr/bin/mail and /usr/bin/mailx are still here. Their timestamps were updated after building the world (so it means they were compiled) and they don't appear in the output of make check-old.

In src.conf(5) I also found WITHOUT_MAIL option, but it implies WITHOUT_DMAGENT that removes dma(8), which I need.

So, it seems there's no way to prevent standard mail programs from being built?
 
You must log in or register to reply here.
Back
Top