Appropriateness of new program/feature
Howdy. I've been working on a companion mail reading system for nmh. In short, this is a system that builds a database from mail in folders, allowing it to be searched quickly. It includes a ranking mechanism, and allows messages to be searched by rank. Sort of like the current fad of Bayesian spam filters, but more general. I have already checked in external hook modifications to nmh that allow it to invoke external programs when mail is added, removed, or refiled. But, there's one more sticky point. There's no good way to test whether or not nmh is installed. When I set up my program, I want to fail with an error message if the user hasn't set up a mail directory, etc. I need to do this because my program needs to invoke some nmh commands via pipes, like folder -fast to get the current folder, or mhpath + to get the mail folder. If there is no mail folder, nmh commands prompt the user for installation as opposed to failing with an error code. This is nice for a user but a real nuisance for a program. I currently have an is_nmh_installed() function as part of my program. I really don't like doing it this way because things like how the MH environment variable works and where to find the mail folder in the profile seem to me like nmh internals that belong in nmh, not in some other program. So, I'd like to add something to nmh to allow for installation testing. I think that the best way to do this would be to add a report-only option to install-mh. Any objections if I do this? Jon
Re: Appropriateness of new program/feature
Jon Steinhart wrote: There's no good way to test whether or not nmh is installed. When I set up my program, I want to fail with an error message if the user hasn't set up a mail directory, etc. ... So, I'd like to add something to nmh to allow for installation testing. I think that the best way to do this would be to add a report-only option to install-mh. It's always bugged me that MH/nmh starts to install a new user setup if it can't find something it's looking for -- like the MH (.mh_profile) file. IMHO, it should simply fail and print an error message that gives the pathname of the MH file that it's looking for (that's either the setting of the MH envariable, or $HOME/.mh_profile). It could also tell the user how to install MH/nmh. The error could say something like: progname: aborting: can't read pathname-of-MH-file. Check your MH environment variable (if any) or run install-mh to install nmh. I haven't given a lot of thought to the implications, or to all the possible permutations (which problems cause install-mh to be invoked). Still, this method (telling the user to run install-mh if MH isn't installed) seems like a more sane way to handle the problem. Comments, anyone? Would this change break any front-end programs (mh-e, etc.) that somehow depend on the prompts that install-mh now prints by default? Jerry -- Jerry Peek, [EMAIL PROTECTED], http://www.jpeek.com/
Re: Appropriateness of new program/feature
Neil W Rickert wrote: progname: aborting: can't read pathname-of-MH-file. Check your MH environment variable (if any) or run install-mh to install nmh. I vote for that feature. aol me too /aol
Re: Appropriateness of new program/feature
But, there's one more sticky point. There's no good way to test whether or not nmh is installed. When I set up my program, I want to fail with an error message if the user hasn't set up a mail directory, etc. Is test -d `mhparam Path` sufficient for your needs? -- Eric Gillespie * [EMAIL PROTECTED] No. If mh isn't installed, mhparam will prompt for installation just like every other mh program. Jon
Re: Appropriateness of new program/feature
Jerry Peek [EMAIL PROTECTED]; wrote: progname: aborting: can't read pathname-of-MH-file. Check your MH environment variable (if any) or run install-mh to install nmh. Good idea. Comments, anyone? Would this change break any front-end programs (mh-e, etc.) that somehow depend on the prompts that install-mh now prints by default? Fascinating. MH-E 5.0.2 ran install-mh for you, but I notice that the beta for MH-E 7.0 (mh-e.sourceforge.net) prints a mysterious message (Can't find paths). Whoops, I guess that's something we never checked while putting out this version. In any case, MH-E development is active enough these days that we could easily recover from any changes to nmh in this department. Don't let us stop you. -- 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: 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 Well...yesterday I sent a message from a different email address that I imagine the list owner might be reading about now...don't worry about that message (sorry for the duplicate if it gets to the list). I maintain the nmh port for FreeBSD and I've gotten a request to update it to 1.1-RC1. Updating to release _candidates_ would normally make me kind of nervous, but given the release history and that the RC was, what, about 4 months ago now, I was wondering if anyone had any thoughts on whether or not I should. If so, should the savannah.gnu.org download site be the official source of the tarball? Any thoughts or recommendations would be welcome! Scott
Working on the install-mh change questions
I've started working on the changes for the mh installation thing discussed earlier. My plan is to modify context_read() to print a message instead of invoking install-mh, and to add a -check option to install-mh that allows it to silently check for installation, returning the status via the exit code. There's a bunch of strange stuff in context_read() that seems unnecessary. I'd like to get rid of it, but want to check with y'all in case there's some undocumented historic necessity of which I'm unaware. I know that these are picky things, but I'm just not in the write-sloppy-and-slow-software-camp even though computers are pretty darned fast these days. 1. The program starts by checking to see whether or not defpath has been set, and bails if it has. Apparently a test in case it's called more than once. I've checked all of the other programs, and it never is. defpath is unnecessarily checked in a number of other places: sbr/context_del.c sbr/context_find.c sbr/context_replace.c sbr/seq_read.c sbr/seq_save.c uip/flist.c uip/folder.c uip/rmf.c I'd prefer to see asserts used to check for dumb programming errors. 2. Next there's a test to see if mypath is set, and setting it is skipped if it's already set. Again, I don't see any way that this could occur. 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? 5. There's code that removes a trailing / from mypath if mypath is more than one character long. Seems completely unnecessary; the definition of path names means that // is interpreted as /. And if that wasn't the case, this code wouldn't catch multiple trailing slashes anyway. 6. If an MH environment variable is set and doesn't begin with a / the MH environment variable is changed to the profile path. Why bother? It's never used by anything. Exec'd programs can get figure this out if they need to - any exec'd nmh program does that anyway. Jon
Another working on the install-mh change question
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? Jon
