Path: utzoo!censor!geac!jtsv16!uunet!bloom-beacon!CSE.OGC.EDU!schaefer
From: schaefer@CSE.OGC.EDU (Barton E. Schaefer)
Newsgroups: comp.mail.mush
Subject: Re: .mushrc && folders
Message-ID: <8909190438.AA29021@cse.ogc.edu>
Date: 19 Sep 89 04:38:27 GMT
Organization: The Internet
Lines: 67

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