Path: utzoo!attcan!uunet!snorkelwacker!apple!agate!eos!shelby!SUMEX-AIM.STANFORD.EDU!lane From: lane@SUMEX-AIM.STANFORD.EDU (Christopher Lane) Newsgroups: comp.sys.next Subject: Re: .login file Message-ID: Date: 15 Oct 90 15:41:56 GMT References: <9215@milton.u.washington.edu> Sender: Christopher Lane Organization: Internet-USENET Gateway at Stanford University Lines: 24 In <9215@milton.u.washington.edu>, wiml@milton.u.washington.edu writes: > >... I think the preferred way to have arbitrary things happen when you >log in is to use the defaults database: > >dwrite loginwindow LoginHook /some/program/name >dwrite loginwindow LogoutHook /some/other/program > >... On the other hand, I think these are global defaults (everyone who >logs in on the console has these programs run). The hook would have to >do whatever differentiation is neccessary. More specifically, root has to dwrite the LoginHook since loginwindow runs as root. Also, the program that is the LoginHook actually runs before the user is logged in (intended as a login verification) so the user id will still be root (though you can determine the user from the argument to the LoginHook). I wouldn't recommend using the current LoginHook as a way of doing user specific initialization. Perhaps someone could design a 'dummy' Workspace application that looked in the user database for something to execute on start up and then started up the 'real' Workspace application. - Christopher -------