Paul Fox <pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us> writes:
norm(_at_)dad(_dot_)org 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 <kenh(_at_)pobox(_dot_)com> 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
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=
Norman Shapiro
=
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers
=3D----------------------
paul fox, pgf(_at_)foxharp(_dot_)boston(_dot_)ma(_dot_)us (arlington, ma,
where it's 73.0 degree=
s)
Norman Shapiro
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers