BASH历史记录在每次登录时被截断为500行

由于某种原因，我无法让系统在重启后保留BASH历史记录。这是我的相关部分~/.bashrc：

shopt -s histappend
PROMPT_COMMAND='history -a; updateWindowTitle'
export HISTCONTROL=ignoredups
export HISTSIZE=9999
export HISTFILESIZE=999999
export HISTFILE="$HOME/.bash_history"

据我所知，所有这些都是必要的选项（我知道我曾经能够在多次重新启动后保留历史记录，而过去却没有所有这些选项）。但是，尽管之前已在几次重新引导中添加了这些选项，但在重新引导后，我仍然失去了大部分历史记录。它不是空的，但是没有重新启动前的9999行。

在有人抱怨之前，是的，我已经阅读了这些问题。我已经执行了上面列出的一些建议，其余建议没有帮助或不相关：

• 使用histappend时Bash历史记录丢失
• 如何防止Bash更改历史记录？
• 什么决定了bash history命令中显示的内容？
• 如何在各个会话之间保留bash历史记录？
• 定期保存bash历史记录

如果那里可能还有其他相关命令，您可以~/.bashrc 在此处查看我的全部内容。

那么，我想念什么？为什么我的历史记录没有保存？如果有人认为其他文件可能相关，请告诉我，我将其发布。我通过运行grep -i hist \.*进行检查，$HOME该结果显示唯一相关的.文件包含字符串hist或HIST为.bashrc。

我正在运行Linux Mint Debian Edition，GNU bash，版本4.2.36（1）-发行版（x86_64-pc-linux-gnu），而我最喜欢的终端模拟器是（如果相关）terminator。

更新：

遵循@mpy在评论中的建议，我~/.bashrc将set 改为HISTFILE=~/bash_history默认值~/.bash_history，这似乎解决了交互式shell的问题。登录外壳仍然显示相同的行为，历史记录在行处被截断500。但是，HIST在相关文件中没有设置相关变量：

$ for f in /etc/profile ~/.profile ~/.bash_profile ~/.bash_login; do \
   echo -ne "$f :"; echo `grep HIST $f`; \
done
/etc/profile :
/home/terdon/.profile :grep: /home/terdon/.profile: No such file or directory
/home/terdon/.bash_profile :grep: /home/terdon/.bash_profile: No such file or directory
/home/terdon/.bash_login :grep: /home/terdon/.bash_login: No such file or directory
$ grep -r HIST /etc/profile.d/  <-- returns nothing

那么，除非我明确将default 设置为默认值，否则为什么set HISTSIZE和HISTFILESIZEin ~/.bashrc还不够？$HISTFILE~/.bash_history

问题实际上归结为登录和非登录外壳的不同行为。我已经设置了控制历史记录的变量~/.bahsrc。当启动登录shell时不会读取此文件，只能由交互式非登录shell（从man bash）读取：

当bash作为交互式登录shell或带有--login选项的非交互式shell被调用时，它首先从文件/etc/profile（如果该文件存在）中读取并执行命令。读取该文件后，它将按顺序查找〜/ .bash_profile ~/.bash_login和~/.profile，并从存在且可读的第一个命令中读取并执行命令。--noprofile启动外壳程序以禁止此行为时，可以使用该选项。

[。。。]

启动不是登录外壳程序的交互式外壳程序时，如果该文件存在，则bash从〜/ .bashrc读取并执行命令。使用--norc选项可以禁止这种情况。--rcfile file选项将强制bash从文件而不是〜/ .bashrc中读取并执行命令。

因此，每次我登录，放下tty或使用ssh时，.history文件都会被截断，因为我也没有将其设置为正确的大小~/.profile。我终于意识到了这一点，只需将变量设置~/.profile 在它们所属的位置，而不是~/.bashrc

因此，我~/.history被截断的原因是因为我只在交互式非登录外壳程序读取的文件中设置了HISTORY变量，因此，每次我运行不同类型的外壳程序时，变量都将被忽略，并且文件将被剪切。相应地。

我的建议是使用另一个文件作为HISTFILE默认文件~/.bash_history。

尽管我没有分析性的解释，但我将尝试概述导致我提出此建议的原因：如果您将其bash用作默认的（登录）shell，并且还使用X（两者都很有可能），则bash在（图形） 登录：

systemd
 ...
  |-login
  |   `-bash      <<====
  |       `-slim
  |           |-X -nolisten tcp vt07 -auth /var/run/slim.auth
  |           |  `-{X}
  |           `-fluxbox
  |               `-xterm -bg black -fg white
  |                   `-bash
 ...

我认为此实例是一个登录shell，因此它不会读取您的信息~/.bashrc，因此不会对该histappend选项有所了解：

man bash（1）：启动不是登录 shell 的交互式shell 时，bash会从/etc/bash.bashrc和〜/ .bashrc中读取并执行命令（如果存在）。（...）

只要此“父外壳”运行，一切都很好，但是在终止（即系统停止）时，它将覆盖~/.bash_history（因为这是默认值）并弄乱您的历史记录或在系统启动时将其裁剪为（再次默认）500线。（或者也许两者都...）

我也感到很惊讶，仅在中包含历史记录配置是不够的~/.bashrc，因为这不是一个罕见的设置。我对此没有任何解释。

关于您的问题，“登录外壳仍然显示相同的行为”，您可以尝试在~/.bash_profile以下位置也包括历史记录配置：

man bash（1）：当bash作为交互式登录shell或使用--login选项作为非交互式shell调用时，它首先从文件/ etc / profile中读取并执行命令（如果该文件存在）。读取该文件后，它将查找〜/ .bash_profile，（...）

不幸的是bash，由于我是zsh个人，我无法发布更合理的解释，其中包含我自己的配置中的详细信息。

由于所有设置均按照手册页排列，并且历史文件不受大小（字节）的限制，因此我能想到的唯一可能的解释是。它与外壳的死方式有关。

根据在线参考，仅当shell收到SIGHUP时，才会正常退出（保存历史记录）。我无法真正解释重启时系统如何传播信号，但我怀疑您的Shell会因SIGKILL或SIGPWR而退出。

这可能是因为您的WM异步运行（等待），并且从bash所在的WM生成了终端仿真器，而不是收到SIGHUP以外的退出强制信号。也可能是OS会在初始正常的SIGHUP设法通过X-> WM-> xterm到达外壳之前迅速将“最终终止”发送到所有进程，这可能是因为X或WM退出需要比退出更长的时间。操作系统需要准备就绪才能停机。

我在使用这些东西的情况很深，但是我认为遵循这些原则的某些行为会导致行为不稳定。我以前遇到过这个问题，最可靠的解决方法是exit在bash中保留历史记录。

我注意到history -a了您的问题，我想不出为什么那不足以保存历史。

您可以通过找出导致Bash真正消失的原因来解决问题，然后继续找出信号的来源并在那里修复问题，或者在知道哪个信号是最后一个信号时简单地刷新历史记录（假设那时磁盘仍处于联机状态） ）：

trap "echo got 1  >/tmp/sig1;  exit" SIGHUP
trap "echo got 2  >/tmp/sig2;  exit" SIGINT
trap "echo got 15 >/tmp/sig15; exit" SIGTERM
 .. and so on...

随附的屏幕快照说明了我在第二段和第三段中所说的内容。该序列有我在外壳左，杀右和猫的历史左壳。

猛男

在启动时，如果需要，将（...）以HISTFILE值命名的文件截断为不超过由HISTFILESIZE值指定的行数（+默认值500）。

如果启用了histappend shell选项（此处为+缺省设置），则这些行将附加到历史文件中，否则将覆盖历史文件。

在线参考

3.7.6信号

当Bash是交互式的时，在没有任何陷阱的情况下，它会忽略SIGTERM（这样，“ kill 0”不会杀死交互式shell），并且会捕获和处理SIGINT（这样，可中断内置的wait）。当Bash收到SIGINT时，它将脱离任何执行循环。在所有情况下，Bash都会忽略SIGQUIT。如果作业控制有效（请参阅作业控制），则Bash会忽略SIGTTIN，SIGTTOU和SIGTSTP。

由Bash启动的非内置命令将信号处理程序设置为shell从其父级继承的值。当作业控制无效时，除了这些继承的处理程序之外，异步命令还会忽略SIGINT和SIGQUIT。由于命令替换而产生的命令将忽略键盘生成的作业控制信号SIGTTIN，SIGTTOU和SIGTSTP。

默认情况下，在收到SIGHUP时，shell退出。退出之前，交互式外壳程序会将SIGHUP重新发送给所有正在运行或已停止的作业。已停止的作业将发送给SIGCONT，以确保它们收到了SIGHUP。为防止外壳将SIGHUP信号发送到特定作业，应使用内置的disown将其从作业表中删除（请参阅内置的作业控制），或使用disown -h将其标记为不接收SIGHUP。

如果已经使用shopt设置了huponexit shell选项（请参见内置Shopt），则Bash在退出交互式登录Shell时将SIGHUP发送到所有作业。

如果Bash正在等待命令完成并接收到已设置陷阱的信号，则在命令完成之前将不执行陷阱。当Bash通过等待内置函数等待异步命令时，接收到已设置陷阱的信号将导致等待内置函数立即返回，退出状态大于128，然后立即执行陷阱。

示范屏幕截图

检查/ etc / profile和/etc/profile.d/*

也许那里的历史设置有些混乱。