Comande historique Post: 99974

Sponsored Content

Operating Systems AIX Comande historique Post 99974 by Garry_Garrett on Wednesday 22nd of February 2006 07:21:41 PM

02-22-2006

Registered User

How your shell history is kept depends upon your shell (sh, csh, ksh, etc.). You are probably using Korn shell, which defaults to using .sh_history in the user's home directory to store a history in. You can change this by setting HISTFILE in your .profile. I would recommend setting the following in /etc/profile:

USER=`/usr/bin/who am i | /bin/cut -d' ' -f 1`
MYTTY=`/usr/bin/tty`
BASETTY=`/bin/basename ${MYTTY}`
HISTFILE=${HOME}/.hist.${USER}.${BASETTY}
export readonly HISTFILE
HISTORY=100000
export readonly HISTORY

A lot of books espouse using $$, your PID. This is dumb. You get a separate shell history per login, but you create a boatload of files that never get reused. These self same books will tell you to do something stupid like create a cron job to delete any of these that are more than 3 days old. 3 days! Try 6 months! With the above, as you only have one (pseudo) terminal for each login session, each login session will get their own history. However, you will reuse the ttys, so you will reuse the history files. If HISTORY is large enough, however, you'll go back far enough. You can, however, trace back who had which tty when via the "last" command. There is no way to historically trace the PID. If you don't want to reuse the history files, add the date:

DATE=`/bin/date "+%Y%m%d.%H%M"`

I would put it between .hist and ${USER}. The ${USER} part may seem superflous, but if you have some account used by multiple users (like say "oracle"), then this allows you to see who did what. Because you take the username off of "who", you see their name before they su'ed (and of course you are going to set RLOGIN to "no" for a user like oracle so that users are forced to login as themselves and then su to the account, so that you have a paper trail to follow).

If we are talking about some derviative of C shell (csh), you have to put something in the user's .cshrc file (.login will not due) like:

set history = 100000
set savehist = 100000

Actually the first one is how many history command to show when they type "history", so that you might make smaller. No way to make it read-only. No way to set the file's name, it saves in $HOME/.history (like it or not). Furthermore, ksh writes to the history as it goes. csh writes to .history when it exits. Login into two windows, exit out of window A, exit out of window B - the history saved by window A gets overwritten and is lost; only the history of window B gets saved. For this reason, if history is important to you, csh is not your first choice.

Bourne shell doesn't do history at all.

The catch 22 is, if users can write to their history files, users can trash their own history files. Nothing you can do about that (other than say frequent backups).

Last edited by Garry_Garrett; 02-22-2006 at 08:25 PM.. Reason: pronoun mistake

Garry_Garrett

View Public Profile for Garry_Garrett

Find all posts by Garry_Garrett

LEARN ABOUT MOJAVE

tklib_history

history(n)					       Provides a history for Entry widgets						history(n)

__________________________________________________________________________________________________________________________________________________

NAME

       history - Provides a history for Entry widgets

SYNOPSIS

       package require Tcl  8.4

       package require Tk  8.4

       package require history	?0.1?

       ::history::init pathName ?length?

       ::history::remove pathName

       ::history::add pathName text

       ::history::get pathName

       ::history::clear pathName

       ::history::configure pathName option ?value?

       bell

_________________________________________________________________

DESCRIPTION

       This package provides a convenient history mechanism for Entry widgets.	The history may be accessed with the up and down arrow keys.

       ::history::init pathName ?length?
	      Arranges	to  remember  the  history of the named Entry widget. An optional length determines the number of history entries to keep.
	      This may be changed later with ::history::configure. History entries must be added with the ::history::add command before  they  can
	      be seen.

       ::history::remove pathName
	      Forgets all history entries for the Entry pathName and removes the history bindings.

       ::history::add pathName text
	      This command is used to add history entries to an Entry that has previously had ::history::init called on it. This command should be
	      called from your Entry handler with the contents of the entry (or whatever you wish to add to the history).

       ::history::get pathName
	      This command returns a list containing the history entries for the Entry pathName

       ::history::clear pathName
	      This command clears the history list for the named Entry.

       ::history::configure pathName option ?value?
	      This command queries or sets configuration options. Currently the options recognized are length and alert. Setting the length deter-
	      mines the number of history entries to keep for the named Entry. Alert specifies the command to run when the user reaches the end of
	      the history, it defaults to

       bell

       entry .e
       bind .e <Return> [list ProcessEntry %W]
       ::history::init .e
       pack .e

       proc ProcessEntry {w} {
	   set text [$w get]
	   if {$text == ""} { return }
	   ::history::add $w $text
	   puts $text
	   $w delete 0 end
       }

KEYWORDS

       entry, history

history 								0.1								history(n)