# HG changeset patch # User markus schnalke # Date 1341412119 -7200 # Node ID cc35686f359e26d000374003c5d7d98b03769924 # Parent 83681ad27ec8f914110db0ad61cbe746b20b6ad8 Wrote about profile reading. diff -r 83681ad27ec8 -r cc35686f359e discussion.roff --- a/discussion.roff Wed Jul 04 16:23:01 2012 +0200 +++ b/discussion.roff Wed Jul 04 16:28:39 2012 +0200 @@ -104,8 +104,7 @@ For example, a wrapper script for qmail would be: .VS #!/bin/sh -# ignore command line arguments -exec qmail-inject +exec qmail-inject # ignore command line arguments VE The requirement to parse the recipient addresses out of the message header is likely to be removed in the future. @@ -3275,36 +3274,193 @@ .H2 "Profile Reading .P -FIXME XXX - -commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8 -Author: markus schnalke -Date: Wed Jun 27 14:23:35 2012 +0200 - - spost: Read profile and context now. Removed -library switch. - spost is a full part of the mmh toolchest, hence, it shall read the - profile/context. This will remove the need to pass profile information - from send to spost via command line switches. - In January 2012, there had been a discussion on the nmh-workers ML - whether post should read the profile/context. There wasn't a clear - answer. It behavior was mainly motivated by the historic situation, - it seems. My opinion on the topic goes into the direction that every - tool that is part of the mmh toolchest should read the profile. That - is a clear and simple concept. Using MH tools without wanting to - interact with MH (like mhmail had been) is no more a practical problem. - -commit 32d4f9daaa70519be3072479232ff7be0500d009 -Author: markus schnalke -Date: Wed Jun 27 13:15:47 2012 +0200 - - mhmail: Read the context! - mhmail will change from a mailx-replacment to an alternative to - `comp -ed prompter', thus being a send front-end. Hence, mhmail - should not stay outside the profile/context respecting mmh toolchest. - - -slocal - +The MH profile contains the configuration for the user-specific MH setup. +MH tools read the profile right after starting up, +as it contains the location of the user's mail storage +and similar settings that influence the whole setup. +Further more, the profile contains the default switches for the tools, +hence, it must be read before the command line switches are processed. +.P +For historic reasons, some MH tools did not read the profile and context. +Among them were +.Pn post /\c +.Pn spost , +.Pn mhmail , +and +.Pn slocal . +The reason why these tools ignored the profile were not clearly stated. +During the discussion on the nmh-workers mailing list, +.[ +nmh-workers levine post profile +.] +David Levine posted an explanation, quoting John Romine: +.QS +I asked John Romine and here's what he had to say, which +agrees and provides an example that convinces me: +.QS +My take on this is that post should not be called by +users directly, and it doesn't read the .mh_profile +(only front-end UI programs read the profile). +.QP +For example, there can be contexts where post is called +by a helper program (like 'mhmail') which may be run by +a non-MH user. We don't want this to prompt the user +to create an MH profile, etc. +.QP +My suggestion would be to have send pass a (hidden) +`\-fileproc proc' option to post if needed. You could also +use an environment variable (I think send/whatnow do +this). +.QE +I think that's the way to go. My personal preference is to use a command line option, not an environment variable. +.QE +.P +To solve the problem of +.Pn post +not honoring the +.Pe fileproc +profile entry, +the community roughly agreed that a switch +.Sw -fileproc +should be added to +.Pn post +to be able to pass a different fileproc. +I strongly disagree with this approach because it does not solve +the problem; it only removes a single symptom. +The problem is that +.Pn post +does not behave as expected. +But all programs should behave as expected. +Clear and simple concepts are a precondition for this. +Hence, the real solution is having all MH tools read the profile. +.P +Yet, the problem has a further aspect. +It mainly originates in +.Pn mhmail . +.Pn mhmail +was intended to be a replacement for +.Pn mailx +on systems with MH installations. +.Pn mhmail +should have been able to use just like +.Pn mailx , +but sending the message via MH's +.Pn post +instead of +.Pn sendmail . +Using +.Pn mhmail +should not be influenced by the question whether the user had +MH set up for himself or not. +.Pn mhmail +did not read the profile as this requests the user to set up MH +if not done yet. +As +.Pn mhmail +used +.Pn post , +.Pn post +could not read the profile neither. +This is the reason why +.Pn post +does not read the profile. +This is the reason for the actual problem. +It was not much of a problem because +.Pn post +was not intended to be used by users directly. +.Pn send +is the interactive front-end to +.Pn post . +.Pn send +read the profile and passed all relevant values on the command line to +.Pn post +\(en an awkward solution. +.P +The important insight is that +.Pn mhmail +is no true MH tool. +The concepts broke because this outlandish tool was treated as any other +MH tool. +Instead it should have been treated accordingly to its foreign style. +The solution is not to prevent the tools reading the profile but +to instruct them reading a different profile. +.Pn mhmail +could have set up a well-defined profile and caused all MH tools +in the session use it by exporting an environment variable. +With this approach, no special cases would have been introduced, +no surprises would have been caused. +By writing a clean-profile-wrapper, the concept could have been +generalized orthogonally to the whole MH toolchest. +Then Rose's motivation behind the decision that +.Pn post +ignores the profile, as quoted by Jeffrey Honig, +.[ +nmh-workers post profile +.] +would have become possible: +.QS +when you run mh commands in a script, you want all the defaults to be +what the man page says. +when you run a command by hand, then you want your own defaults... +.QE +.LP +Yet, I consider this explanation short-sighted. +We should rather regard theses two cases as just two different MH setups, +based on two different profiles. +Mapping such problems on the concepts of switching between different +profiles, solves them once for all. +.P +In mmh, the wish to have +.Pn mhmail +as as replacement for +.Pn mailx +is considered obsolete. +Mmh's +.Pn mhmail +does no longer cover this use-case. +Currently, +.Pn mhmail +is in a transition state. +.Ci 32d4f9daaa70519be3072479232ff7be0500d009 +It may become a front-end to +.Pn comp , +which provides an interface more convenient in some cases. +In this case, +.Pn mhmail +will become an ordinary MH tool, reading the profile. +If, however, this idea will not convince, then +.Pn mhmail +will be removed. +.P +Every program in the mmh toolchest reads the profile. +The only exception is +.Pn slocal , +which is not considered part of the mmh toolchest. +This MDA is only distributed with mmh, currently. +Mmh has no +.Pn post +program, but +.Pn spost , +which now reads the profile. +.Ci 3e017a7abbdf69bf0dff7a4073275961eda1ded8 +With this change, +.Pn send +and +.Pn spost +can be considered to be merged. +Direct invocations of +.Pn spost +are only done by the to-be-changed +.Pn mhmail +implementation and by +.Pn rcvdist , +which will require rework. +.P +The +.Fu context_foil() +function to pretend to have read an empty profile was removed. +.Ci 68af8da96bea87a5541988870130b6209ce396f6 +All mmh tools read the profile.