ast
ast copied to clipboard
att
Remove mail related env vars
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.
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.
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.
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.
Not only are they required by POSIX, but they are in use as well. At least by this user.
@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.
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.
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.
@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.
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.
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.
@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
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.
@kshji No "server" depends on the ksh recognizing $MAIL and related env vars. That is because those those only affect interactive shells. That is, those shells that are connected to a tty. The feature being discussed is solely one that affects interactive use. And I still maintain that 98% of ksh users don't use or care about this feature.
@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.
Sorry, but which part of "use the Finder for a web browser" was hard to understand? I also use the Finder for VirtualBox, and I use the terminal for ksh. If it's the word "running" you are missing, then it seems you are simply choosing to misunderstand, to dismiss the comment. The same goes for your reply to the comment from @kshji. A "server" is a machine that one occasionally log in to interactively, to use or maintain. An admin (or other user for that matter) logging into a server would want to be notified of new mail, with as little fuss as possible. All of the servers (Unix machines) that I have access to are headless, with the sole exception of my desktop system.
Well, you can choose to remove the existing facility to detect new mail from this shell if you want, on whatever basis you feel you can come up with (e.g. "I haven't used it in a long time"), but the few people that seems to care enough to actually follow this conversation don't seem to agree with you. Retaining the effect of being notified of new mail by default would therefore be greatly appreciated.
It's been over a decade since I've used MUAs like mail, mh, or mutt. When I did use those MUAs I did use the ksh new mail notification mechanism. So I decided to do some empirical tests of its behavior and found, unsurprisingly, that it does not behave as documented and is at best a heuristic that works most of the time but is prone to false negatives. In fact, the behavior is so bad that it can't reliably be used to monitor changes to non-mail spool files.
Sorry, but which part of "use the Finder for a web browser" was hard to understand?
Nothing other than the fact the macOS Finder app isn't usable as a web browser. I also understand what the term "server" means. I've been a SysAdmin and DBA (I started programming computers in 1978). I maintain several local headless VMs specifically to test the work I do on projects like this one which I connect to via SSH.
Note that when you log into a "server" ksh won't tell you if the local mail spool file has new mail since the last time you logged into the server. It will only tell you if the modification timestamp changes after you start the shell. And after that it will only alert you of new mail if the size of the file is larger since the last time it stat()'d the file. Which means that if use a MUA like mail to look at your mailbox, delete a message, and a new message arrives that results in the mbox being smaller than its old size ksh won't alert you about the new mail.
It's been over a decade since I've used MUAs like
mh, ormutt. When I did use those MUAs I did use the ksh new mail notification mechanism. So I decided to do some empirical tests of its behavior and found, unsurprisingly, that it does not behave as documented and is at best a heuristic that works most of the time but is prone to false negatives. In fact, the behavior is so bad that it can't reliably be used to monitor changes to non-mail spool files.
The only person in this thread interested in monitoring non-mail spool files seems to be you. I use mail and mutt daily. In fact, I read this thread in mutt, and reply in Chrome (running in the macOS Finder, to be clear).
Sorry, but which part of "use the Finder for a web browser" was hard to understand?
Nothing other than the fact the macOS
Finderapp isn't usable as a web browser. I also understand what the term "server" means. I've been a SysAdmin and DBA (I started programming computers in 1978). I maintain several local headless VMs specifically to test the work I do on projects like this one which I connect to via SSH.Note that when you log into a "server" ksh won't tell you if the local mail spool file has new mail since the last time you logged into the server. It will only tell you if the modification timestamp changes after you start the shell. And after that it will only alert you of new mail if the size of the file is larger since the last time it stat()'d the file. Which means that if use a MUA like
Well, that last bit certainly seems like a bug then. The shell should inform the user of new mail when the $MAIL file, or any of the files referenced by $MAILPATH, are created or when their last modified timestamp changes. The size of the file(s) is irrelevant.
The shell should inform the user of new mail when the
$MAILPATH, are created or when their last modified timestamp changes. The size of the file(s) is irrelevant.
Ksh has no knowledge of the content or structure of a local mail box file. That is the crux of the problem involving this feature. Ksh simply assumes that if the modification timestamp changes after the current shell process starts monitoring the file that means new mail has been delivered. After that event it only reports new mail has been delivered if the size of the file is larger since the last time it did a stat() of the file.
The problem with simply checking if the modified timestamp changes is that it results in false positives. Consider what happens if you delete a single message. The mtime of the file changes and the size of the mbox shrinks. This is why ksh deliberately checks if the size of the mbox grows (at least after the first time it checks the status of the file).
This mechanism is fundamentally broken from a correctness viewpoint. Yes, it works well enough in practice. But as a software engineer such heuristics offend my sensibilities unless the limitations are clearly documented.
If this were implemented via a ksh script function that is run just before a new prompt is about to be written then it could theoretically do something much more intelligent. Such a ksh script function could be customized by the distro or user. It could invoke the MUA to ask if new mail is present rather than relying on the crude heuristic of testing if the file has been modified or increased in size. If that isn't possible it could still fall back to the crude heuristic of the existing implementation. Regardless, this has no business being implemented in the core C code.
and reply in Chrome (running in the macOS Finder, to be clear).
No, you are not. I hate to be pedantic but in macOS the Finder app is just that: an app. The Chrome app does not run in the Finder app. Both run in the macOS window manager/desktop.