Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!wuarchive!udel!princeton!jonlab!jon
From: jon@jonlab.UUCP (Jon H. LaBadie)
Newsgroups: comp.sys.att
Subject: Re: Answer to my own KSH history question (I got no responses)
Summary: A relatively painless exit trap may work for you also
Message-ID: <815@jonlab.UUCP>
Date: 24 Oct 89 11:19:54 GMT
References: <1989Oct21.185944.1165@ntvax.uucp> <2011@cjsa.WA.COM>
Organization: 4455 Province Line Rd., Princeton, NJ 08540
Lines: 58

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