lukas@ihlpf.ATT.COM (00771g-Lukas) (05/18/89)
I am trying to use crypt(1). If I invoke cat foo | crypt "abcde" under sh or ksh, it seems to work fine. However, if I extend the key by one character, and invoke cat foo | crypt "abcdef" under sh, I get the message crypt: cannot generate key (ksh works ok). Does anyone have an idea what the problem is? TIA -- John Lukas att!ihlpf!lukas 312-510-6290
dce@Solbourne.COM (David Elliott) (05/18/89)
In article <8526@ihlpf.ATT.COM> lukas@ihlpf.UUCP (Lukas,J.) writes: > >I am trying to use crypt(1). If I invoke > cat foo | crypt "abcde" >under sh or ksh, it seems to work fine. However, if I extend the key >by one character, and invoke > cat foo | crypt "abcdef" >under sh, I get the message > crypt: cannot generate key >(ksh works ok). Does anyone have an idea what the problem is? TIA What year is it? Did I just get thrown back five years? The problem is that some versions of crypt are very naive about doing a wait(). They just wait for the first child process that dies, and if the input file is small enough, that process will often be the cat. You see, the shell forks a process to run the entire command line. The resulting process forks to run the cat, and execs the crypt, so the cat process is a child of the process that ends up running crypt. Crypt forks and execs makekey, and then waits for it. Ksh process handling is slightly different, though I don't know the details. If the cat finishes before the makekey, there may be no data ready to read from makekey, but crypt tries anyway and fails. This was discussed about five years ago, and has been fixed in a number of Unix variants. -- David Elliott dce@Solbourne.COM ...!{boulder,nbires,sun}!stan!dce