Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!cs.utexas.edu!uunet!mcvax!kth!sunic!dkuug!freja!seindal
From: schaefer@ogccse.ogc.edu (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Sourcing (and not sourcing) Mushrc
Message-ID: <4674@freja.diku.dk>
Date: 20 Jul 89 00:42:39 GMT
Sender: seindal@freja.diku.dk
Lines: 85

In article <5395@xenna.Xylogics.COM> loverso@Xylogics.COM (John Robert LoVerso) writes:
} 
} BTW, I just put up 6.5.6 and installed the new default Mushrc.  Next time
} I ran mush, it said "oh I see you're a new user to mush...".  While this
} behavior might be desireable for someone who's really a new user to mush,
} having to create a .mushexpert file to elide that behavior just clogs my
} home directory.

I have this overwhelming urge to say "I told you so" to the people who
wanted "install" directives added to the makefiles.  So I guess I told
them so. :-)

There should be more instructions in the README to the effect that the
Mushrc should be edited before installation.  Sorry.

} Worse still, I realized that mush was always sourcing the
} default Mushrc (before my .mushrc!).

Would you rather it sourced the default Mushrc AFTER it sourced yours?!?
The idea is that your .mushrc overrides the defaults ...

Sourcing of a system-wide init file has been in Mush since (I think) 6.3.
Before 6.5.5, the system-wide init file was /usr/lib/Mail.rc.  Dan felt it
was appropriate for Mush to have it's own file instead of relying on the
one from ucbMail.  If you don't want the new Mushrc to be used, modify
config.h to change DEFAULT_RC to /dev/null, or swap the defs of DEFAULT_RC
and ALT_DEF_RC.

} So, naturally I thought to use "mush -n"
} to prevent the sourcing of it, but that also prevents it from sourcing my
} .mushrc - and leaves me with no identical way of having my .mushrc sourced
} before the folder is read.  *Sigh*.  I wouldn't mind leaving the new default
} Mushrc there for new users, but when a user has a .mushrc,
} mush shouldn't go off and amuse what it should be sourcing.

Amused init files are definitely no laughing matter. :-)

The original intent behind sourcing a global init file was to allow the
system administrator to define a common base environment for all users.
(For example, the /usr/lib/Mail.rc file here is:
	set append
	set ask
	set dot
	set keep
	set save
	ignore Message-Id Resent-Message-Id Status
	ignore Received Mail-From Return-Path Via
so everybody gets those settings.)  Many of the ucbMail settings don't
apply to mush (e.g. keep, save, and append above), so we changed it
to a separate global Mushrc.  Exactly what is appropriate to include
in that file is *still* under discussion, but we couldn't wait forever
to post patch #5 ....

If you have comments on what should be included in Mushrc, and where an
appropriate place for a "demo .mushrc" would be, feel free to follow up
to this posting.

} My fix: I left
} the Mushrc there, but removed the code from main.c that first sources Mushrc
} and then goes off to source the .mushrc.  (It even looks from this code that
} if I don't have a .mushrc, it will source Mushrc twice!).

Yes, now that you mention it, that is a bug.  It almost never comes up,
because nearly everyone has either a .mushrc or a .mailrc, both of which
are looked for before the second source of Mushrc is done.  We'll get it
patched for the SunView-port version.

} Lastly, while it's nice mush no longer makes complains about changing the
} "From:" header, it still provides its own (incorrect) "From:" header, even
} when I've got a better set in my_hdrs.

This is a known problem.  In case you hadn't noticed, mush also inserts
the In-Reply-To header twice when using $edit_hdrs.  We have fixes for
both of these; everything is awaiting testing of the SunView stuff.

} I've now been using mush for nearly 10 months - thats the longest I've stuck
} with a new mailer ever.
} Anyway, this is to say, "mush is great - thanks a lot, Dan, Bart, et al!".

You're welcome.  We'll try to do even better next time. :-)
-- 
Bart Schaefer           "And if you believe that, you'll believe anything."
                                                            -- DangerMouse
CSNET / Internet                schaefer@cse.ogc.edu
UUCP                            ...{sequent,tektronix,verdix}!ogccse!schaefer