Bash 没有针对 SIGQUIT 的特殊处理程序，并且不参与创建核心转储的过程。当且仅当核心转储的 rlimit 足够大时，内核才会将核心转储写入为 SIGQUIT 的“默认操作”的一部分；该 rlimit 可能是通过登录根据 limit.conf 中的内容建立的，也可能是使用 ulimit 等手动调整的。
我不太明白“Bash 没有特殊的 SIGQUIT 处理程序”。
每个进程都有信号处理程序，即使其中一些是默认的，并且通常一个进程获取其默认信号处理程序，并从中fork()复制其父进程的信号处理程序，并且execve()不更改信号处理程序，这是否正确？
bash 进程从哪里获取其默认信号处理程序/陷阱？
在 APUE 中，我无法找到login（或getty启动序列中的其他程序）是否是第一个设置默认信号处理程序（以及来自 的资源限制/etc/security/limits.conf，这是链接中主题的中心）并通过它们一直到登录 shell：
如果我们正确登录，登录将
• 更改到我们的主目录(chdir)
• 更改我们的终端设备的所有权 (chown)，以便我们拥有它
• 更改终端设备的访问权限，以便我们有权读取和写入它
• 通过调用setgid 和initgroups 设置我们的组ID
• 使用登录拥有的所有信息初始化环境：我们的主目录 (HOME)、外壳 (SHELL)、用户名（USER 和 LOGNAME）以及默认路径 (PATH)
• 更改为我们的用户 ID (setuid) 并调用我们的登录 shell，如下所示
execl("/bin/sh", "-sh", (char *)0);