schaefer@ogccse.ogc.edu (Barton E. Schaefer) (07/20/89)
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
loverso@Xylogics.COM (John Robert LoVerso) (07/20/89)
In article <3750@ogccse.ogc.edu> schaefer@ogccse.UUCP (Barton E. Schaefer) writes: > Would you rather it sourced the default Mushrc AFTER it sourced yours?!? > The idea is that your .mushrc overrides the defaults ... I forgot to mention the driving reason behind what I did. My thoughts are that my .mushrc completely overrides the `default' Mushrc. I don't want to have to possibly undo whatever my system administrator added in there. (well, I'm him, but that's besides the point). If I really want the stuff in Mushrc, I can always put a "source /usr/local/lib/mush/Mushrc" in MY own .mushrc. I'd be happy with an option ("-N"?) that just prevented mush from sourcing the Mushrc, but left the sourcing of my .mushrc alone. (ps: I've always had my own "make install" for mush, which copies to /usr/local/lib/mush, among other things, the numerous README files, etc). John
comp-mail-mush@srhqla.sr.com (07/20/89)
From: island!argv (Dan Heller) > On Jul 14, 10:01am, Barton E. Schaefer wrote: > On Jul 14, 3:57pm, John Robert LoVerso wrote: > } Subject: Re: Sourcing (and not sourcing) Mushrc > } > } In article schaefer@ogccse.UUCP (Barton E. Schaefer) writes: > } > Would you rather it sourced the default Mushrc AFTER it sourced yours?!? > } > The idea is that your .mushrc overrides the defaults ... > } I forgot to mention the driving reason behind what I did. My thoughts are > } that my .mushrc completely overrides the `default' Mushrc. I don't want > } to have to possibly undo whatever my system administrator added in there. > > Perhaps "-I init_file" to specify a file to be read before the folder is > loaded, in the same way that -F reads one after the folder is loaded. > Then you could use > > mush -n -I ~/.mushrc > I agree that there should be an option to not source the system init file. I like -I, but would ammend that there can be a filename appended to the arg in the following (ugly) manner: -I/usr/lib/Mushrc or: -I In the first case (the init file desired is attached to the arg), then that file is used rather than the default init file. If no filename is attached to -I, then no default init file is used. As for the user's .mushrc file, that can already be changed by the $MAILRC env variable. With the above scheme, it is now possible to configure, at runtime, the location of both the default and the user's mushrc. Also, you can specify not to source either one of them. I realize the syntax for -I as I've proposed it is ugly and incosnstent with the rest of the mush args, but at least it solves this problem :-) --dan