After wading through substantial non-sense, Pat Hayzlett points out the answer here.

The problem in a nut shell is that mySQL 4.1 changed their password hashing and now store the passwords of database users in 40 chars instead of 16 as formerly. A number of clients cannot handle these wider passwords, including recent versions of php.

This is a public service announcement for the desperate. Normally Google is fairly effective at pointing out the solutions for very specific problems such as this, but it took a while for me to wade through the dross. If you are having this problem, follow the links. In the comments section at dev.mysql.com are instructions for modifying your php installation.

In that light emacs is a somewhat heavy tool, but I have become accustomed to it and there are frequently tasks that emacs can do, that would be much harder with any other set of tools, such as cutting a particular rectangle out of the middle of a text file, or the kind of processing that is possible with a particular query-replace-regexp or keyboard macro. Moore’s Law has solved the only issues that I ever had with emacs, I can now run it on every computer that I own. In any case, I have been using emacs off and on for almost 20 years as my programming environment. I keep trying other tools and environments, but I always end up returning to emacs.

The one set of infelicities about using emacs that were still causing me to occasionally drop into vi(m) were that I hadn’t managed to configure emacs to start up correctly in all of the different situations in which I needed to use it. I use emacs in a terminal window when connected to my Linux server. Sometimes that window is direct ssh, so it supports X-forwarding, to the X-server that I may have running on my local computer. (I use X-win32.) Sometimes I am running emacs on my local computer, editing both local and remote files. And most problematically sometimes I am deep in some other tool and relying on the value of my shell EDITOR variable to determine what editor to start up.

The issue is that each of these situations has two alternatives: when I have already started emacs, and when I haven’t. When I have already started emacs, I want to use that existing emacs so that I can take advantage of being able to access the other windows that I have open, refer to a man page, etc. There is a tool to do that, if you start the first instance of emacs that you open as a server, then later instances can connect to that server with the emacsclient command. I use gnuclient on Windows which solves these problems there, but I still have problems when on Linux.

The problem is that if I defined my EDITOR as emacsclient, then the command would fail half the time because I hadn’t first started the server. If I defined the EDITOR as emacs (the server) then the command failed the other half of the time.

Christoph Pfisterer posted about 85% of the solution to my problems here. He wrote a set of scripts to test for the definition of the DISPLAY variable, the universal indicator for the presence of X, and the file that the emacs server uses, and launching plain terminal emacs, emacs server, or emacsclient. In the last two cases, the script launches to X and then returns to the command line immediately.

A second script, ew, will not return immediately in the last two cases. This version is for the case where the script is called from a tool like less or crontab, which wants to get the return from the script.

Actually Christoph’s version of the script will not return normally until the emacs exits in the case where there is not currently a server running. I made a simple modification to his code to handle this case. Here is the full script, tested under bash on Linux.

!/bin/sh EMACS=emacs EMACSCLIENT=emacsclient if [ -f $HOME/.emacsconfig ]; then . $HOME/.emacsconfig fi if [ -z "$DISPLAY" ]; then exec $EMACS "$@" else tempuid=`id -u` temphost=`hostname` if [ -e "/tmp/esrv$tempuid-$temphost" ]; then exec $EMACSCLIENT "$@" else exec $EMACS & while [ ! -e "/tmp/esrv$tempuid-$temphost" ] ; do sleep 1 ; done $EMACSCLIENT "$@" fi fi

This is the change that I made:
17c17,19 < exec $EMACS "$@" --- > exec $EMACS & > while [ ! -e "/tmp/esrv$tempuid-$temphost" ] ; do sleep 1 ; done > $EMACSCLIENT "$@"

Christoph’s code was launching emacs and was waiting for it to return before returning control. I modified it to launch emacs in the background (you might want or need to pass the parameters -f server-start, to loop until emacs opens the socket, and then to launch the emacsclient with the appropriate arguments, waiting for the return of the client, but leaving the server running.

My small modification solves the remaining 15% of my problem. Thanks to Christoph.

I suddenly started seeing a warning when creating or deleting a user:
[root@server root]# adduser newuser configuration error - unknown item 'PASS_MAX_AGE' (notify administrator) [root@server root]# userdel newuser configuration error - unknown item 'PASS_MAX_AGE' (notify administrator)

The resources of Google were no help.
man adduser showed me the following config files
FILES /etc/passwd - user account information /etc/shadow - secure user account information /etc/group - group information /etc/gshadow - secure group information /etc/default/useradd - default information /etc/login.defs - system-wide settings /etc/skel - directory containing default files

Poking through these files with grep returned:

/etc/login.defs:PASS_MAX_AGE 5

login.defs was modified about a month ago, I don’t know how or why. useradd was six months old. I assume some other package modified login.defs, or maybe there was a configuration step that I performed unknowingly or incorrectly. I do not recall this, but maybe I did it through a GUI. I guess I need to get my entire hierarchy under version control, and more facility with yum/up2date.

Anyway, if PASS_MAX_AGE means what I think it does, passwords cannot be older than 5 days, or the user is forced to change it. This is bizarrely short for my purposes.

login.defs is not very helpful. Here is a snippet of the file:
# Password aging controls: # # PASS_MAX_DAYS Maximum number of days a password may be used. # PASS_MIN_DAYS Minimum number of days allowed between password changes. # PASS_MIN_LEN Minimum acceptable password length. # PASS_WARN_AGE Number of days warning given before a password expires. # PASS_MAX_DAYS 60 PASS_MIN_DAYS 0 PASS_MIN_LEN 5 PASS_MAX_AGE 5

The other variables are documented. PASS_MAX_AGE isn’t and PASS_WARN_AGE is documented and not used. I assume that this is a mistake.

Google returns 1500 hits for PASS_WARN_AGE.

I commented out the PASS_MAX_AGE and replaced it with PASS_WARN_AGE. No warnings from useradd and userdel. I will report back if anything else breaks.