Re: Why does sh in the build environment ignore SIGINT and SIGQUIT?

[Foo Chuan Wei <chuanwei.foo@hotmail.com>]

On 2022-05-22 14:14 +0000, Ryan Prior wrote:
> ------- Original Message -------
> On Sunday, May 22nd, 2022 at 8:00 AM, Foo Chuan Wei <chuanwei.foo@hotmail.com> wrote:
>
> > The shell in the environment where packages are built ignores SIGINT
> > and SIGQUIT. If I add `(invoke "sh" "-c" "trap")` to a custom build
> > phase
>
> That executes a shell which traps and then immediately exits. By the
> next step of the build phase execution it's already gone. The shell
> isn't ignoring you - it's not running at all.

`(invoke "sh" "-c" "trap")` is merely a trivial example for
demonstrating that the shell ignores SIGINT and SIGQUIT. This might be
significant if the build step invokes the shell to do something more
significant (e.g. to build something).

Anyway, I found that this behavior is possibly related to one specified
by POSIX [1]:

> 2.11. Signals and Error Handling
>
> If job control is disabled (see the description of set -m) when the
> shell executes an asynchronous list, the commands in the list shall
> inherit from the shell a signal action of ignored (SIG_IGN) for the
> SIGINT and SIGQUIT signals.

To reproduce:
Method 1:
$ set +m
$ bash -c 'trap' &

Method 2:
$ bash -c 'bash -c "trap" &'

Output:
trap -- '' SIGINT
trap -- '' SIGQUIT

Method 2 probably shows what is happening in Guix.

> Sounds extremely cursed.
:D
Do you have a solution to this problem?


  [1]: https://pubs.opengroup.org/onlinepubs/9699919799/utilities/V3_chap02.html