
<<LoginCommandsDoc.Tioga>>
<<Last Edited by: Spreitzer, March 18, 1984 9:19:57 pm PST>>

    LoginCommands facilitates customizing pool machines to individuals, without their getting in each other's way.
How to Use it:
    When making a checkpoint on a public machine, make sure that LoginCommands has been run before the checkpoint is made.  This can be 
    done either via the PreRun option in user profiles, or the CommandTool.BootCommands option, or by explicitly running it.  
    LoginCommands will not yet execute any commands; it waits untill after the checkpoint (unless you issue the EnableLoginCommands 
    command --- see below).
    Consider the plight of J.R. PoolUser. She would like certain programs (e.g., Walnut) to always be running when she is using a 
    machine, but she shouldn't put them in public checkpoints (and maybe not even in private ones).  She also would like all her 
    CommandTools customized in certain ways (e.g., a button that does opens from [Ivy]<PoolUser>), but again, this is not something 
    that belongs in public checkpoints.  LoginCommands to the rescue!  In her user profile, J.R. puts the following two entries:

    LoginCommands.PerLogin: "
    EnsureButton OpenHome [Ivy]<PoolUser>$CurrentSelection$
    Walnut
    "
    LoginCommands.PerCommandTool: "
    EnsureButton OpenHome [Ivy]<PoolUser>$CurrentSelection$
    "
    Whenever she logs into a public machine conveniently checkpointed with LoginCommands, these commands will be executed.  The first 
    set (PerLogin) will be executed in some one CommandTool (if there is one); then second set (PerCommandTool) will be executed in 
    all other CommandTools.
    EnsureButton, implemented by LoginCommands, is like CreateButton, except that it does a RemoveButton first.  This means J.R. does 
    not have to look at C.B. Peon's OpenHome button.
    Note a difficulty with the CommandTool.EachCommandToolCommands user profile entry.  If J.R. sets it to be:

    CommandTool.EachCommandToolCommands: "
    EnsureButton OpenHome [Ivy]<PoolUser>$CurrentSelection$
    "
    when she is making a checkpoint on a public machine, her OpenHome button will be in the checkpoint; this is wrong.  LoginCommands 
    provides a way out:

    CommandTool.EachCommandToolCommands: "
    DoPerCommandTool
    "
    DoPerCommandTool is a command that will immediately execute the PerCommandTool commands in the CommandTool in which it is given, 
    but only if LoginCommands is enabled.  Since LoginCommands is not normally enabled untill after the checkpoint, this works just 
    right.
What it Does:
    LoginCommands' basic mission is to execute commands from the user's profile whenever a user logs in or rolls back.  There are two 
    UserProfile entries that LoginCommands interprets:

    LoginCommands.PerLogin: TOKEN _ ""
    LoginCommands.PerCommandTool: TOKEN _ ""

    When LoginCommands decides it is "time to customize", it tries to execute the PerLogin commands in some CommandTool, and the 
    PerCommandTool commands in all the other CommandTools.  The PerLogin execution temporally precedes the PerCommandTool 
    executions.
    Since we don't want customization in public machine's checkpoint, LoginCommands will hold off doing anything untill it is enabled.  
    LoginCommands is enabled either by a rollback (this includes the rollback that is the last thing a checkpoint does) or by 
    executing the command EnableLoginCommands.
    Here are the commands that LoginCommands implements:

    LoginCommandsHere

        The CommandTool executing this command is remembered;  when it comes time to customize, this is the CommandTool used for the 
        PerLogin commands (unless this CommandTool is deleted in the interim).

    EnableLoginCommands

        Enables LoginCommands, then customizes.

    DoPerCommandTool

        Immediately executes, in the CommandTool where this command is being given, the PerCommandTool login commands.

    ///Commands/EnsureButton

        Like the standard CreateButton, except that it first does a RemoveButton.