Return to Question

I am using a following version of the bash:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

When I start some command (e.g. ./hiprogram) directly from the terminal, then bash forks itself, exec the command, and at the same time it places a new process in a new group that becomes the foreground, while moving its group to the background.

However, when I create a script that runs ./hiprogram, then bash (that executes script) forks/exec itself in the same way but now bash stays in the same group as the command and thus stays in foreground group, why?

The only reason I can see for this is that the bash executing the script must be able to receive signals intended for the foreground group, such as CTRL+C, and react in the right way (for CTRL+C, that would mean to stop further execution of the script). Is that the only reason? AIs say that bash executing the script also remains in the foreground group to manage job control, but that explanation doesn’t quite make sense to me—after all, job control works just fine in first case when commands are executed directly from the terminal and bash is not part of the foreground group.

I am using the following version of the bash:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

When I start some command (e.g. ./hiprogram) directly from the terminal, then bash forks itself, execs the command, and at the same time it places a new process in a new group that becomes the foreground, while moving its group to the background.

However, when I create a script that runs ./hiprogram, then bash (that executes script) forks/execs itself in the same way but now bash stays in the same group as the command and thus stays in foreground group, why?

The only reason I can see for this is that the bash instance executing the script must be able to receive signals intended for the foreground group, such as CTRL+C, and react in the right way (for CTRL+C, that would mean to stop further execution of the script). Is that the only reason? AIs say that bash executing the script also remains in the foreground group to manage job control, but that explanation doesn’t quite make sense to me—after all, job control works just fine in the first case when commands are executed directly from the terminal and bash is not part of the foreground group.

I am using a following version of the bash:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

When I start some command (e.g. ./hiprogram) directly from the terminal, then bash forks itself, exec the command, and at the same time it places a new process in a new group that becomes the foreground, while moving its group to the background.

However, when I create a script that runs ./hiprogram, then bash (that executes script) forks/exec itself in the same way but now bash stays in the same group as the command and thus stays in foreground group, why?

The only reason I can think of is that Bash needs to handle signals, such as CTRL+C, which would interrupt the script's execution. Is that the only reason? AIs say that Bash also remains in the foreground group to manage job control, but that explanation doesn’t quite make sense to me—after all, job control works just fine when commands are executed directly from the terminal.

I am using a following version of the bash:

GNU bash, version 5.1.16(1)-release (x86_64-pc-linux-gnu)

When I start some command (e.g. ./hiprogram) directly from the terminal, then bash forks itself, exec the command, and at the same time it places a new process in a new group that becomes the foreground, while moving its group to the background.

However, when I create a script that runs ./hiprogram, then bash (that executes script) forks/exec itself in the same way but now bash stays in the same group as the command and thus stays in foreground group, why?

The only reason I can see for this is that the bash executing the script must be able to receive signals intended for the foreground group, such as CTRL+C, and react in the right way (for CTRL+C, that would mean to stop further execution of the script). Is that the only reason? AIs say that bash executing the script also remains in the foreground group to manage job control, but that explanation doesn’t quite make sense to me—after all, job control works just fine in first case when commands are executed directly from the terminal and bash is not part of the foreground group.