ksh: separate sh_history files for each process?
Steve Wechsler
We have a couple of shared accounts that I'd like to set up so that each
login session gets its own unique sh_history file. Currently, every
process is writing to the same file, which makes recalling commands
almost useless.
ksh is being exec'ed by csh, which allows me to set the HISTFILE
environment variable before I enter ksh. Attaching a process id to the
file name is trivial enough, but how do you remove it on exit? ksh
doesn't seem to have any concept of a .logout file (or does it? I seem
to remember using this function in the past under AIX, but now I'm
running Solaris). I don't want a whole bunch of old history files
sitting around.
Thanks,
Steve
--
Steve Wechsler/Sybase DBA/CS First Boston
swec...@syseng.fbc.com
"When everyone's out to get you, paranoia is just good thinking"
-- "Dr." Johnny Fever
The opinions expressed above have absolutely no relation to those of
CSFB
Abusive flames posted publicly at my discretion. You have been warned.
Andrew Gierth
>>>>> "Steve" == Steve Wechsler <swec...@syseng.fbc.com> writes:
Steve> We have a couple of shared accounts that I'd like to set up so
Steve> that each login session gets its own unique sh_history file.
Steve> Currently, every process is writing to the same file, which
Steve> makes recalling commands almost useless.
Steve> ksh is being exec'ed by csh,
WHY??!?
Steve> which allows me to set the HISTFILE environment variable
Steve> before I enter ksh.
Setting it early enough in the .profile is sufficient.
Steve> Attaching a process id to the file name is trivial enough, but
Steve> how do you remove it on exit? ksh doesn't seem to have any
Steve> concept of a .logout file (or does it? I seem to remember
Steve> using this function in the past under AIX, but now I'm running
Steve> Solaris). I don't want a whole bunch of old history files
Steve> sitting around.
trap 'rm -f $HISTFILE' 0
--
Andrew Gierth (and...@microlise.co.uk)
"Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam
Dan Mercer
Steve Wechsler (swec...@syseng.fbc.com) wrote:
: We have a couple of shared accounts that I'd like to set up so that each
: login session gets its own unique sh_history file. Currently, every
: process is writing to the same file, which makes recalling commands
: almost useless.
: ksh is being exec'ed by csh, which allows me to set the HISTFILE
: environment variable before I enter ksh. Attaching a process id to the
: file name is trivial enough, but how do you remove it on exit? ksh
: doesn't seem to have any concept of a .logout file (or does it? I seem
: to remember using this function in the past under AIX, but now I'm
: running Solaris). I don't want a whole bunch of old history files
: sitting around.
: Thanks,
: Steve
: --
: Steve Wechsler/Sybase DBA/CS First Boston
: swec...@syseng.fbc.com
: "When everyone's out to get you, paranoia is just good thinking"
: -- "Dr." Johnny Fever
: The opinions expressed above have absolutely no relation to those of
: CSFB
: Abusive flames posted publicly at my discretion. You have been warned.
You can set the HISTFILE and HISTSIZE parameters in you ENV file, normally
~/.kshrc. You can also set a trap on exit:
trap '/bin/rm $HISTFILE' EXIT
--
Dan Mercer
Reply To: dame...@mmm.com
Rich Kus
In article <uy7mo7d...@nmo.gtegsc.com>,
David Karr <dk...@nmo.gtegsc.com> wrote:
>>>>>> "Steve" == Steve Wechsler <swec...@syseng.fbc.com> writes:
> Steve> login session gets its own unique sh_history file. Currently, every
> Steve> process is writing to the same file, which makes recalling commands
> Steve> almost useless.
>
> Steve> ksh is being exec'ed by csh, which allows me to set the HISTFILE
> Steve> environment variable before I enter ksh. Attaching a process id to the
> Steve> file name is trivial enough, but how do you remove it on exit? ksh
> Steve> doesn't seem to have any concept of a .logout file (or does it? I seem
> Steve> to remember using this function in the past under AIX, but now I'm
> Steve> running Solaris). I don't want a whole bunch of old history files
> Steve> sitting around.
>
>I create my history files as:
>
> /tmp/$USER.hist.$(uname -n).$$
>
>Then, I have a cron job that runs on all the hosts I use that checks
>for files of this form. For each file, it checks to see if that
>process id exists. If not, it deletes the file.
>
>I don't see a practical way to delete the file upon exit from the
>shell process.
>
could you make use of trap?
trap "/bin/rm /tmp/$USER.hist.$(uname -n).$$" 0
richk
>--
>============================================================================
>David M. Karr | Unix/X/C++/Emacs | GTE - Government Systems
>dk...@nmo.gtegsc.com | Software Engineer | w:(206)487-8578 h:(206)844-3896
Conrad E. Kimball
In article <uflocnm...@zen.microlise.co.uk>, and...@microlise.co.uk (Andrew Gierth) writes:
|> >>>>> "Steve" == Steve Wechsler <swec...@syseng.fbc.com> writes:
|>
|> Steve> We have a couple of shared accounts that I'd like to set up so
|> Steve> Currently, every process is writing to the same file, which
|> Steve> makes recalling commands almost useless.
|>
|> Steve> ksh is being exec'ed by csh,
|>
|>
|> Steve> which allows me to set the HISTFILE environment variable
|> Steve> before I enter ksh.
|>
|> Setting it early enough in the .profile is sufficient.
True, but possibly not completely helpful - the key is just what is
"early enough", particularly when .profile or .kshrc contain a function
defintion, or source another file that contains a function definition.
From a Korn shell programming notes file I wrote a while ago:
# As a special case of this, it can be tricky to set up the Korn
# shell HISTFILE variable to direct ksh's history file to a user-
# specified path.
#
# Once the history file has been established, it is futile to change
# the HISTFILE variable. The rule the Korn shell follows for
# establishing its history file is:
#
# For interactive shells, ksh opens or creates the history file at
# the earlier of: the first function definition it reads while the
# nolog option is off; the first time the history file is referenced,
# e.g. with a "print -s" or "read -s"; or after the environment file
# (i.e. .kshrc) has been read and executed.
#
# For non-interactive shells, ksh opens or creates the history file
# the first time it is referenced.
#
# This sounds rather simple, but remember that the Korn shell parses
# an entire sourced file before executing any commands (though it
# reads ~/.profile and ~/.kshrc line-by-line). And note that the
# Korn shell will by default record all function definitions in its
# history file - this can be disabled by the "set -o nolog" command,
# but again, remember that the function definitions are seen (and
# recorded) during the parse of the file, before any commands are
# executed.
#
# So, if you have function definitions in your ~/.profile or ~/.kshrc
# and you want to redirect ksh's history file, you must set HISTFILE
# anywhere in the file before your first function definition; however
# if you want to set HISTFILE in another file sourced by ~/.profile
# or ~/.kshrc, and that file also contains function definitions, you
# must resort to some subterfuge.
#
# One technique is to "hide" the function definition inside quotes
# and then at execution time, after you've set HISTFILE, "eval" the
# definition to define the function. If you like to put function
# definitions at the top, before you set HISTFILE, you can put the
# function definition in a shell variable and "eval" that variable
# after you've set HISTFILE. An example:
#
# # hide a function definition, so HISTFILE works
# # (this occurs before the HISTFILE definition, as it is my
# # personal style to put functions at the top of the file; it
# # could also be put after the HISTFILE definition)
#
# MyFunctionDefinition='
# function MyFunction
# {
# print -r - "MyFunction called - arguments are: $@"
# }
# '
#
# # establish HISTFILE, so each shell has its own history
#
# export HISTFILE=~/.ksh.history.$(uname -n).$$
#
# # now eval the variable containing the definition, to define the
# # function, and unset the temporary variable holding the definition
#
# eval "${MyFunctionDefinition}"
# unset MyFunctionDefinition
--
Conrad Kimball | Client Server Tech Svcs, Boeing Information & Supt.
c...@bcstec.ca.boeing.com | P.O. Box 24346, MS 7M-HC
(206) 865-6410 | Seattle, WA 98124-0346
Dan Mercer
Andrew Gierth (and...@microlise.co.uk) wrote:
: >>>>> "Steve" == Steve Wechsler <swec...@syseng.fbc.com> writes:
: Steve> We have a couple of shared accounts that I'd like to set up so
: Steve> that each login session gets its own unique sh_history file.
: Steve> Currently, every process is writing to the same file, which
: Steve> makes recalling commands almost useless.
: Steve> ksh is being exec'ed by csh,
: WHY??!?
I can't speak for him, but we do that in one account where we use
remsh (rsh to non SYSV) to manage the account. The .cshrc is always
sourced which means we can set up a default environment - in particular,
the PATH. The default PATH for remsh is rather limited
/bin/:/usr/bin:/usr/local/bin:/usr/contrib/bin
so we set it to include the directories we want. But when I log into
that account, I want to work in ksh.
: Steve> which allows me to set the HISTFILE environment variable
: Steve> before I enter ksh.
: Setting it early enough in the .profile is sufficient.
: Steve> Attaching a process id to the file name is trivial enough, but
: Steve> how do you remove it on exit? ksh doesn't seem to have any
: Steve> concept of a .logout file (or does it? I seem to remember
: Steve> using this function in the past under AIX, but now I'm running
: Steve> Solaris). I don't want a whole bunch of old history files
: Steve> sitting around.
: trap 'rm -f $HISTFILE' 0
: --
: Andrew Gierth (and...@microlise.co.uk)
: "Ceterum censeo Microsoftam delendam esse" - Alain Knaff in nanam
--
Steve Kives
> >>>>> "Steve" == Steve Wechsler <swec...@syseng.fbc.com> writes:
> Steve> We have a couple of shared accounts that I'd like to set up so
that each
> Steve> login session gets its own unique sh_history file. Currently, every
> Steve> process is writing to the same file, which makes recalling commands
> Steve> almost useless.
>
> Steve> ksh is being exec'ed by csh, which allows me to set the HISTFILE
> Steve> environment variable before I enter ksh. Attaching a process id
to the
> Steve> file name is trivial enough, but how do you remove it on exit? ksh
> Steve> doesn't seem to have any concept of a .logout file (or does it?
I seem
> Steve> to remember using this function in the past under AIX, but now I'm
> Steve> running Solaris). I don't want a whole bunch of old history files
> Steve> sitting around.
>
> I create my history files as:
>
> /tmp/$USER.hist.$(uname -n).$$
>
> Then, I have a cron job that runs on all the hosts I use that checks
> for files of this form. For each file, it checks to see if that
> process id exists. If not, it deletes the file.
>
> I don't see a practical way to delete the file upon exit from the
> shell process.
For .logout behavior, just alias exit to run a script instead, called
".logout" if you wish, which does some housecleaning then runs an explicit
"exit".
Another history mechanism is to put a "HISTFILE=$HOME/.histdir/hist.$$"
line in the .kshrc file, which is referenced for every new shell invocation.
In your .profile, put a line with "find $HOME/.histdir -mtime +28 -print |
xargs -l32 rm -f" to clean up old histfiles, older than four weeks. This is
nice for keeping around records of old sessions, to see how you screwed
something up several days ago.
Steve Kives
Marcus S. Yoo
I know of two tricks to do this.
If you have control over the envrionemnt variable before invoking ksh,
set HISTFILE to some unique file name (using hostname & pid, for example).
Also set ENV variable for ksh to source. In this ENV file, simply
remove the history file (rm -f $HISTFILE).
If you don't want to worry about history files, then here is what
I did. I created $HOME/.sh_history file, and made it non-readable
and non-writable.
% touch $HOME/.sh_history
% chmod 0 $HOME/.sh_history
Now, make sure the variable $HISTFILE is unset, or is set to $HOME/.sh_history,
when you invoke the next ksh, and all the ksh processes will have
their own private history, but you will not be able to save that
history for the next ksh process unless you do something.
The reason why I have (or rather, had) this problem was because I'm
running multiple windows on my X11 screen, each running a ksh.
Using the history mechanism was ....a bit difficult, to say the least,
especially when I had 4, 5, or more xterms each running ksh.
Well, I'm back to using zsh in xterms, which is a bit awkward
because my login shell (console, rlogin, etc.) is ksh. Oh well...
--
Marcus S. Yoo (my...@scr.siemens.com) | For God so loved the world, that he gave
Siemens Corporate Research, Inc. | his only begotten Son, that whosoever
755 College Rd. E., 609-734-3313 | believeth in him should not perish, but
Princeton, NJ 08540 fax: -6565 | have everlasting life. -- John 3:16
Jim Aites
But why limit the history file to a process? If you tie it to the tty then at
least it *might* be a real history next time you use a given terminal.
export HISTFILE=$HOME/.sh_`basename \`tty\``
(in the .profile)
--
-jim-
Dan Mercer
Dan Mercer (dame...@mmm.com) wrote:
: Steve Wechsler (swec...@syseng.fbc.com) wrote:
: : We have a couple of shared accounts that I'd like to set up so that each
: : login session gets its own unique sh_history file. Currently, every
: : process is writing to the same file, which makes recalling commands
: : almost useless.
: : ksh is being exec'ed by csh, which allows me to set the HISTFILE
: : environment variable before I enter ksh. Attaching a process id to the
: : file name is trivial enough, but how do you remove it on exit? ksh
: : doesn't seem to have any concept of a .logout file (or does it? I seem
: : to remember using this function in the past under AIX, but now I'm
: : running Solaris). I don't want a whole bunch of old history files
: : sitting around.
: : Thanks,
: : Steve
: : --
: : Steve Wechsler/Sybase DBA/CS First Boston
: : swec...@syseng.fbc.com
: : "When everyone's out to get you, paranoia is just good thinking"
: : -- "Dr." Johnny Fever
: : The opinions expressed above have absolutely no relation to those of
: : CSFB
: : Abusive flames posted publicly at my discretion. You have been warned.
: You can set the HISTFILE and HISTSIZE parameters in you ENV file, normally
: ~/.kshrc. You can also set a trap on exit:
: trap '/bin/rm $HISTFILE' EXIT
: --
: Dan Mercer
: Reply To: dame...@mmm.com
I just had another thought - you can always remove the HISTFILE immediately.
The ksh opens it and keeps it open. When your ksh exits finally,
the blocks will be returned (since the link count will be 0). The only
problem you would have is if you started a new shell, in which case
it would be recreated.
Eli The Bearded
Jim Aites <ai...@lvld.hp.com> wrote:
>But why limit the history file to a process? If you tie it to the tty then at
>least it *might* be a real history next time you use a given terminal.
This reminds me of a hack that works for csh and could be
modified for use here. Reusing the old history file when
you next log in is kinda boring if you don't remember
what's in it. If you create a history file with a bunch
of commands you find useful, then chmod it read-only,
you can have that history every time you login.
For ksh here, create the history file, copy it to some
unique name, then move it into place for the history of
each subshell you want. I haven't tried it, but it should
be doable.
Elijah
------
has been known to use ed purely for distinguishing it in history
Brian S Hiles
Brian Hiles (bsh20858.news.atc.fhda.edu) gratuitously interjects:
: Jim Aites (ai...@lvld.hp.com) wrote:
: export HISTFILE=$HOME/.sh_`basename \`tty\``
Good idea! But how about:
HISTFILE=$(tty) export HISTFILE=~/.sh_${HISTFILE##*/}
Saves a process....
-Brian
--
,---. ,---. ,---. ,---. ,---. ,---. ,---.
/ _ \ / _ \ / _ \ / _ \ / _ \ / _ \ / _ \
.' / \ `.' / mailto:bsh2...@challenger.atc.fhda.edu \ `.' / \ `.
__,' `.___,' `.___,' `.___,' `.___,' `.___,' `.___,' `.__