That should be fine. It produces "uv1o844x44bz." using 5.6.1 on Solaris 8.

First, I'd try with a two character salt (though, that shouldn't make a difference.)

Secondly, I'd try a minimal C program to be sure it works as expected:

int main () {
    char *salt = "uv";
    char *pass = "abcdef";
    printf("%s\n", crypt(pass, salt));
}
[download]

You say that it "has worked flawlessly in the past (and continues to work on a remote host)" so I have to ask: has anything changed recently on the box it is failing on?

-sauoq
"My two cents aren't worth a dime.";

What's changed? The addition of and defaulting to ActiveState Perl. My assertion that the problem also occurred under {the Redhat-supplied} 5.6.0 was mistaken, due to some $PATH mangling and the wrong symbolic link being referenced. It's the ActivePerl {5.6.1, build 633} that's the problem. This behavior is quite disturbing, too. If their crypt function were used by the unwary to create a password file (which I nearly did), any password subsequently entered during authentication would match -- a clear security breach! And the programmer wouldn't have a clue that anything was amiss without looking at the encrypted password file.

Before posting this, I called ActiveState to give them a chance to comment. I was informed that this was a known bug, discovered only in the past couple days.

Update (18 Sep 02): Added braced text for clarification. I haven't used ActiveState's 5.6.0 or other builds of 5.6.1, so I don't know if they had the same problem.

Thanks. In fact, it was discovered internally only yesterday and fixed.

The problem is that ActivePerl uses the crypt_r() function which needs a buffer to work with, and that argument requires one of its fields to be nulled. ActivePerl allocates this buffer on the stack, so the said field may be non-null.

The following patch has been checked in:

--- ./pp.c.~1~      Tue Sep 17 14:17:07 2002
+++ ./pp.c  Tue Sep 17 14:17:07 2002
@@ -2347,6 +2347,7 @@
 #  if defined(__linux__)
 #   include <crypt.h>
     struct crypt_data c_data;
+    c_data.initialized = 0;
 #    define crypt(k,s) crypt_r(k,s,&c_data)
 #  endif
 #endif
End of Patch.
[download]

There should be a new release out for Linux ASAP.

perldoc -f crypt says:

Encrypts a string exactly like the crypt(3) func-
tion in the C library (assuming that you actually
have a version there that has not been extirpated
as a potential munition).
[download]

Wasn't yours been extirpated?

Maybe  perl -V can tell you. Look for the  -lcrypt string.