How to immediately trap a signal to an interactive Bash shell?

Question

I try to send a signal from one terminal A to another terminal B. Both run an interactive shell.

In terminal B, I trap signal SIGUSR1 like so :

$ trap 'source ~/mycommand' SIGUSR1

Now in terminal A I send a signal like so :

$ kill -SIGUSR1 pidOfB

Unfortunately, nothing happens in B. If I want to have my command executed, I need to switch to B and either input a new command or press enter.

How can I avoid this drawback and immediately execute my command instead ?

EDIT :

It's important to note that I want to interact directly with the interactive shell in terminal B from terminal A. For this reason, every solution where the trap command would be executed in a subshell would not work for me...

Also, terminal B must stay interactive.

Answer 1

The shell may simply be stuck in a blocking read, waiting for command-line input. Hitting enter causes the handler to execute before the entered command. Running a non-blocking command like wait:

$ sleep 60 & wait

then sending the signal causes wait to terminate immediately, followed by the output of the handler.

Answer 2

I use a similar trap so that periodically I can (from a separate cron job) force all idle bash processes to do a 'history -a'. I found that if I trap SIGALRM instead of SIGUSR1, then the bash blocking read seems not to be a problem: the trap runs now, rather than next time one hits return. I tried SIGINT, but that caused an annoying "^C", followed by a new prompt line, to be displayed. I haven't yet found any drawbacks of using SIGALRM, but perhaps they will arise.

Answer 3

It may be buffering.

As a test, try installing a loop trigger. In window A:

{ trap 'ls' USR1; while sleep 1; do echo>/dev/null;done } &
[1] 7316

in window B:

 kill -usr1 7316

back in window A the ls is firing when the loop does an echo. Don't know if that will help, but it's something.