Remove mail related env vars

[krader1961]

Once we manage to publish a new stable release based on the ksh93v- work in progress we should embark on some cleanups that involve removing legacy features no longer relevant. Such as eliminating the recognition of the MAIL, MAILCHECK, and MAILPATH env vars. Those have not been relevant for a decade or more. With the possible exception of people who will never upgrade their software but we don't care about that set of users.

[siteshwar]

What is the motivation for this clean up ? Both bash and ksh support these variables and I think they should be retained. They should not be removed without discussions with the community.

[krader1961]

Removing obsolete features in order to simplify the code base is a good thing. There may be people using this feature to monitor arbitrary files for changes. But using it to monitor your mailbox hasn't been relevant for a very long time. And there are better mechanisms for monitoring arbitrary files for changes.

[siteshwar]

These variables are required by POSIX. You can read about them here.

[DavidMorano]

These variables are required by POSIX. You can read about them here.

Not only are those variables required by POSIX, they are not much of a burden on the code either. I would not be in favor of removing that feature. The maintenance of those variables is tiny compared with other issues to deal with. The code base must be starting to look very good if we think it is time to rip out some POSIX required feature.

[andkaha]

Not only are they required by POSIX, but they are in use as well. At least by this user.

[krader1961]

@kusalananda I'm betting you are using those vars to monitor files unrelated to the original intent. That is, monitoring mail spool files. Even when this mechanism was relevant, and I used it myself for several years, once the X Window system became available I, and everyone I knew, switched to X Window widgets for monitoring our mail spool files. If you're using these env vars to monitor changes to arbitrary files (i.e., unrelated to local mail delivery) you are using the feature in a creative manner. Kudos to you for thinking outside the box. But the reality is that there are better, cheaper, ways to do so.

@siteshwar and @DavidMorano Thanks for the link but I'm aware that POSIX requires these env vars. Removing them only affects interactive use of the shell. I am not advocating breaking POSIX compatibility where doing so would break an existing script. That is not the case for these vars. POSIX simply codified the behavior of the most popular shell(s) at the time it was written. That does not justify fetishizing the standard especially when aspects of the standard are no longer relevant.

Note that I am not proposing removing support for these vars in the immediate future. This would be done only if we ever manage to get the code into good enough shape that distros would be willing to ship it as the successor to ksh93u+. At that point we would be able to talk about a subsequent "major" release that broke some backward compatibility in areas like these env vars. This issue is a placeholder to remind people to consider such changes.

[krader1961]

Also, it should be obvious, but apparently isn't, that the AST team broke backward compatibility several times. But because they were locked into a release version paradigm that required every release ID to have a ksh93 prefix followed by a letter those backward incompatible changes were obscured. Which is one reason why I have argued vehemently for switching to semantic versioning.

[siteshwar]

This change will break POSIX compatibility, backward compatibility and user experience. I am personally against any such change.

@krader1961 In general if anything goes against POSIX, it would be a good idea to discuss it on austin-group mailing list. I don't think we should use ksh as a vehicle to push any change against POSIX.

[andkaha]

@kusalananda I'm betting you are using those vars to monitor files unrelated to the original intent. That is, monitoring mail spool files. Even when this mechanism was relevant, and I used it myself for several years, once the X Window system became available I, and everyone I knew, switched to X Window widgets for monitoring our mail spool files. If you're using these env vars to monitor changes to arbitrary files (i.e., unrelated to local mail delivery) you are using the feature in a creative manner. Kudos to you for thinking outside the box. But the reality is that there are better, cheaper, ways to do so.

Sorry, no. I use them to monitor my incoming mail spool file(s). I do this on OpenBSD, macOS and on Linux. I don't run graphical interfaces on the non-macOS machines, and on macOS only use the Finder for a web browser. The mail on macOS and Linux is mainly cron output (but essential that I get notified about through the shell). The real mail comes in on my OpenBSD machine, which I connect to through SSH (so no need for X11).

I haven't used a desktop manager on a free OS, for many years as I find that they tend to change too much too often and only gets in my way (and I would only run a full screen xterm with tmux anyway).

As far as I know, a graphical user interface is not mandated by POSIX nor required to run a POSIX system. I do concede that it seems slightly arbitrary of POSIX to even mention MAIL and related environment variables, but it does, and I use them for their intended purposes.

[dannyweldon]

As @kusalananda has said, these variables are still being actively used on servers, because local mail is necessary for system accounts (unless redirected). I can't remember how many times I have logged into a server via ssh and as root (albeit using bash) I see this:
You have new mail in /var/spool/mail/root
which makes me think, hmm, what's going on here? From there I can run the mail program or simply run less $MAIL and jump to the end to quickly see what was just sent.
I noticed that on my Linux desktop though, that $MAIL is not set, obviously because I am using a desktop mailing program to read mail, but if I su to root, voila, $MAIL is set to /var/mail/root.

[kshji]

We are talking about properties of ksh93. Of course there are other tools which you can do same result.
Every properties of ksh93 is possible to remove. There are other tools which you can use. BUT there are lot of servers which use ksh93 to do so many different kind of jobs. We can't know how they use current properties. It's dangerous to remove or change properties. If you remove some properties (OR change it), you destroy something in some servers. It have to be very good reason to change current properties. Add on is not problem.

[krader1961]

@kusalananda It seems like English is not your native language. Nonetheless, you can't use the macOS Finder program as a web browser so I don't understand what point you were trying to make with that statement. Also, the fact you don't rely on "desktop manager" environments is not really relevant.

@dannyweldon I still don't see any value in retaining this feature. I did use this feature long ago when I used mailx, mh, mutt, and other mechanisms that depended on local mailboxes. You said

I noticed that on my Linux desktop though, that $MAIL is not set, obviously because I am using a desktop mailing program

No, that is not why that env var is not set in your primary account. It appears to be a quirk of the Linux PAM behavior that it is not set in your GUI terminals until you su.

I still contend that today the MAIL, and related env vars, are mostly irrelevant and should not be a feature implemented in the core (i.e., C) code. It should be implemented via a ksh function that is run when a new prompt is about to be issued. People who want this can then register that function to be run when a new prompt is about to be emitted. Sadly, ksh doesn't support such a function but it should.

Also, this mechanism is fundamentally broken.