Any way to timestamp ksh .sh_history file entries?

[Ken Bell]

Is there some clever trick to get timestamps on the history
file entries for ksh? Sometimes it would be oh so useful to
have them there.

--
Ken Bell : kb...@giss.nasa.gov : 212-678-5526 : 678-5552 (fax)
======== : ken...@panix.com : 212-475-4976

[Leszek Leszczynski]

True, it would be a VERY nice feature.... As a first approach - far from
perfect but better than nothing we could try something like - print -s
"# $(date)" in the crontab.... (-s options redirects the output to the
history file instead of stdout)... Regards....

[Norman Levin]

I don't know what this will do to the history file, but
if you were to open a separate window or background the
following program

while true
do
date >> ~/.sh_history
sleep 600
done
--
Norman Levin
vm/dynAmIX inc.

[Ken Bell]

Leszek Leszczynski <les...@softsystem.com.pl> writes:
> True, it would be a VERY nice feature.... As a first approach - far from
> perfect but better than nothing we could try something like - print -s
> "# $(date)" in the crontab.... (-s options redirects the output to the
> history file instead of stdout)... Regards....

and Norman Levin <norma...@ibm.net> writes:
> I don't know what this will do to the history file, but
> if you were to open a separate window or background the
> following program
>
> while true
> do
> date >> ~/.sh_history
> sleep 600
> done

Either of the above methods (with a "#" prepended to the output of
'date' in Norman Levin's example) provide an arbitrarily configurable
way to home in on the time that a given command got entered, but I was
hoping more for real timestamping of individual commands. Another
concern is that this "addon" timestamping process can easily end up
stepping on ksh's own updates to the history file, since there is no
way to synchronize the multiple (dual) writes.

Storing periodic snapshots of the history file in some dedicated
directory is one way to avoid dealing with multiple write access to the
file, and permits a similar "windowing" of command times, but it's not
very convenient in practice. I'm starting to think that maybe "bash",
given that source code is available, is a better way to go.

[certified computer guy...]

>
>Either of the above methods (with a "#" prepended to the output of
>'date' in Norman Levin's example) provide an arbitrarily configurable
>way to home in on the time that a given command got entered, but I was
>hoping more for real timestamping of individual commands. Another
>concern is that this "addon" timestamping process can easily end up
>stepping on ksh's own updates to the history file, since there is no
>way to synchronize the multiple (dual) writes.
>
>Storing periodic snapshots of the history file in some dedicated
>directory is one way to avoid dealing with multiple write access to the
>file, and permits a similar "windowing" of command times, but it's not
>very convenient in practice. I'm starting to think that maybe "bash",
>given that source code is available, is a better way to go.
>
>--

Hadn't seriously thought about this to much, so don't laugh to loud if I'm
way out there.....but,
Suppose you put a "wrapper" around the shell....e.g replace /usr/bin/ksh
with your own script which logged the time into .sh_history, then executed
the "real" ksh passing your command and arguments to it. Might work, but
may have unpredictable results too. I may have to try that on one of our
test machines.....I do miss those old mainframe audit trails with their
exact to-the-second timestamp for each and every command entered.

[Leszek Leszczynski]

I wish we had "IBM wish list" somewhere.... nice feature and easy to
implement in ksh.... instead of escaping to "bash"....
BTW: most probably you do not have to worry about synchronizing writes to the
history file - print -s - is a standard ksh option so it it will take care
about synchronization.... and, besides write() with O_APPEND is an atomic
operation.....
I could have some doubts about ">>" redirection since history file is not pure
ASCII file but this may work too.....
Regards, Leszek Leszczynski

Ken Bell wrote:

> Leszek Leszczynski <les...@softsystem.com.pl> writes:
> > True, it would be a VERY nice feature.... As a first approach - far from
> > perfect but better than nothing we could try something like - print -s
> > "# $(date)" in the crontab.... (-s options redirects the output to the
> > history file instead of stdout)... Regards....
>
> and Norman Levin <norma...@ibm.net> writes:
> > I don't know what this will do to the history file, but
> > if you were to open a separate window or background the
> > following program
> >
> > while true
> > do
> > date >> ~/.sh_history
> > sleep 600
> > done
>

> Either of the above methods (with a "#" prepended to the output of
> 'date' in Norman Levin's example) provide an arbitrarily configurable
> way to home in on the time that a given command got entered, but I was
> hoping more for real timestamping of individual commands. Another
> concern is that this "addon" timestamping process can easily end up
> stepping on ksh's own updates to the history file, since there is no
> way to synchronize the multiple (dual) writes.
>
> Storing periodic snapshots of the history file in some dedicated
> directory is one way to avoid dealing with multiple write access to the
> file, and permits a similar "windowing" of command times, but it's not
> very convenient in practice. I'm starting to think that maybe "bash",
> given that source code is available, is a better way to go.
>
> --

[Joe Moore]

In article <7ossta$26...@babylon.giss.nasa.gov>,

Ken Bell <kb...@giss.nasa.gov> wrote:
>
>Either of the above methods (with a "#" prepended to the output of
>'date' in Norman Levin's example) provide an arbitrarily configurable
>way to home in on the time that a given command got entered, but I was
>hoping more for real timestamping of individual commands. Another
>concern is that this "addon" timestamping process can easily end up
>stepping on ksh's own updates to the history file, since there is no
>way to synchronize the multiple (dual) writes.
>
>Storing periodic snapshots of the history file in some dedicated
>directory is one way to avoid dealing with multiple write access to the
>file, and permits a similar "windowing" of command times, but it's not
>very convenient in practice. I'm starting to think that maybe "bash",
>given that source code is available, is a better way to go.
>
>--
>Ken Bell : kb...@giss.nasa.gov : 212-678-5526 : 678-5552 (fax)
>======== : ken...@panix.com : 212-475-4976

How about printing the date into the history as part of the prompt?

(UNTESTED:)
PS1='$((date >> ~/.history)) #'

Or something like that. This might be a good question to ask comp.unix.shell

--Joe

--
If Schrodinger falls in a forest and nobody is around,
would he exist both in a state of making a sound and
not making a sound?

[Matthew Landt]

How about... get a copy of gnuksh or a shareware KSH version where you can
get the source code and tweek the source to do what you want it to.

Ken Bell wrote:

> Leszek Leszczynski <les...@softsystem.com.pl> writes:
> > True, it would be a VERY nice feature.... As a first approach - far from
> > perfect but better than nothing we could try something like - print -s
> > "# $(date)" in the crontab.... (-s options redirects the output to the
> > history file instead of stdout)... Regards....
>
> and Norman Levin <norma...@ibm.net> writes:
> > I don't know what this will do to the history file, but
> > if you were to open a separate window or background the
> > following program
> >
> > while true
> > do
> > date >> ~/.sh_history
> > sleep 600
> > done
>

> Either of the above methods (with a "#" prepended to the output of
> 'date' in Norman Levin's example) provide an arbitrarily configurable
> way to home in on the time that a given command got entered, but I was
> hoping more for real timestamping of individual commands. Another
> concern is that this "addon" timestamping process can easily end up
> stepping on ksh's own updates to the history file, since there is no
> way to synchronize the multiple (dual) writes.
>
> Storing periodic snapshots of the history file in some dedicated
> directory is one way to avoid dealing with multiple write access to the
> file, and permits a similar "windowing" of command times, but it's not
> very convenient in practice. I'm starting to think that maybe "bash",
> given that source code is available, is a better way to go.
>
> --
> Ken Bell : kb...@giss.nasa.gov : 212-678-5526 : 678-5552 (fax)
> ======== : ken...@panix.com : 212-475-4976

--
________________________________________________________
Matthew Landt la...@austin.ibm.com

Comments, views, and opinions are mine alone, not IBM's.

[Norman Levin]

While time stamping the history file might be of use, I'm completely amazed at
the output of the vmstat command which is USELESS - unless each line entry is
time stamped. How can you look at this output and know when a problem
occurred?
How could you plot pi or po against time of day? You can't. This is an
example
of a command written by somebody because they could - but obviously had no
idea
of performance analysis.
--
Norman (glad I got that off my chest - only 105 in dallas) Levin
vm/dynAmIX inc.

[Leszek Leszczynski]

Yeah, another very good point... There are some simple scripts to timestap vmstat
output out there (one of them was published in AIXpert), I bet you have them - but
give me a note if you need one....

Leszek Leszczynski
IBM Certified Advanced Technical Expert
Soft Computer Consultants, Ltd mailto:les...@softcomputer.com,
34350 US Highway 19N Palm Harbor FL 34681; USA
Softsystem Spolka Z o.o. mailto:les...@softsystem.com.pl
02-678 Warszawa ul. Szturmowa 4; Poland

[jrkno...@my-deja.com]

After playing around a bit, I've found that I can do realtime stamping
as follows:

1. create a function to do the stamping

function histstamp
{
print -s "#$(date)"
}

2. trap the DEBUG event in ksh

trap 'histstamp' DEBUG

The stamping needs to be in a function because functions do not inherit
the DEBUG trap, which would be triggered by the print statement
otherwise.

- Rod Knowlton

In article <7ossta$26...@babylon.giss.nasa.gov>,

Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.

[Dr. Markus]

In article <7ps1d0$d29$1...@nnrp1.deja.com>,

jrkno...@my-deja.com wrote:
> After playing around a bit, I've found that I can do realtime stamping
> as follows:
>
> 1. create a function to do the stamping
>
> function histstamp
> {
> print -s "#$(date)"
> }
>
> 2. trap the DEBUG event in ksh
>
> trap 'histstamp' DEBUG
>
> The stamping needs to be in a function because functions do not
inherit
> the DEBUG trap, which would be triggered by the print statement
> otherwise.
>
> - Rod Knowlton
>

- YES?
- and how would I implement this?
Markus

[jrkno...@my-deja.com]

In article <7q0ft8$hvk$1...@nnrp1.deja.com>,

I had done it by entering the function definition and trap on the
command line. To have it on whenever you logon, you could place them in
the file specified in your ENV variable. I'd try it from the command
line first, though, and be sure that you like having all those
timestamps when going back through history on the command line. Also
you'll find that some commands, like man, use sh behind the scenes.
This results in error messages, because sh inherits the trap but not
the function.

Another, probably better, approach would be to cron a script at
whatever interval you'd like that checks the timestamps of itself and
the history file. If the history file is newer, have the script print a
datestamp to history and then touch itself.

Rod Knowlton

[Matthew Landt]

Ok this is a very good method for time stamping. Unfortunately, this
has
only fed my coding/scripting fire and I would like to find out the
different
signals that can be trapped in AIX, what those signals are, and what
causes
them to be generated. I know the general SIG signals found and pretty
clearly explained in /usr/include/sys/signals.h. But signals like DEBUG
are not
part of that.

Thanks in advance

- Matt

--
________________________________________________________
Matthew Landt la...@austin.ibm.com

Comments, views, and opinions are mine alone, not IBM's.

jrkno...@my-deja.com wrote:

[Rod Knowlton]

In article <37C409EB...@austin.ibm.com>,

Matthew Landt <la...@austin.ibm.com> wrote:
> Ok this is a very good method for time stamping. Unfortunately, this
> has
> only fed my coding/scripting fire and I would like to find out the
> different
> signals that can be trapped in AIX, what those signals are, and what
> causes
> them to be generated. I know the general SIG signals found and pretty
> clearly explained in /usr/include/sys/signals.h. But signals like
DEBUG
> are not
> part of that.
>
> Thanks in advance

I found the DEBUG signal, along with other special signals and trap
statement behavior, in David Korn's "The New Kornshell Command and
Programming Language" (ISBN 0-13-182700-6), but it's also available in
InfoExplorer (Korn Shell or POSIX Shell Built-In Commands: par 75) on
our 4.2.1 system.

Hope this helps,

Rod

>
> - Matt
>
> --
> ________________________________________________________
> Matthew Landt la...@austin.ibm.com
>
> Comments, views, and opinions are mine alone, not IBM's.
>
> jrkno...@my-deja.com wrote:
> >
> > After playing around a bit, I've found that I can do realtime
stamping
> > as follows:
> >
> > 1. create a function to do the stamping
> >
> > function histstamp
> > {
> > print -s "#$(date)"
> > }
> >
> > 2. trap the DEBUG event in ksh
> >
> > trap 'histstamp' DEBUG
> >
> > The stamping needs to be in a function because functions do not
inherit
> > the DEBUG trap, which would be triggered by the print statement
> > otherwise.
> >
>