Re: nmh 1.1 release canidate uploaded
Ken Hornstein [EMAIL PROTECTED] wrote: Everyone, I've created a nmh 1.1 release canidate. You can get it from: http://savannah.gnu.org/download/nmh/nmh-1.1-RC1.tar.gz What's the difference between this release and the one I picked (and have been using since then) in July?
Re: nmh 1.1 release canidate uploaded
Glenn Burkhardt [EMAIL PROTECTED] wrote: Ken Hornstein [EMAIL PROTECTED] wrote: Everyone, I've created a nmh 1.1 release canidate. You can get it from: http://savannah.gnu.org/download/nmh/nmh-1.1-RC1.tar.gz What's the difference between this release and the one I picked (and have been using since then) in July? Good question. Unfortunately, Savannah doesn't seem to provide the same Files section as does Sourceforge which organizes release notes and changelogs together with the release. It just points to a big ftp directory. In the MH-E project, my release notes are the README file which is short and says which versions of Emacs are supported, how to install MH-E, and where to get more help and documentation. I don't actually show the actual ChangeLog, but distill the best bits. It looks like the Emacs' NEWS file. On Savannah, we could do one of two things (or a combination). We could create README and a NEWS files. The README would include the installation notes (which in nmh's case might point to an INSTALL file within the distribution) and the NEWS file would be a reverse chronological listing of new features and bug fixes: NEWS README nmh-1.1-RC1.tar.gz Or, we could associate a README and a NEWS file with each release: nmh-1.1-RC1.NEWS nmh-1.1-RC1.README nmh-1.1-RC1.tar.gz Or, a combination thereof (I think this would work best in this case): README nmh-1.1-RC1.NEWS nmh-1.1-RC1.tar.gz To see where I'm coming from, go to: https://sourceforge.net/projects/mh-e/ Look down to the Latest File Releases section and and click on the book for the mh-e package. When you do that, you'll see the Notes (which comes from the README in the distribution) and the Changes (which comes from the file MH-E-NEWS in the distribution). The only reason we use the name MH-E-NEWS instead of NEWS is because we install MH-E into GNU Emacs, and it wouldn't be such a great idea to overwrite the Emacs NEWS file ;-). -- Bill Wohler [EMAIL PROTECTED] http://www.newt.com/wohler/ GnuPG ID:610BD9AD Maintainer of comp.mail.mh FAQ and mh-e. Vote Libertarian! If you're passed on the right, you're in the wrong lane.
Re: Working on the install-mh change questions
Jon Steinhart [EMAIL PROTECTED] writes: 3.If the $HOME environment variable is set, mypath is copied from the getenv return. Why? It's never changed. 4.If the $HOME environment variable is not set, mypath is copied from the pw_dir member of the returned passwd structure. Now, I understand that this is a static structure, but getpwuid is never called again so I don't see why the copy is needed. 4.If the $HOME environment variable is not set, the pw_dir member of the passwd structure returned by getpwuid() is checked for a NULL pointer. This can never happen in a non-error return, which is already checked. So why the superfluous check? These checks are not superflous, they are for maintainability. Two years from now someone will add a second getenv(3) call and waste their (probably volunteer) time trying to figure out how they busted the home dir variable. That is why, unless you are writing super-tight-must-be-the-best-performing-code-ever applications (which mh is not), it is necessary always to make a copy of the static buffer pointed to by the return values of such functions. -- Eric Gillespie * [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Another working on the install-mh change question
Jon Steinhart [EMAIL PROTECTED] writes: sbr/context_read does a complicated check for installation involving first the MH environment variable and second the default profile. I was surprised to discover that uip/install-mh does not perform identical tests. It just looks for the default profile. This seems wrong to me. Should I fix it? Yes. -- Eric Gillespie * [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: install-mh location
Neil W Rickert [EMAIL PROTECTED] writes: But, install-mh is not likely to be in the user's path; it's in the lib directory. Should I change the installation to move this to the bin directory or to make a link from the bin to the lib directory? Make a sym-link, or put in a shell script. Why? It's an obvious end-user program, especially now. It belongs in bindir. I doubt much if anything uses the old path (mh-e might, but note that it is still alive and kicking, arguably more so than nmh itself), so i say don't even bother with a backwards compatability symlink, but if you must have one the link goes in libexecdir. -- Eric Gillespie * [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: install-mh location
Neil W Rickert [EMAIL PROTECTED] writes: But, install-mh is not likely to be in the user's path; it's in the lib directory. Should I change the installation to move this to the bin directory or to make a link from the bin to the lib directory? Make a sym-link, or put in a shell script. Why? It's an obvious end-user program, especially now. It belongs in bindir. I doubt much if anything uses the old path (mh-e might, but note that it is still alive and kicking, arguably more so than nmh itself), so i say don't even bother with a backwards compatability symlink, but if you must have one the link goes in libexecdir. -- Eric Gillespie * [EMAIL PROTECTED] Well, I already checked in a change to make it a link. Feel free to change it. By the way, should the manual page be changed from section 8 to section 1? Jon
Re: Working on the install-mh change questions
Jon Steinhart [EMAIL PROTECTED] writes: 3. If the $HOME environment variable is set, mypath is copied from the getenv return. Why? It's never changed. 4. If the $HOME environment variable is not set, mypath is copied from the pw_dir member of the returned passwd structure. Now, I understand that this is a static structure, but getpwuid is never called again so I don't see why the copy is needed. 4. If the $HOME environment variable is not set, the pw_dir member of the passwd structure returned by getpwuid() is checked for a NULL pointer. This can never happen in a non-error return, which is already checked. So why the superfluous check? These checks are not superflous, they are for maintainability. Two years from now someone will add a second getenv(3) call and waste their (probably volunteer) time trying to figure out how they busted the home dir variable. That is why, unless you are writing super-tight-must-be-the-best-performing-code-ever applications (which mh is not), it is necessary always to make a copy of the static buffer pointed to by the return values of such functions. -- Eric Gillespie * [EMAIL PROTECTED] This is one of those places where we'll have to respectfully disagree. I'm obviously in the minority given the quality of software that I see these days, but I think that programming is still something that should be done by professionals. I don't want someone hacking on code that doesn't take the time to figure out what's going on first. Protecting against the really silly mistakes allows such people to make really complex ones. As I said in my earlier email, I'm not going to write slow and sloppy code just because computers are fast. Matter of fact, I keep on trying to get up the courage to tackle m_getfld(). Oh, some details. 1. A second getenv() call would not break the code. The copy was really unnecessary. 2. It's hard for me to imagine a situation where getpwuid() would #1 get called a second time and #2 for a different uid, which is the only that a problem would occur. 3. If there's a NULL passwd-pw_dir then libc is broken and should be fixed. Better that this gets pointed out and fixed rather than covered up so that it stays unnoticed and broken. Oh, and I've wasted some of my volunteer time trying to figure out what the code did before changing it. I'd waste less if there was less code. Best way to accomplish this is to get rid of the code that doesn't do anything. Jon
Re: install-mh location
Eric Gillespie [EMAIL PROTECTED] wrote: Neil W Rickert [EMAIL PROTECTED] writes: But, install-mh is not likely to be in the user's path; it's in the lib directory. Should I change the installation to move this to the bin directory or to make a link from the bin to the lib directory? Make a sym-link, or put in a shell script. Why? It's an obvious end-user program, especially now. It People have been using MH, and now nmh, for a very long time. They have come to expect things in particular places and my have local shell scripts that depend on it. with a backwards compatability symlink, but if you must have one the link goes in libexecdir. Putting the link in lib would be fine. -NWR
Re: Working on the install-mh change questions
On Mon, 2002-11-18 at 22:47, Eric Gillespie wrote: Jon Steinhart [EMAIL PROTECTED] writes: 3. If the $HOME environment variable is set, mypath is copied from the getenv return. Why? It's never changed. 4. If the $HOME environment variable is not set, mypath is copied from the pw_dir member of the returned passwd structure. Now, I understand that this is a static structure, but getpwuid is never called again so I don't see why the copy is needed. 4. If the $HOME environment variable is not set, the pw_dir member of the passwd structure returned by getpwuid() is checked for a NULL pointer. This can never happen in a non-error return, which is already checked. So why the superfluous check? These checks are not superflous, they are for maintainability. Two years from now someone will add a second getenv(3) call and waste their (probably volunteer) time trying to figure out how they busted the home dir variable. The return value of getenv() is a pointer into the environment; a future getenv() call will not overwrite it. So it's safe not to copy it unless you anticipate a putenv(). (And I think it's safe even in the face of a putenv(), actually.) A judgement call. Your argument definitely holds for copying the getpwuid() value. Checking the pw_dir element for NULL is superfluous unless you feel like second-guessing the kernel and libc at every turn, a practice which doesn't have much value.
Re: Working on the install-mh change questions
Greg Hudson [EMAIL PROTECTED] writes: The return value of getenv() is a pointer into the environment; a future getenv() call will not overwrite it. So it's safe not to copy it unless you anticipate a putenv(). (And I think it's safe even in the face of a putenv(), actually.) A judgement call. Not according to the new POSIX/SUSv3 (and i suspect the original POSIX): http://www.opengroup.org/onlinepubs/007904975/functions/getenv.html The return value from getenv() may point to static data which may be overwritten by subsequent calls to getenv(), [CX] [Option Start] setenv(), or unsetenv(). [Option End] [XSI] [Option Start] On XSI-conformant systems, the return value from getenv() may point to static data which may also be overwritten by subsequent calls to putenv(). [Option End] If you think about it, that makes sense. The environment is an array of pointers to character buffers, and since what putenv(3) stores for FOO is often larger than the size of the original FOO, it will need to get a larger buffer at a different address, invalidating the original returned address. I just checked Harbison Steele, and according to them ISO C does not allow calls to putenv to modify the getenv return value, and as seen above, nor does POSIX (though the XSI extension does). Maybe i'm just not very imaginative at this late hour, but i don't see another way to implement the environment without putenv modifying it, so i find it strange that the two important standards don't allow for it. Bleh, i hope that made sense. sleep... -- Eric Gillespie * [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
Re: Working on the install-mh change questions
Eric Gillespie [EMAIL PROTECTED] writes: I just checked Harbison Steele, and according to them ISO C does not allow calls to putenv to modify the getenv return value, and as seen above, nor does POSIX (though the XSI extension does). Maybe i'm just not very imaginative at this late hour, but i don't see another way to implement the environment without putenv modifying it, so i find it strange that the two important standards don't allow for it. Just thought of one, though perhaps not the most obvious. POSIX and ISO C *do* mention static buffers; a getenv implementation can copy from the environment array into its own static buffer, extending it if necessary (subsequent getenv buffers may invalidate old ones, i.e. return addresses of newly allocated buffers). Then putenv calls wouldn't invalidate the getenv return value. -- Eric Gillespie * [EMAIL PROTECTED] Build a fire for a man, and he'll be warm for a day. Set a man on fire, and he'll be warm for the rest of his life. -Terry Pratchett
