Verlauf in Bashrc beim Anmelden im Vergleich zur manuellen Beschaffung – Löschen und Laden

Question

Ich verwende bei der Arbeit eine Reihe verschiedener AIX-Maschinen und muss Benutzer mit Kollegen teilen.

Um mir das Leben einfacher zu machen, ohne andere mit meinen Anpassungen zu belästigen, habe ich eine .bashrc-Datei erstellt, die ich nach /tmp/matthewh kopiere, wenn ich einen neuen Host verwenden muss.

Meine .bashrc legt eine neue Verlaufsdatei fest, sodass mein persönlicher Befehlsverlauf von anderen, die dieselbe Maschine und denselben Benutzer verwenden, isoliert bleibt.

# History options
export HISTTIMEFORMAT="%F %T "
export HISTCONTROL=ignorespace 
export HISTSIZE=2000
export HISTFILESIZE=2000
export HISTFILE="/tmp/matthewh/$USER.bash_history"

Nachdem ich die Datei kopiert habe, verbinde ich mich mit ssh user@host -t "bash --rcfile /tmp/matthewh/.bashrc".

Das funktioniert einwandfrei. Das Problem tritt auf, wenn ich zu einem anderen Benutzer wechsle und die .bashrc-Datei als Quelle verwende.

$ su - apache
$ . /tmp/matthewh/.bashrc

Das Problem besteht darin, dass zunächst der su - apacheVerlauf von Apache aus ~/.bash_history geladen wird und es dann zu spät ist, wenn ich .bashrc als Quelle verwende. Die Verlaufsdatei wird korrekt geändert, wurde aber bereits geladen. Ich kann dieses Problem beheben, indem ich ausführe. history -c && history -rIch muss das also nur auch in .bashrc einfügen und alles sollte in Ordnung sein, oder?

sshWenn ich das in meine .bashrc-Datei einfüge, geht leider alles kaputt, wenn ich mich mit und der Option anmelde -t "bash --rcfile /tmp/matthewh/.bashrc". Da es dadurch als Anmeldeshell verwendet wird, ist das Laden des Verlaufs Teil des Prozesses. Das bedeutet, dass die history -r.bashrc-Datei den Verlauf ein zweites Mal lädt und mein Arbeitsverlauf doppelt so groß ist, wie er sein sollte.

Gibt es eine Möglichkeit für .bashrc, zu erkennen, ob es manuell oder über eine Anmelde-Shell bezogen wird, sodass es den Verlauf nur bedingt löschen und neu laden kann?

Answer 1

Anstatt den Verlauf in der RC-Datei zu löschen und neu zu laden, verschieben Sie ihn, bis die Shell die erste Eingabeaufforderung ausgibt:

PROMPT_COMMAND='unset PROMPT_COMMAND; test -f $HISTFILE && history -c && history -r $HISTFILE'

Answer 2

Eine Möglichkeit besteht darin, herauszufinden, ob die SSH-Variablen festgelegt sind:

SSH_CLIENT='...'
SSH_CONNECTION='...'
SSH_TTY=/dev/pts/1

Wenn Sie "su -" verwenden, werden diese in der neuen Umgebung nicht gesetzt. Sie könnten also etwas wie Folgendes hinzufügen:

[ -z "$SSH_TTY" ] && history -c && history -r

Answer 3

Eine Lösung besteht darin, zu prüfen, ob die Verlaufsdatei leer ist oder nicht:

# If this was sourced manually history will not be empty
currhistsize="`history | wc -l`"
if [[ "${currhistsize// }" != "0" ]]; then
    # Clear the old history, then reload the correct history
    history -c
    history -r
fi

Die Verwendung von ${currhistsize// } war notwendig, da es viele führende Leerzeichen enthielt, die entfernt werden mussten.

Dies fühlt sich jedoch wie ein Workaround und nicht wie eine echte Lösung an. Mich würde eine geeignete Methode sehr interessieren, um zu überprüfen, ob die Datei manuell oder über eine Shell-Initialisierung bezogen wird.

Answer 4

Okay, hier ist eine andere Idee. Jede Bash-Sitzung hat eine eindeutige ID. Nur um sicherzugehen, können Sie auch einen eindeutigen Zeitstempel erstellen. Dies wird Ihr Problem nicht direkt lösen, und ich bin mir nicht sicher, ob es funktioniert, während ich es schreibe, aber jede neue Shell erstellt ihre eigene Verlaufsdatei basierend auf PID und Zeitstempel

Sie können in die .bashrc-Datei etwas wie

mypid=echo $$
mydatestamp=`date +"%Y%m%d_%H%M%S"`
export HISTFILE="/root/historyfiles/$mypid.$mydatestamp.bash_history"

So hältst du wenigstens alles getrennt.

Nicht getestet, wenn Sie sich also für diese Art von Idee entscheiden, müssen Sie wahrscheinlich daran herumbasteln, bis es funktioniert :)