We may have run into a bug, working with Novell support on it, that is
causing us some grief.

Basically the Generate password() token, when pointed at our UP policy,
is generating passwords with non-ASCII characters in it, even though the
policy says not to do that.

This causes the bidirectional NIS driver to hang up on that event, which
is kind of annoying, since fixing it means restarting the shim, after
clearing out the stuck event (changelog and loopback directories, clear
the files) and then eDir on the engine server.

One work around would be to test the password (we generate it in a
loopback driver) before setting it, and if it contains non-ASCII try
again, till we get one that does not.

I am trying to figure out an XPATH or regex test that would do that.

I am pretty sure that a regex of something like [a-z][A-Z][0-9] would
start me off. But we also want to allow the special characters,
(actually require at least one) like !@#$%^&*()_+ (And no, I am not
cartoon cursing!). I know there is XPATH contains() that might be
helpful as well. Not sure of the exact case I would use here though.

My thinking was set a local variable (say 'tempPassword'to the output of
Generate Password.

Then in a while loop, where the test is while tempPassword contains
non-ASCII chars, set local variable testPassword, the output of Generate
Password().

What would that test for non-ASCII chars look like? Any comments from
the cheap seats? (Regex/XPATH pros?)