BASH 2.05b/3.0/3.2 Mail Check Patch

Sometimes software doesn't do what users think it should. Bash has a mail checking feature that, by default, checks your mail spool file every 60 seconds (or 600 if you have POSIXLY_CORRECT set). You can disable this feature by unsetting your MAILCHECK environment variable or setting it to a negative value.

Even if you do this, bash will still check the timestamp and file size of your mail file when it first starts in interactive mode as well as when any of the MAIL, MAILCHECK, and MAILPATH environment variables changes value. The end result is that every time you start an interactive bash shell, your mail file is checked. For systems where the mail spool directory is mounted via NFS or some other network file system, this behavior can become a performance drag on both the client and server.

If you're a wireless laptop user, you don't want to wait for the automounter to mount the mail spool every time you open a shell window. Worse, if the NFS server goes down, you may not be able to log in to a client, even with a local account, because bash will hang on an I/O operation while trying to check your mail. Therefore, it is desirable to make bash do what users want it to do when they unset MAILCHECK or set it to a negative value. We don't want bash to examine our mail file at all unless we change the value of MAILCHECK back to a non-negative value. Here's a patch for bash 2.05b which does exactly that:

Ideally a bash maintainer would write a less klugey solution than this patch to fix the problem. The bash startup code is a bit convoluted and needs some cleaning up to do that. I tried to fix the problem by changing as little code as possible, but it remains an ugly hack.

bash 3.0 was released in August 2004. I had submitted my patch to the bash developers through Savannah in August 2003. The issue report was never assigned and all other reports at the time had not been assigned. Apparently, the developers want you to use bashbug to submit issue reports (I refuse to use bashbug for reasons not worth discussing here). bash 3.0 still exhibits the same problem, but my patch works with it even though it was based on 2.05b. Same goes for bash 3.2

It looks like Debian Linux applied my patch to its bash package in May 2004. Apparently at least one Debian user reported the problem the patch fixes.

After many years, bash 4.0 was released, appearing to fix the problem (I'm not completely certain). You may, however, still experience a similar issue if your system references pam_mail.so in the PAM configuration for login. Simply comment out the offending line.