Paul Fox <[email protected]> writes: >[email protected] wrote: >> Right now, all but the first line, of .mh_profile, assigning a given va= >riable >> is silently ignored. This seems wrong to me. All but the last assignmen= >t >> should be ignored. Maybe an admonish message should be issued then. >> = > >> But multiple assignment to the same variable, is almost always a user e= >rror. > >(by "same variable", i assume you mean "profile entry"?) > >> So maybe the program (i.e. pretty much every nmh command) should then a= >bort. > >i disagree. the system copy of mhn.defaults contains fallback >definitions, and the user is free to override those with entries in >.mh_profile or with $MHSHOW or $MHSTORE. that's the whole point of >having one's own copy. it would be very clumsy if one couldn't >do that without causing an error. > >or perhaps i misunderstand.
Sorry for the confusion. By "multiple assignments", I meant multiple assignment within .mh_profile, or perhaps, more generally, multiple assignments within any one file. >paul > >> = > >> Ken Hornstein <[email protected]> writes: >> >> > Why the first instead of the last? Maybe because that's the way Br= >uce Borden >> >> > happened to program reading the lines of .mh_profile, one afternoo= >n during the >> >> > American Civil War? Or is there a better reason? >> >> >> >>if the search order was "system-installed file first", then using the >> >>last match would make sense. but since the user's profile comes >> >>first, it has to be able to override the system setting, otherwise it >> >>would be useless. >> >> >> >>the fact that the $MHSHOW/$MHBUILD etc variables come in between make= >s >> >>no sense -- one would usually view an environment variable as a >> >>high-priority override, but not in this case. >> > >> >I think some of this might be simple oversight. >> > >> >The way readconfig() is implemented now, a new profile entry won't ove= >rride >> >an existing one. So like Paul said, it makes sense to read the files >> >you want to override everything else first. >> > >> >I went back and looked; MHSHOW was always read after .mh_profile was >> >loaded (MHSHOW was added for nmh). But thinking about this, this >> >doesn't really make sense; you'd think a program-specific environment >> >variable should override .mh_profile. So maybe this is a case that >> >Richard Coleman didn't really think this through, or it was a simple >> >bug, or he had reasons for doing it that we don't know. >> > >> >I think it would make more sense to have MHSHOW profile entries overri= >de >> >.mh_profile(), but that's a post-1.6 change I think. >> > >> >--Ken >> > >> >_______________________________________________ >> >Nmh-workers mailing list >> >[email protected] >> >https://lists.nongnu.org/mailman/listinfo/nmh-workers >> = > >> Norman Shapiro >> = > >> _______________________________________________ >> Nmh-workers mailing list >> [email protected] >> https://lists.nongnu.org/mailman/listinfo/nmh-workers > >=3D---------------------- >paul fox, [email protected] (arlington, ma, where it's 73.0 degree= >s) Norman Shapiro _______________________________________________ Nmh-workers mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/nmh-workers
