Bash não possui um manipulador especial para SIGQUIT e não está envolvido no processo de criação de um core dump. O kernel grava um core dump como parte da "ação padrão" para SIGQUIT, se e somente se o rlimit para core dumps for grande o suficiente; esse rlimit pode ter sido estabelecido por login de acordo com o que diz em limites.conf, ou pode ter sido ajustado manualmente usando ulimit, ou qualquer outra coisa.
Não entendo muito bem "O Bash não possui um manipulador especial para o SIGQUIT".
É correto que todo processo tenha manipuladores de sinal, mesmo que alguns deles sejam padrão, e geralmente um processo adquire seus manipuladores de sinal padrão, dos fork()quais copiará os manipuladores de sinal de seu pai e execve()não alterará os manipuladores de sinal?
Onde um processo bash obtém seus manipuladores/armadilhas de sinal padrão?
No APUE, não consigo descobrir se login(ou gettyalgum outro programa na sequência de inicialização) é o primeiro programa que configura manipuladores de sinal padrão (bem como limites de recursos de /etc/security/limits.conf, que é o centro do tópico no link) e passa até o shell de login:
Se fizermos login corretamente, o login será
• Mude para nosso diretório inicial (chdir)
• Alterar a propriedade do nosso dispositivo terminal (chown) para que ele seja nosso proprietário
• Alterar as permissões de acesso do nosso dispositivo terminal para que tenhamos permissão para ler e escrever nele
• Defina nossos IDs de grupo chamando setgid e initgroups
• Inicialize o ambiente com todas as informações que o login possui: nosso diretório home (HOME), shell (SHELL), nome de usuário (USER e LOGNAME) e um caminho padrão (PATH)
• Mude para nosso ID de usuário (setuid) e invoque nosso shell de login, como em
execl("/bin/sh", "-sh", (char *)0);