canoaf@ntvax.uucp (Augustine Cano) (10/22/89)
The original question: up to a point in time, every time I started a ksh, its history started with no commands at all, when the shell was terminated, its command history disappeared. Then, one day, every new ksh started would bring with it the same existing command history. The file ~/.kshistory was obviously being used by all ksh's, and it grew and grew. My question was: What had changed? why all of the sudden didn't the shells start with a blank history? The answer: It turns out that the key is in the ownership and permissions of ~/.kshistory. The permissions of this file are rw-------, if the file is owned by the user, it will be used by the shells. If it is owned by root, the shells can't access it and will therefore create a new history of their own. This is why .kshistory files turn up in /lost+found when crashes occur in the latter case, and not in the former. My guess is that ~/.kshistory was somehow deleted and that caused the behavior change. Augustine Cano
jeff@cjsa.WA.COM (Jeffery Small) (10/23/89)
canoaf@ntvax.uucp (Augustine Cano) writes: >The answer: It turns out that the key is in the ownership and permissions >of ~/.kshistory. The permissions of this file are rw-------, if the file >is owned by the user, it will be used by the shells. If it is owned by root, >the shells can't access it and will therefore create a new history of their >own. What I have observed is that when you "su" to root, your history file gets remade and is now owned by root. Now when you exit "su" back to your original login, ksh can still continue to use the history file (probably 'cause it's already opened) but when it comes time to remove it when you exit ksh, you can't because it is owned by root. -- Jeffery Small (206) 485-5596 uw-beaver!uw-nsr!uw-warp C. Jeffery Small and Associates !cjsa!jeff 19112 152nd Ave NE - Woodinville, WA 98072 uunet!nwnexus
jon@jonlab.UUCP (Jon H. LaBadie) (10/24/89)
In article <2011@cjsa.WA.COM>, jeff@cjsa.WA.COM (Jeffery Small) writes: > canoaf@ntvax.uucp (Augustine Cano) writes: > > >The answer: It turns out that the key is in the ownership and permissions > >of ~/.kshistory. The permissions of this file are rw-------, if the file > >is owned by the user, it will be used by the shells. If it is owned by root, > >the shells can't access it and will therefore create a new history of their > >own. > > What I have observed is that when you "su" to root, your history file gets > remade and is now owned by root. Now when you exit "su" back to your original > login, ksh can still continue to use the history file (probably 'cause it's > already opened) but when it comes time to remove it when you exit ksh, you > can't because it is owned by root. Jeffery is correct to a point, removal should not depend on file, but directory ownership. However, access to the data in the file is controlled by file ownership. To effect a workaround to the what I suspect is Augustino's problem, I implemented an exit trap on my ksh interactive sessions. The trap says if I am currently running as uid root, as I exit, the history file is chown'ed to my real id ("jon"). I put the relevant code in my ENV file so it is only executed for interactive ksh invocations. Here is the code from my "rather long" ENV file. The first part defines a function I use in a number of programs (uid) and could be imbedded in the trap rather than defined separately. # UNRELATED STUFF function uid { typeset x y x=`id` y=${x%%'(*'} echo ${y#uid=} } typeset -xf uid # UNRELATED STUFF # An su to root has a strange effect. The file specified as # "HISTFILE" is chown'ed to root. Thus, it can not be accessed # as jon any longer. This is a crude attempt to correct the # problem. trap ' [ `uid` = 0 ] && chown ${LOGNAME} ${HISTFILE:-${HOME}/.history} ' 0 # UNRELATED STUFF -- Jon LaBadie {att, princeton, bcr}!jonlab!jon {att, attmail, bcr}!auxnj!jon