How to know from a bash script if the user abruptly closes ssh session

Question

I have a bash script that acts as the default shell for a user loging in trough ssh. It provides a menu with several options one of wich is sending a file using netcat.

The netcat of the embedded linux I'm using lacks the -w option, so if the user closes the ssh connection without ever sending the file, the netcat command waits forever.

I need to know if the user abruptly closes the connection so the script can kill the netcat command and exit gracefully.

Things I've tried so far:

• Trapping the SIGHUP: it is not issued. The only signal issued i could find is SIGCONT, but I don't think it's reliable and portable.
• Playing with the -t option of the read command to detect a closed stdin: this would work if not for a silly bug in the embedded read command (only times out on the first invocation)

---

Edit:

I'll try to answer the questions in the comments and explain the situation further.

The code I have is:

nc -l -p 7576 > /dev/null 2>> $LOGFILE < $TMP_DIR/$BACKUP_FILE &
wait

I'm ignoring SIGINT and SIGTSTP, but I've tried to trap all the signals and the only one received is SIGCONT.

Reading the bash man page I've found out that the SIGHUP should be sent to both script and netcat and that the SIGCONT is sent to stopped jobs to ensure they receive the SIGHUP.

I guess the wait makes the script count as stopped and so it receives the SIGCONT but at the same time the wait somehow eats up the SIGHUP.

So I've tried changing the wait for a sleep and then both SIGHUP and SIGCONT are received.

The question is: why is the wait blocking the SIGHUP?

---

Edit 2: Solved

I solved it polling for a closed stdin with the read builtin using the -t option. To work around the bug in the read builtin I spawn it in a new bash (bash -c "read -t 3 dummy").

Answer 1

Does the Parent PiD change? If so you could look up the parent in the process list and make sure the process name is correct.

Answer 2

I have written similar applications. It would be helpful to have more of the code in your shell. I think there may be a way of writing your overall program differently which would address this issue.