Robert has managed to articulate what I only had as vague feelings, and of course we were presented with someone who actually had profile entries under 'post' and had a legitimate (if surprising) reason to do so.
Thinking about this some more ... while it WOULD be weird, certainly a user could symlink "show" to "post", and then a profile entry for post would make perfect sense. I cannot think of any reason why you would do that, but it would be legitimate (and as we've seen, certainly people do plenty of things where I've said, "I can't think of any reason why you would that") >I also think that MH users are (by and large) able to deal with issues >like this, and preventing the occasional question to the list isn't worth >the effort of extra code, of making the profile parser bigger and even >messier (and also forcing a full read every time, which one day might >be good to avoid - just reading enoughto get the entry needed) and >just generally being obnoxious. Weeeelll .... the whole reason this started was because people aren't reading the documentation :-) Even Ralph (RALPH!) admitted he doesn't always read to the end of the post(8) man page all of the time :-) David brings up the point that on average, it's come up twice a year on the mailing list ... and that seems a lot to me. That suggests to me at the very least our documentation needs improving. I think I am leaning back to NOT having a warning, but I don't feel super strong about that. So, I went back and looked AGAIN at this. Currently, only "post", "install-mh", and "slocal" call context_foil() (the function that disables the reading of the profile). And even though David added a comment about this in sbr/mts.c, whom DOES read the profile (and as far as I can tell, it always did). Back in MH 6.8.5, the following programs called m_foil() (the precursor to context_foil()): conflict mhmail mhn post rmail sbboards slocal spop vmhtest This ... is an odd list, but there are some things in common. Most of these programs are designed be run by OTHER programs; that's true of post & mhn (other MH programs typically ran them, but not always true for mhn). rmail, sbboards, slocal & spop were designed to be run as local delivery agents. I can't really explain conflict; except maybe it was normally run via cron? mhmail was designed to be a replacement for Berkeley mail, so maybe it was intended that nothing in the MH profile would affect it. I have no idea what vmhtest was supposted to do, so don't ask me about it :-) To muddle the waters even further, spost DID read the profile explicitly. install-mh isn't on this list, but it did not use the profile to add to it's arguments. Along the way from MH to nmh, context_foil was dropped from mhn & added to spost. That left the other programs, but most of them (conflict, rmail, sbboards, spop, vmhtest) have been removed as obsolete. When David created nmh_init(), he changed install-mh to call context_foil() (which makes sense to me). mhmail has been changed to a shell script, which obviously doesn't check the profile either. What does this all mean? Well, people are still confused about it, which isn't great. I think improving our documentation would be good. Did Jay Dresser ever get email working? That WAS the original point of this thread, after all :-) --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers