Problems with I/O redirection via exec

Shell Programming and Scripting
1

Hello,
I am running a shell script on AIX 6.1. The script calls ksh to run. ksh is also the login shell for the account under which I am running this script, but for convenience I always change to the bash shell via "exec bash" after I "su" to the account.

The script redirects stdout and stderr to a file via exec, then builds a report via a bunch of "echo" and "awk" commands, and then finally reconnects to stdout and stderr and emails the report:

#!/usr/bin/ksh
#set -x
   .   .   .   .
STAMP=`date "+%H%M%S"`.$$               # Unique suffix for tmp files.
RPTF=/tmp/arch_cmp_rpt.$STAMP           # Seq chk report file.
   .   .   .   .
exec 2>&1 > $RPTF                       # Capture std output and stderr.
   .   .   .   .
exec                                    # Restore stdout/stderr.
cat $RPTF | /usr/sbin/sendmail recip@myemployer.com
                                        # Pipe report to sendmail.
rm $RPTF                                # Clean up.

I run into difficulties when I try to run this script (archcmp.sh) in the background via "./archcmp.sh &" . I can do so, and the script does run, but as soon as I type anything at the terminal (like an 'ls -l' on the report file in /tmp) the script stops and I cannot resume it. I see the same behavior whether or not I switch from the ksh login shell to bash before running the report:

$ ./archcmp.sh &
[1] 12189786
ls -l /tmp/arch_cmp_rpt.115918.12189786 
-rw-rw----    1 eprprde  profile         700 Jul 21 11:59 /tmp/arch_cmp_rpt.115918.12189786
[1]+  Stopped                 ./archcmp.sh
$ bg
[1]+ ./archcmp.sh &
ls -l /tmp/arch_cmp_rpt.115918.12189786 
-rw-rw----    1 eprprde  profile         700 Jul 21 11:59 /tmp/arch_cmp_rpt.115918.12189786
$ date
Tue Jul 21 12:00:43 EDT 2015
$ date
Tue Jul 21 12:05:46 EDT 2015
$ ls -l /tmp/arch_cmp_rpt.115918.12189786 
-rw-rw----    1 eprprde  profile         700 Jul 21 11:59 /tmp/arch_cmp_rpt.115918.12189786
$

It will never write anything more to the report file.

I find that I can get my program to behave the way that it should (or, at least, the way that I would like it to) if I change I redirecting 'exec' command to redirect all three of the standard file handles, as follows:

exec 2>&1 >$RPTF </dev/null

But this should be unnecessary, shouldn't it? When I place a command into the background via '<commandname> &' , it should be unconditionally dissociated from the terminal. Is this a bug in ksh? Is there some other way to get the background process to actually resume?

These are the OS & shell versions:

$ uname -a
AIX servername 1 6 00C7252F4C00
$ 
$ set -o vi
$ Version M-11/16/88f
$ bash --version 
GNU bash, version 3.2.16(1)-release (powerpc-ibm-aix5.2.0.0)
Copyright (C) 2005 Free Software Foundation, Inc.
$

Thanks for any explanation you can provide.

2

& doesn't mean "unconditionally dissociated from the terminal" -- anything but, really. Once it's in the background, attempting to do I/O on the std channels will suspend it. This is expected behavior.

3

Please be aware that

exec 2>&1 > $RPTF                       # Capture std output and stderr

does NOT capture std output and stderr. It duplicates stderr from (the old) stdout , and then redirects stdout to $RPTF. So stderr still points to (presumably) /dev/tty (or so) and eventually prints to it.
and that

exec                                    # Restore stdout/stderr.

does NOT restore stdout/stderr. Actually, it doesn't do anything.

4

You're right, I keep writing that backwards,

5

Steps are processed from left to right:

1st make redirect for stdout and 2nd redirect stderr (handler 2) to same as stdout (handler 1)

# ususally needed
  > redirect.stdout  2>&1

This works also but result is little surprise. Not planned.
1st set stderr same as stdout is now and 2nd redirect stdout. = stderr is same as stdout was before new setup.

# not so often needed
  2>&1 > redirect.stdout