mcr@julie.UUCP (Michael Richardson) (09/10/89)
Dan Heller writes: >Use the -source arguemnt to mush when you start up: > >% mush -source script_file > >This file is sourced after your folder has been read in. Most of my customization of my .mushrc has been based around the advanced.mushrc file included in the tar. One thing struck me as quite odd --- the .mushrc file is read before the folder is. There is all this stuff with $first_time, etc... which seemed silly --- why not a command (which could be called from the init file) that would cause the mailbox to be read in? That way the .mushrc could deal with pre-initialisation, and then sort my mail too. (The first thing I always do in mush is to type 'n' anyway...) Is there some reason that this would be difficult to implement? (I'm asking before I stick my head in mush source for a day or two... :-)) -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ WORK: michael@fts1.UUCP
argv%turnpike@Sun.COM (Dan Heller) (09/12/89)
In article <0576.AA0576@julie> mcr@julie.UUCP (Michael Richardson) writes: > Dan Heller writes: > >Use the -source arguemnt to mush when you start up: > >% mush -source script_file > >This file is sourced after your folder has been read in. > > Most of my customization of my .mushrc has been based around > the advanced.mushrc file included in the tar. One thing struck me as > quite odd --- the .mushrc file is read before the folder is. There is > all this stuff with $first_time, etc... which seemed silly --- why > not a command (which could be called from the init file) that > would cause the mailbox to be read in? Part of the initialization of mush is to "read in init file(s), load folder specified, process commands from user-interface". Loading a folder from your .mushrc isn't wise because not everything has been initialized such as tmpdir, and other variables that are important to the startup process. If a folder has been loaded during initialization, then initialization might change certain values that could lose changes or might do some interaction with the user -- this isn't the place to do that stuff. The reason $first_time is used is to demonstrate that the .mushrc can be reused -- possibly recursively. Many people forget that mush is more of a "shell" than it is a Mail-clone. The use of command line aliases, history, and variable usage greatly enhances the usability of the product. dan <island!argv@sun.com> ----- My postings reflect my opinion only -- not the opinion of any company.
scott@grlab.UUCP (Scott Blachowicz) (09/13/89)
>In article <10569@dasys1.UUCP> gts@dasys1.UUCP (G. T. Samson) writes: > > Hi there. I've finally figured out a proper way to use the > "pick" command (from inside a script file), but for the life > of me, I can't figure out how to get this script file to > execute automatically! > > What I'm trying to do is to toss out certain mail, move other > mail to separate mailboxes for later perusal, etc. - all the > things that the "pick" command does best. Now, how do I get > this to happen every time that mush starts up? I know that I > shouldn't put it in the .mushrc file, as no messages have yet > been read in when that's executed... but I even tried to bind > the command that I want to run to a key, and it wouldn't let > me pass an argument. I've done the same sort of thing, but I don't have it run when I read my mail. I run it as a "batch job" out of crontab. I setup a script that cleans out my mail folder directory (archive old messages into an "old/" directory and compress them; delete old messages out of folders). The script looks like this (I imagine there are better ways to do this, but this one has worked for a while, so I don't muck with it): --------------------- #! /bin/sh # # Usage: clean_mboxes [<folder_directory>] # cd ${1:-$HOME/mboxes} if [ ! -d old ] then mkdir old 2>/dev/null fi { ls -F | # Generate mbox filenames grep -v / | # Filter out directories (e.g. the old/ dir) # Now, this generates the MUSH commands to delete messages from # +backup that are > 3 months old and archive messages older than # 4 months from other folders. awk ' { if ($1 == "backup") { print "folder " $1 " | pick -ago -3m | delete"; } else { print "uncompress old/" $1; print "folder " $1 " | pick -ago -4m | save old/" $1 " | delete"; print "compress -v old/" $1; } } END { print "quit"; }' } >/tmp/cmb.$$ 2>&1 # Give all those commands to MUSH and filter out some of the messages. /usr/local/bin/mush -i < /tmp/cmb.$$ 2>&1 | sed -n ' /^Saved/p /^Appended/p /^Updating/p /^"/p /^old\//p ' rm -f /tmp/cmb.$$ -- Scott Blachowicz E-mail: scott@grlab.UUCP USPS: Graphicus ..or.. ...!hpubvwa!grlab!scott 150 Lake Str S, #206 VoicePh: 206/828-4691 Kirkland, WA 98033 FAX: 206/828-4236
mcr@julie.UUCP (Michael Richardson) (09/14/89)
I wrote: mcr> not a command (which could be called from the init file) that mcr> would cause the mailbox to be read in? Dan Heller wrote: dan>Part of the initialization of mush is to "read in init file(s), load folder dan>specified, process commands from user-interface". Loading a folder from dan>your .mushrc isn't wise because not everything has been initialized such dan>as tmpdir, and other variables that are important to the startup process. I guess I didn't phrase my question properly. I'm asking why a command like `mush_init' couldn't cause all the above to happen, and then continue execution of the script. (Or even, "init_to script-file", if maintaining an open script is too difficult. The script-file(s) specified in the different init files [e.g. /usr/lib/mushrc, .mushrc] might even all take effect once the folder has loaded, etc...) The init_to command might not even cause the init file to terminate or even for the script to run immediately, but rather to continue on and run when all the initialisation is complete. >The reason $first_time is used is to demonstrate that the .mushrc can be >reused -- possibly recursively. Many people forget that mush is more of >a "shell" than it is a Mail-clone. The use of command line aliases, >history, and variable usage greatly enhances the usability of the product. I'm just not sure that the $first_time example is a particularly great example of the programming/shell features of mush... (An aside --- my boss was looking for a way to print out a folder, one per page to a laser. I handed him mush. [He still uses /bin/mail. All my mail from him says `Apparently-To:' :-)]) But, I think there are enough examples of good usage in there to get people going... -- :!mcr!: Michael Richardson Amiga v--------+ UUCP: uunet!attcan!lsuc!nrcaer!julie!mcr | INTERNET mcr@doe.carleton.ca Fido: Michael Richardson @ 1:163/109.10<--+ WORK: michael@fts1.UUCP
schaefer@CSE.OGC.EDU (Barton E. Schaefer) (09/19/89)
On Sep 14, 2:39pm, Michael Richardson wrote: } Subject: Re: .mushrc && folders (was Help with auto-processing of messages } } I wrote: } mcr> [why] not a command (which could be called from the init file) that } mcr> would cause the mailbox to be read in? } } Dan Heller wrote: } dan>Part of the initialization is to "read in init file(s), load folder } dan>specified, process commands from user-interface". } } I guess I didn't phrase my question properly. I'm asking why a command } like `mush_init' couldn't cause all the above to happen, and then continue } execution of the script. Something sort of like this is under consideration. A brief word on why it isn't easily done at the moment: Mush's initialization is presently handled by two functions, main() and init(). main() passes a structure pointer to parse_options(), which reads the command line and returns the file name for the -source option (and, in the 6.5.6.xx beta and 7.0 alpha releases, the -init option), among other things. main() first calls init(), which hunts down various things from the environment and the system (like the hostname); next it sources the init files; loads the folder; sources the -source file if any; and finally calls the command interpreter. Note that most of the information obtained by parse_options() is saved only in a structure that is local to main(). It is therefore somewhat difficult to arrange for commands from sourced files to modify this data. Also, since sourcing is handled by a separate function, it's equally hard let main() continue upon command and then resume sourcing later. Using the -source option is at present the best solution. } The init_to command might not even cause the init file to terminate } or even for the script to run immediately, but rather to continue } on and run when all the initialisation is complete. In effect, the "something sort of like this" being considered is a set of commands that would allow changing of (SOME of) the command line args from within the program. One of these would be the -source file name. A drawback is that we are reluctant to add more global variables to the scads already in use. Also, to do this the Right Way, provision must be made for multiple -source names (currently only one is allowed). } >The reason $first_time is used is to demonstrate that the .mushrc can be } >reused -- possibly recursively. Many people forget that mush is more of } >a "shell" than it is a Mail-clone. } } I'm just not sure that the $first_time example is a particularly } great example of the programming/shell features of mush... You're right, it isn't a great example of shell features. It's an example of re-using the same init file for more than one task. We included it because a number of people had asked about doing that. } But, I think } there are enough examples of good usage in there to get people } going... We hope so. :-) -- Bart Schaefer "And if you believe that, you'll believe anything." -- DangerMouse CSNET / Internet schaefer@cse.ogc.edu UUCP ...{sequent,tektronix,verdix}!ogccse!schaefer