Tinkering a bit more with my prior attempt at a workaround...

Since by default an interactive shell will put a pipeline in a new process group and make that new group the foreground group, if we want to prevent the progress group created by the -c argument to the subshell from taking the foreground, it must be backgrounded. However, without a wait, there will be nothing for the main script to wait on. So, the following may be the best we can do:

Code:

#!/bin/bash

echo COPY START
# sh -ic 'scp large.tar.gz server:/tmp/ & wait' &
sh -ic 'sleep 15 & wait' &
ps -t $(tty) -o pid,ppid,pgid,stat,command
wait
echo COPY END

Test run:

Code:

$ ./robertford.sh
COPY START
[1] 5418
  PID  PPID  PGID STAT COMMAND
 3896   478  3896 Ss   login -pf xxxxx
 3897  3896  3897 S    -bash
 5415  3897  5415 S    /bin/bash ./robertford.sh
 5416  5415  5416 S+   sh -ic sleep 15 & wait
 5418  5416  5418 S    sleep 15
 5420  5415  5415 R    ps -t /dev/ttyp2 -o pid
^C
COPY END

The interactive subshell will execute in a different process group and will become the foreground process group. control-c will be sent to it and any other members of that group. However, the backgrounded pipeline (in this case, sleep 15, ultimately it should be your scp command) is run in another process group which is at last not in the foreground.

Cheers,
Alister

---------- Post updated at 12:39 PM ---------- Previous update was at 11:36 AM ----------

I tested it with the same script I used in my previous post, but it doesn't even create a new process group. I'm assuming that without the -i option, -c renders it a non-interactive shell, despite the -l/--login options (I tried both).

I believe that session creation for interactive use is handled by the login process before it execs the user's shell.

A quick peek at the process list of a few systems, using different default login shells (debian-bash, osx-bash, openbsd-ksh) shows:

debian and osx: -bash login shells are not session leaders (each terminal with a logged in user has a login process associated with it that is the session leader).

openbsd: -ksh login shells are session leaders (there's no login process for those terminals).

Without looking at the source or examining a process trace, one cannot be absolutely certain, but it seems to me that differences in login implementations determine whether or not a user's login shell will be a session leader. The shell's themselves never seem to attempt to become a session leader (in the openbsd case, `ksh -l` will not yield a session leader, which is why I assume it's set up that way by the login process that exec'd it).

Regards,
Alister