Message-Id: <200101211728.MAA26023@qnx.com> Subject: Re: Status update (Smalltalk/Python) To: djgpp-workers AT delorie DOT com Date: Sun, 21 Jan 2001 12:28:19 -0500 (EST) From: "Alain Magloire" In-Reply-To: <2593-Sun21Jan2001185912+0200-eliz@is.elta.co.il> from "Eli Zaretskii" at Jan 21, 2001 06:59:13 PM X-Mailer: ELM [version 2.5 PL0b1] MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Reply-To: djgpp-workers AT delorie DOT com Errors-To: nobody AT delorie DOT com X-Mailing-List: djgpp-workers AT delorie DOT com X-Unsubscribes-To: listserv AT delorie DOT com Precedence: bulk > > > Date: Sun, 21 Jan 2001 11:09:16 -0500 (EST) > > From: "Alain Magloire" > > > > > > Eli Zaretskii wrote: > > > > > > > > On Sun, 21 Jan 2001, Tim Van Holder wrote: > > > > > Wasn't sure what to use for a value though; would apps expect > > > > > crypt()'ed values or plaintext? > > > > > > > > Could people who can access Unix and GNU/Linux boxes please look what > > > > they do? > > > > Crypt. > > I think emulating encrypted password is way too much. Would some > application mind if we return a clear-text password? Would they even > know? Yes and no. Yes, it the sense it will always fail. The way programs(login, ftpd, popd, etc ...) authenticate is by doing this: if (strcmp (pw->pw_passwd, crypt (pass, pw->pw_passwd))) { return error; } By providing, a clear text passwd crypt() will always failed. So porting applications that involve this may take a few #ifdefs #ifdef __DJGPP__ # define crypt(k,s) s #endif No, since if I understand, DJPP does not provide any support for this. There are may crypt()'s implementation on the net. -- au revoir, alain ---- Aussi haut que l'on soit assis, on est toujours assis que sur son cul !!!