0

If run over ssh, a script with a trap statement with interrupt signal names (SIGINT, etc) gives an error and the trap does not work when an interrupt (eg. Ctrl+C) is sent. Eg: 

#!/bin/bash

trap 'echo "Exit signal detected..."' SIGINT

# display something
echo "This is a test"

sleep 100000

When this is run over ssh, it prints an error

trap: SIGINT: bad trap

and trap's command is never executed.

The problem is over ssh only; if run locally it works.

However, if the interrupt signal number (2) is used instead the name (SIGINT), it works including over ssh.

I thought it's preferable to use signal names and not signal numbers.

EDIT: Local system is running Fedora 28, and remote system is on Ubuntu 18.04.

adatum
  • 1,111
  • 3
  • 13
  • 27
  • Is the system you're SSHing to a different operating system to what you use local? This might explain the different behaviours. – mhutter Sep 12 '18 at 00:31
  • @mhutter They are different: local = Fedora 28, remote = Ubuntu 18.04. Is ssh not standard? – adatum Sep 12 '18 at 00:46
  • @Goro Do you mean `trap '' SIGINT; ssh [remote IP]` ? I tried this and the behavior was the same. – adatum Sep 12 '18 at 01:05
  • 1
    @JosephSible Just using `INT` without the `SIG` part works! Still confused about the cause, since the solution you linked to mentions different shells might behave differently, but in this case both local and remote use bash. – adatum Sep 12 '18 at 01:39
  • @adatum are you positive that your remote shell is bash? Or is it “/bin/sh”, which invokes posix mode.... – Jeff Schaller Sep 12 '18 at 01:45
  • https://www.gnu.org/software/bash/manual/html_node/Bash-POSIX-Mode.html#Bash-POSIX-Mode – Jeff Schaller Sep 12 '18 at 01:46
  • @JeffSchaller The remote is Ubuntu 18.04 and `echo $SHELL` gives `/bin/bash`. Is there something else I can check? – adatum Sep 12 '18 at 01:50

0 Answers0