dyer@arktouros.mit.edu (Steve Dyer) (03/02/89)
The 'csh' problem has been found and fixed. Apparently
the updates to AIX 2.2.1 had been "applied" but not "committed".
Weird. Redoing it from scratch fixed things.
---
Steve Dyer
dyer@arktouros.mit.edu
dyer@spdcc.com aka ...!{harvard,linus,ima,m2c,rayssd}!spdcc!dyersauer@auschs.UUCP (Charlie Sauer) (03/06/89)
In article <9550@bloom-beacon.MIT.EDU>, dyer@arktouros.mit.edu (Steve Dyer) writes: > The 'csh' problem has been found and fixed. Apparently > the updates to AIX 2.2.1 had been "applied" but not "committed". > Weird. Redoing it from scratch fixed things. The csh Steve was having trouble with was from the initial 2.2.1 install diskettes. The "mandatory" update diskettes that are supposed to come in the same box(es?) have the csh that I referred to in my previous belated posting. I haven't had trouble with that csh and, apparently, neither has Steve. But I don't understand the "committed" statement above. Since a reinstall has apparently been already performed, I don't think this can be diagnosed, but I suspect that the updates had been "rejected" after they were "applied." updatep, which manages the updates, allows one to "apply" the updates and try them out. Once applied, they are operational. E.g., in this case, /bin/csh should be the new one from the update diskettes, but until the commit, there is a copy of the old /bin/csh hidden where it can be retrieved by the reject option. If one likes the updates, they go ahead and commit them, and the hidden copy is deleted. If one doesn't then they can be rejected, and the prior version is reinstated. I'm normally trusting and just go ahead and apply/commit in one step, e.g., updatep -ac. Charlie -- C.H. Sauer IBM Advanced Workstations Div. !'s: cs.utexas.edu!ibmaus!sauer 11400 Burnet Road, D75/802 @'s: @CS.UTEXAS.EDU:sauer@ibmaus.uucp Austin, Texas 78758-2502 !&@: ibmaus!sauer@CS.UTEXAS.EDU (512) 823-3692 vnet: SAUER at AUSVM6