1.1 --- a/discussion.roff	Wed Jul 04 16:23:01 2012 +0200
     1.2 +++ b/discussion.roff	Wed Jul 04 16:28:39 2012 +0200
     1.3 @@ -104,8 +104,7 @@
     1.4  For example, a wrapper script for qmail would be:
     1.5  .VS
     1.6  #!/bin/sh
     1.7 -# ignore command line arguments
     1.8 -exec qmail-inject
     1.9 +exec qmail-inject  # ignore command line arguments
    1.10  VE
    1.11  The requirement to parse the recipient addresses out of the message header 
    1.12  is likely to be removed in the future.
    1.13 @@ -3275,36 +3274,193 @@
    1.14  
    1.15  .H2 "Profile Reading
    1.16  .P
    1.17 -FIXME XXX
    1.18 -
    1.19 -commit 3e017a7abbdf69bf0dff7a4073275961eda1ded8
    1.20 -Author: markus schnalke <meillo@marmaro.de>
    1.21 -Date:   Wed Jun 27 14:23:35 2012 +0200
    1.22 -
    1.23 -    spost: Read profile and context now. Removed -library switch.
    1.24 -    spost is a full part of the mmh toolchest, hence, it shall read the
    1.25 -    profile/context. This will remove the need to pass profile information
    1.26 -    from send to spost via command line switches.
    1.27 -    In January 2012, there had been a discussion on the nmh-workers ML
    1.28 -    whether post should read the profile/context. There wasn't a clear
    1.29 -    answer. It behavior was mainly motivated by the historic situation,
    1.30 -    it seems. My opinion on the topic goes into the direction that every
    1.31 -    tool that is part of the mmh toolchest should read the profile. That
    1.32 -    is a clear and simple concept. Using MH tools without wanting to
    1.33 -    interact with MH (like mhmail had been) is no more a practical problem.
    1.34 -
    1.35 -commit 32d4f9daaa70519be3072479232ff7be0500d009
    1.36 -Author: markus schnalke <meillo@marmaro.de>
    1.37 -Date:   Wed Jun 27 13:15:47 2012 +0200
    1.38 -
    1.39 -    mhmail: Read the context!
    1.40 -    mhmail will change from a mailx-replacment to an alternative to
    1.41 -    `comp -ed prompter', thus being a send front-end. Hence, mhmail
    1.42 -    should not stay outside the profile/context respecting mmh toolchest.
    1.43 -
    1.44 -
    1.45 -slocal
    1.46 -
    1.47 +The MH profile contains the configuration for the user-specific MH setup.
    1.48 +MH tools read the profile right after starting up,
    1.49 +as it contains the location of the user's mail storage
    1.50 +and similar settings that influence the whole setup.
    1.51 +Further more, the profile contains the default switches for the tools,
    1.52 +hence, it must be read before the command line switches are processed.
    1.53 +.P
    1.54 +For historic reasons, some MH tools did not read the profile and context.
    1.55 +Among them were
    1.56 +.Pn post /\c
    1.57 +.Pn spost ,
    1.58 +.Pn mhmail ,
    1.59 +and
    1.60 +.Pn slocal .
    1.61 +The reason why these tools ignored the profile were not clearly stated.
    1.62 +During the discussion on the nmh-workers mailing list,
    1.63 +.[
    1.64 +nmh-workers levine post profile
    1.65 +.]
    1.66 +David Levine posted an explanation, quoting John Romine:
    1.67 +.QS
    1.68 +I asked John Romine and here's what he had to say, which
    1.69 +agrees and provides an example that convinces me:
    1.70 +.QS
    1.71 +My take on this is that post should not be called by
    1.72 +users directly, and it doesn't read the .mh_profile
    1.73 +(only front-end UI programs read the profile).
    1.74 +.QP
    1.75 +For example, there can be contexts where post is called
    1.76 +by a helper program (like 'mhmail') which may be run by
    1.77 +a non-MH user.  We don't want this to prompt the user
    1.78 +to create an MH profile, etc.
    1.79 +.QP
    1.80 +My suggestion would be to have send pass a (hidden)
    1.81 +`\-fileproc proc' option to post if needed.  You could also
    1.82 +use an environment variable (I think send/whatnow do
    1.83 +this).
    1.84 +.QE
    1.85 +I think that's the way to go.  My personal preference is to use a command line option, not an environment variable.
    1.86 +.QE
    1.87 +.P
    1.88 +To solve the problem of
    1.89 +.Pn post
    1.90 +not honoring the
    1.91 +.Pe fileproc
    1.92 +profile entry,
    1.93 +the community roughly agreed that a switch
    1.94 +.Sw -fileproc
    1.95 +should be added to
    1.96 +.Pn post
    1.97 +to be able to pass a different fileproc.
    1.98 +I strongly disagree with this approach because it does not solve
    1.99 +the problem; it only removes a single symptom.
   1.100 +The problem is that
   1.101 +.Pn post
   1.102 +does not behave as expected.
   1.103 +But all programs should behave as expected.
   1.104 +Clear and simple concepts are a precondition for this.
   1.105 +Hence, the real solution is having all MH tools read the profile.
   1.106 +.P
   1.107 +Yet, the problem has a further aspect.
   1.108 +It mainly originates in
   1.109 +.Pn mhmail .
   1.110 +.Pn mhmail
   1.111 +was intended to be a replacement for
   1.112 +.Pn mailx
   1.113 +on systems with MH installations.
   1.114 +.Pn mhmail
   1.115 +should have been able to use just like
   1.116 +.Pn mailx ,
   1.117 +but sending the message via MH's
   1.118 +.Pn post
   1.119 +instead of
   1.120 +.Pn sendmail .
   1.121 +Using
   1.122 +.Pn mhmail
   1.123 +should not be influenced by the question whether the user had
   1.124 +MH set up for himself or not.
   1.125 +.Pn mhmail
   1.126 +did not read the profile as this requests the user to set up MH
   1.127 +if not done yet.
   1.128 +As
   1.129 +.Pn mhmail
   1.130 +used
   1.131 +.Pn post ,
   1.132 +.Pn post
   1.133 +could not read the profile neither.
   1.134 +This is the reason why
   1.135 +.Pn post
   1.136 +does not read the profile.
   1.137 +This is the reason for the actual problem.
   1.138 +It was not much of a problem because
   1.139 +.Pn post
   1.140 +was not intended to be used by users directly.
   1.141 +.Pn send
   1.142 +is the interactive front-end to
   1.143 +.Pn post .
   1.144 +.Pn send
   1.145 +read the profile and passed all relevant values on the command line to
   1.146 +.Pn post
   1.147 +\(en an awkward solution.
   1.148 +.P
   1.149 +The important insight is that
   1.150 +.Pn mhmail
   1.151 +is no true MH tool.
   1.152 +The concepts broke because this outlandish tool was treated as any other
   1.153 +MH tool.
   1.154 +Instead it should have been treated accordingly to its foreign style.
   1.155 +The solution is not to prevent the tools reading the profile but
   1.156 +to instruct them reading a different profile.
   1.157 +.Pn mhmail
   1.158 +could have set up a well-defined profile and caused all MH tools
   1.159 +in the session use it by exporting an environment variable.
   1.160 +With this approach, no special cases would have been introduced,
   1.161 +no surprises would have been caused.
   1.162 +By writing a clean-profile-wrapper, the concept could have been
   1.163 +generalized orthogonally to the whole MH toolchest.
   1.164 +Then Rose's motivation behind the decision that
   1.165 +.Pn post
   1.166 +ignores the profile, as quoted by Jeffrey Honig,
   1.167 +.[
   1.168 +nmh-workers post profile
   1.169 +.]
   1.170 +would have become possible:
   1.171 +.QS
   1.172 +when you run mh commands in a script, you want all the defaults to be
   1.173 +what the man page says.
   1.174 +when you run a command by hand, then you want your own defaults...
   1.175 +.QE
   1.176 +.LP
   1.177 +Yet, I consider this explanation short-sighted.
   1.178 +We should rather regard theses two cases as just two different MH setups,
   1.179 +based on two different profiles.
   1.180 +Mapping such problems on the concepts of switching between different
   1.181 +profiles, solves them once for all.
   1.182 +.P
   1.183 +In mmh, the wish to have
   1.184 +.Pn mhmail
   1.185 +as as replacement for
   1.186 +.Pn mailx
   1.187 +is considered obsolete.
   1.188 +Mmh's
   1.189 +.Pn mhmail
   1.190 +does no longer cover this use-case.
   1.191 +Currently,
   1.192 +.Pn mhmail
   1.193 +is in a transition state.
   1.194 +.Ci 32d4f9daaa70519be3072479232ff7be0500d009
   1.195 +It may become a front-end to
   1.196 +.Pn comp ,
   1.197 +which provides an interface more convenient in some cases.
   1.198 +In this case,
   1.199 +.Pn mhmail
   1.200 +will become an ordinary MH tool, reading the profile.
   1.201 +If, however, this idea will not convince, then
   1.202 +.Pn mhmail
   1.203 +will be removed.
   1.204 +.P
   1.205 +Every program in the mmh toolchest reads the profile.
   1.206 +The only exception is
   1.207 +.Pn slocal ,
   1.208 +which is not considered part of the mmh toolchest.
   1.209 +This MDA is only distributed with mmh, currently.
   1.210 +Mmh has no
   1.211 +.Pn post
   1.212 +program, but
   1.213 +.Pn spost ,
   1.214 +which now reads the profile.
   1.215 +.Ci 3e017a7abbdf69bf0dff7a4073275961eda1ded8
   1.216 +With this change,
   1.217 +.Pn send
   1.218 +and
   1.219 +.Pn spost
   1.220 +can be considered to be merged.
   1.221 +Direct invocations of
   1.222 +.Pn spost
   1.223 +are only done by the to-be-changed
   1.224 +.Pn mhmail
   1.225 +implementation and by
   1.226 +.Pn rcvdist ,
   1.227 +which will require rework.
   1.228 +.P
   1.229 +The
   1.230 +.Fu context_foil()
   1.231 +function to pretend to have read an empty profile was removed.
   1.232 +.Ci 68af8da96bea87a5541988870130b6209ce396f6
   1.233 +All mmh tools read the profile.
   1.234  
   1.235  
   1.236