Re: nmh 1.0.4 doesn't work as POP client on LInux systems
John Summerfield [EMAIL PROTECTED] writes: nmh_getpass(). I think we should change the name. Our function's whole point is to obviate the need for any system-specific getpass(), so we shouldn't have to adhere to their prototypes unless we really want to. Okay, I've changed it to nmh_getpass(). The only drawback of not calling it getpass() is that in the future people may accidentally use plain getpass() instead of nmh_getpass() and unless they're on an OS where getpass() fails to prompt, they won't know that they shouldn't have done that. You could add a getpass() function that will collide with the system definition and, when called, issue an error message and either a)Call the real one b)Terminate the program. But then we're back to having to autodetect the proper declaration to get it to compile. Probably not worth the work for a function which, as has been pointed out, is likely not get get called elsewhere in the code in the future. Compiler messages are unimportant, though an explanatory comment at the function to explain why it's there would be a Good Thing. I disagree. Compiler warnings just pointed out two bugs in the new getpass() function. It's important to write code that compiles clean with gcc -Wall if it all possible. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
nmh_getpass(). I think we should change the name. Our function's whole point is to obviate the need for any system-specific getpass(), so we shouldn't have to adhere to their prototypes unless we really want to. Okay, I've changed it to nmh_getpass(). The only drawback of not calling it getpass() is that in the future people may accidentally use plain getpass() instead of nmh_getpass() and unless they're on an OS where getpass() fails to prompt, they won't know that they shouldn't have done that. You could add a getpass() function that will collide with the system definition and, when called, issue an error message and either a) Call the real one b) Terminate the program. Compiler messages are unimportant, though an explanatory comment at the function to explain why it's there would be a Good Thing. -- Cheers John Summerfield http://os2.ami.com.au/os2/ for OS/2 support. Configuration, networking, combined IBM ftpsites index.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Shantonu Sen [EMAIL PROTECTED] writes: Just to close out this thread, I have committed a getpass() which Glenn Burkhardt and I have been working on. It solves the problem of other programs interfacing with nmh, such as exmh, as well as guaranteeing the implementation of that function. i have personally compiled and used it on linux (redhat 6.1 with glibc2.1.2), solaris 8, netbsd 1.4.2, IRIX 6.5. it's main dependency is on termios.h, so please tell me if this causes any problems. Works fine on AIX 4.1.5.0.01. I cleaned up four compiler warnings produced by gcc -Wall. One of them required adding an #include of stdlib.h, and this required me to change getpass() to take a const char* rather than a char*, to match the system prototype. Is this how getpass() is declared everywhere? If not, we'll need to add autoconf support to check the declaration or (preferably) change this function name to be nmh_getpass(). I notice the memory allocated by calloc() is leaked. Not that big a deal for nmh's short-running programs, I guess, but it might at least be worth a comment acknowledging the leak and giving the justification. as far as licenses, the code started out from the netBSD codebase, but I really hacked on it a LOT to get it to do what i wanted. hopefully this should be okay. The copyright notice sort of implies that we're using the unchanged version. We should probably add "Portions of this code are" to the beginning, eh? on a separate note, does anyone have objections to cleaning out MACHINES? it really has a lot of useless crap, like the following: *** No longer necessary *** *** This test has been updated and should work now *** if these are no longer issues, they should not be included in the file, since it only serves to confuse users on non-issues. By all means. Ideally we'd be able to get rid of MACHINES altogether. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Works fine on AIX 4.1.5.0.01. I cleaned up four compiler warnings produced by gcc -Wall. One of them required adding an #include of stdlib.h, and this required me to change getpass() to take a const char* rather than a char*, to match the system prototype. Is this how getpass() is declared everywhere? If not, we'll need to add autoconf support to check the declaration or (preferably) change this function name to be nmh_getpass(). I think we should change the name. Our function's whole point is to obviate the need for any system-specific getpass(), so we shouldn't have to adhere to their prototypes unless we really want to. The only reason why I didn't stick with const char* was that I didn't see the relevance of being so specific. It's not that important. I notice the memory allocated by calloc() is leaked. Not that big a deal for nmh's short-running programs, I guess, but it might at least be worth a comment acknowledging the leak and giving the justification. I only added the explicity calloc because my compiler (granted, without -Wall), was complaining about getpass returning a local variable. instead of declaring buf[SIZE], if I manually calloc'ed it, the warning went away. I'll fix this up in the next few days. The copyright notice sort of implies that we're using the unchanged version. We should probably add "Portions of this code are" to the beginning, eh? Sounds good. By all means. Ideally we'd be able to get rid of MACHINES altogether. OK. I seem to recall seeing some programs say "You must use gcc", but we should be able to get around that. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Glenn Burkhardt writes (to me directly as his outgoing server is ORBS'd): Works fine on AIX 4.1.5.0.01. I cleaned up four compiler warnings produced by gcc -Wall. One of them required adding an #include of stdlib.h, and this required me to change getpass() to take a const char* rather than a char*, to match the system prototype. Is this how getpass() is declared everywhere? Linux: char *getpass( const char * prompt ); SunOS: char *getpass( char *prompt ); Solaris: char *getpass( const char *prompt ); Shantonu Sen [EMAIL PROTECTED] writes: Works fine on AIX 4.1.5.0.01. I cleaned up four compiler warnings produced by gcc -Wall. One of them required adding an #include of stdlib.h, and this required me to change getpass() to take a const char* rather than a char*, to match the system prototype. Is this how getpass() is declared everywhere? If not, we'll need to add autoconf support to check the declaration or (preferably) change this function name to be nmh_getpass(). I think we should change the name. Our function's whole point is to obviate the need for any system-specific getpass(), so we shouldn't have to adhere to their prototypes unless we really want to. Okay, I've changed it to nmh_getpass(). The only drawback of not calling it getpass() is that in the future people may accidentally use plain getpass() instead of nmh_getpass() and unless they're on an OS where getpass() fails to prompt, they won't know that they shouldn't have done that. I've added a "nmh-local functions to use in preference to OS versions" section to README.developers documenting this -- anyone know of any other functions in this boat besides [nmh_]getpass()? The only reason why I didn't stick with const char* was that I didn't see the relevance of being so specific. It's not that important. Well, if you have a const char*, you won't be able to pass it to a function that takes a plain char*. In general, functions that don't change what's pointed to by their pointer paramters should declare them const. It can also be an optimization issue -- the compiler can do more optimization if it knows that a pointed-to value shouldn't change across a function call. I notice the memory allocated by calloc() is leaked. Not that big a deal for nmh's short-running programs, I guess, but it might at least be worth a comment acknowledging the leak and giving the justification. I only added the explicity calloc because my compiler (granted, without -Wall), was complaining about getpass returning a local variable. instead of declaring buf[SIZE], if I manually calloc'ed it, the warning went away. I'll fix this up in the next few days. Um, yeah, that warning was pointing out a real bug (as was the one that said the != EOF comparison would always return true). The solution isn't to calloc() it, though -- buf just needs to be declared static. That's what the system getpass() does. I've fixed this. It's happened multiple times in the past that people have introduced warnings that I later ended up cleaning up because they didn't use --enable-debug when they configured nmh, and thus weren't using -Wall. I've changed configure.in so -Wall is now included during optimized compiles as well. The copyright notice sort of implies that we're using the unchanged version. We should probably add "Portions of this code are" to the beginning, eh? Sounds good. Done. --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Shantonu Sen [EMAIL PROTECTED] writes: Okay, I've changed it to nmh_getpass(). The only drawback of not calling it getpass() is that in the future people may accidentally use plain getpass() instead of nmh_getpass() and unless they're on an OS where getpass() fails to prompt, they won't know that they shouldn't have done that. Where else would they use a password function (in nmh?). inc and msgchk for POP mail will use getpass as defined here. Yes, it's likely it won't be used elsewhere, but I still think it's worth having that section in README.developers. I've added a "nmh-local functions to use in preference to OS versions" section to README.developers documenting this -- anyone know of any other functions in this boat besides [nmh_]getpass()? ruserpass(), which is unreliably detected and possibly implemented. I think the TODO mentions some other functions, like snprintf, which aren't implemented yet, but it makes sense to have that section in the README.dev as a placeholder. Yeah, if we _ever_ use the system functions, as we do with snprint(), they shouldn't go in that section. But if we sometimes use the vendor ruserpass(), then our nmh_getpass() won't get called -- we need to always use our ruserpass() or else rename nmh_getpass() back to getpass() (assuming vendor ruserpass() functions always call getpass()). --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
ruserpass(), which is unreliably detected and possibly implemented. I think the TODO mentions some other functions, like snprintf, which aren't implemented yet, but it makes sense to have that section in the README.dev as a placeholder. Yeah, if we _ever_ use the system functions, as we do with snprint(), they shouldn't go in that section. But if we sometimes use the vendor ruserpass(), then our nmh_getpass() won't get called -- we need to always use our ruserpass() or else rename nmh_getpass() back to getpass() (assuming vendor ruserpass() functions always call getpass()). System ruserpass is never used. I removed the dependency because of this kind of complication. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Shantonu Sen [EMAIL PROTECTED] writes: ruserpass(), which is unreliably detected and possibly implemented. I think the TODO mentions some other functions, like snprintf, which aren't implemented yet, but it makes sense to have that section in the README.dev as a placeholder. Yeah, if we _ever_ use the system functions, as we do with snprint(), they shouldn't go in that section. But if we sometimes use the vendor ruserpass(), then our nmh_getpass() won't get called -- we need to always use our ruserpass() or else rename nmh_getpass() back to getpass() (assuming vendor ruserpass() functions always call getpass()). System ruserpass is never used. I removed the dependency because of this kind of complication. I see -- you were just listing it as an "nmh-local function to use in preference to OS version". That section only covers functions with different names than the system ones, however, as when the name is the same, developers don't need to do anything special -- they just type the normal system function name. I see you didn't make a ChangeLog entry for your getpass() and ruserpass() changes -- please do so... --- Dan Harkless | To prevent SPAM contamination, please [EMAIL PROTECTED] | do not post this private email address SpeedGate Communications, Inc. | to the USENET or WWW. Thank you.
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
On Thu, 4 May 2000, Dan Harkless wrote: I don't see that in the CVS source. Did your changes get lost somehow when Doug moved mhost.com? No, I didn't commit it before. Probably for the best, as Doug pointed out the GPL-ness of it. I'm hoping to have a working version committed in the next few days. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Shantonu Sen wrote: i've taken glibc getpass, stripped out some flock-ing code that didn't compile on BSD, and made it into a patch (attached). it should depend only on termios.h (add to the includes) and stdio and strings.h, which are included in nmh.h. so hopefully, this should be pretty portable. This can not be included in the nmh sources. The glibc license is incompatible -- it's GPL. You can not use the source without re-licensing the code you include it into. You may want to consider using using the BSD version of getpass instead from any BSD distribution (Free,Net,Open), as it is clearly compatible. Otherwise, You need to write to the FSF and ask that the conditions of the GPL be waived in this case. The specific section of the GPL is: 10. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally. -- Doug Morris Morris Communications Computer Services, Inc. http://www.mhost.com/
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
My solution was to completely take out any dependency on system ruserpass, and use the version packaged with nmh. If you want to take advantage of this, I recommend you get the latext CVS version. I think that this is the best solution - it gets my vote!
nmh 1.0.4 doesn't work as POP client on LInux systems
Last November, I submitted a bug report with patches for nmh - it didn't work as a POP client properly on Linux systems. But unfortunately, the patches didn't get into the 1.0.4 release, so here goes again: The Symptom: Unless .netrc is used, on systems using glibc 2.1.1, 'inc' fails to work when nmh is configured as a POP client. The Reason: The glibc version of ruserpass() won't prompt the user for a password (the glibc maintainers believe that this is the right and proper behavior, and won't change ruserpass() - see note attached). Possible Solutions: 1. At minimum, the documentation should be changed to note the current restriction that ~/.netrc be used to supply a login/password for POP. 2. For Linux systems, avoid using the glibc version of ruserpass(), and use the version supplied with nmh. There's an additional problem here - ruserpass() calls getpass(), and in glibc, the getpass() flushes standard input before prompting the user for a password. When a program like exmh uses 'inc', it feeds in the password as standard input with code like: exec inc +inbox -truncate -nochangecur -width 100 password which fails with the glibc version of getpass(). So a replacement for getpass() needs to be provided as well. What to Do? I'm willing to put together changes to the nmh configure script that will use the nmh version of ruserpass(). I have a patch for ruserpass() that works with my system (see attached). Would you like me to work on the configure portion? But it is also the case that 'ruserpass()' is not a "well defined" function - it's not a Posix function, and can't be guaranteed to exist with any particular attributes on any particular system. It's an internal routine to rexec(), and by rights shouldn't really be used by nmh at all. So a better overall fix would be to always use the nmh version of ruserpass(), including its own 'getpass()' routine, to make sure it always works. So, what would you like to do? Please at least include a note in the MACHINES file about the restriction that on Linux systems, ~/.netrc must be used for POP login/password info. Thanks! glenn writes: Number: 1474 Category: libc Synopsis: rexec() function won't prompt for password if not found in .netrc file Confidential: no Severity: serious Priority: medium Responsible:libc-gnats State: open Class: sw-bug Submitter-Id: unknown Arrival-Date: Mon Nov 29 12:00:01 EST 1999 Last-Modified: Originator: [EMAIL PROTECTED] Organization: net Release:2.1.1 Environment: Mandrake Linux 6.1, i386 architecture Description: Unfortunately, none of this family of functions (rexec, rcmd) is documented in the manual. Previous editions of ruserpass() in the BSD distribution would prompt for a password if it wasn't found in a variety of places. The glibc version will only return a username/password if there are appropriate entries in the .netrc file. This has caused the current edition of nmh (1.0.2) not to work correctly, because it counts on the user being prompted for a password. Since there is no documentation of rexec() in the glibc manual, I include for reference excerpts from man pages on This has been discussed several times on the glibc mailing lists. I'm citing some comments from the discussion: Mark Kettenis writes on 26th October 1999: Do you have any evidence that the statement about rexec asking for the username/password is true? Although the BSD man pages do indeed mention that rexec() would do this, none of the BSD's derived from BSD 4.2 (which according to the man page is the first version that has rexec()) do implement this. Since the code in glibc is derived directly from BSD, it is no surprise that glibc doesn't do this either. So the whole issue appears to be a documentation bug on the side of BSD. There may be some reimplementations of rexec() around that do ask for a password based on the BSD documentation, but that's not very relevant. I think that there are a lot of cases where it is unwanted. As a principle, no library call should print anything (except when that's the explicit purpose of the call of course), let alone ask for input. And later, Mark again: Anyway, the issue has been discussed before [1]. Ulrich thinks we should stay with the BSD 4.4 implementation, and I agree with him. It's more or less the reference standard for rexec(). Also note that rexec() is considered to be pretty dangerous. FreeBSD and NetBSD only offer it for compatibility with BSD 4.4, and reccommend using another mechanism. Mark [1] http://sourceware.cygnus.com/ml/bug-glibc/1999-07/msg00085.html In a nutshell: glibc follows the BSD 4.4 implementation and we're not going to change it. Andreas -- Andreas Jaeger SuSE Labs [EMAIL PROTECTED] private [EMAIL PROTECTED] *** ruserpass.c.orig Fri Apr 30 14:08:34 1999 --- ruserpass.c Mon Nov
Re: nmh 1.0.4 doesn't work as POP client on LInux systems
Last November, I submitted a bug report with patches for nmh - it didn't work as a POP client properly on Linux systems. But unfortunately, the patches didn't get into the 1.0.4 release, so here goes again: I had the same problems, and fixed them after 1.0.4 came out. I did not want to commit them prematurely and risk the release version having bugs. My solution was to completely take out any dependency on system ruserpass, and use the version packaged with nmh. If you want to take advantage of this, I recommend you get the latext CVS version. 2. For Linux systems, avoid using the glibc version of ruserpass(), and use the version supplied with nmh. There's an additional problem here - ruserpass() calls getpass(), and in glibc, the getpass() flushes standard input before prompting the user for a password. When a program like exmh uses 'inc', it feeds in the password as standard input with code like: exec inc +inbox -truncate -nochangecur -width 100 password which fails with the glibc version of getpass(). So a replacement for getpass() needs to be provided as well. I haven't tested this with exmh. I will look into it. I'm willing to put together changes to the nmh configure script that will use the nmh version of ruserpass(). I have a patch for ruserpass() that works with my system (see attached). Would you like me to work on the configure portion? configure is done, as is ruserpass. I will work on incorporating your getpass(). So, what would you like to do? Please at least include a note in the MACHINES file about the restriction that on Linux systems, ~/.netrc must be used for POP login/password info. Thanks! Hopefully this will not be necessary. Shantonu *---* |Shantonu Sen * (617)225-6778 * [EMAIL PROTECTED]| |Electrical Engineering and Computer Science| |Massachusetts Institute of Technology, 2002| *---*
