File descriptors problem perplexing me

Greetings,

I have a troubling problem with a Korn Shell concept that I know works in Solaris.

Essentially I am assigning file descriptors to a coprocess. Also, it should be noted that I am not using the public domain ksh but, rather AT&T ksh93.

Here is a test scenario:

$ sqlplus -s /nolog |& <== Coprocess
[1] 8566
$ print -p "prompt Hello"
$ read -p line
$ print $line
Hello <== proof that the async communication works

$ exec 5>&p <== assign fd 5 to stdout and fd 6 to stdin
$ exec 6<&p
$ print -u5 "prompt Hello again" <== This works in Solaris but not in Linux
ksh: print: bad file unit number <== I don't know why this is occurring
[1] + Done sqlplus -s /nolog |& <== coprocess dies
$ read -u6 line
$ print $line

$ ulimit -a
address space limit (kbytes) (-M) unlimited
core file size (blocks) (-c) 0
cpu time (seconds) (-t) unlimited
data size (kbytes) (-d) unlimited
file size (blocks) (-f) unlimited
locks (-L) unlimited
locked address space (kbytes) (-l) 32
nofile (-n) 65536 <== Should be enough fds available
nproc (-u) 16384
pipe buffer size (bytes) (-p) 4096
resident set size (kbytes) (-m) unlimited
socket buffer size (bytes) (-b) 4096
stack size (kbytes) (-s) 10240
threads (-T) not supported
process size (kbytes) (-v) unlimited

Any ideas why I can't do this in Linux?

Regards,

Thomas

What you're doing looks good to me. I would suspect a bug your linux version of ksh.

I downloaded and manually installed the latest binary version of KSH from AT&T Research Labs. I thought about downloading and compiling the source. I'll give that a try as soon as I can. I was really hoping that someone had experienced something similar and knew the magic kernel parameter. Thanks for the comments.

Thomas

And if that doesn't work try pdksh - I'm running v5.2.14 99/07/13.2 and the example you posted works fine for me.

Cheers
ZB

I already confirmed prior to posting that pdksh does work fine as you have indicated (even on a PC running CYGWIN). The problem that I encountered with pdksh has to do with variable scope as follows:

$ set -A RESULTS_ARRAY "Initial Value" 0 0 0 0
...
$ {
... some command producing output...
} | while read LINE
> do
> ...
> RESULTS_ARRAY[0]="Some new text"
> RESULTS_ARRAY[1]=1
> ...
> done

$ print ${RESULTS_ARRAY[0]}
Initial Value

The variable's scope appears to be limited to within the while loop. This is probably basic but I could not determine the answer at 2 AM when I was struggling over it. This is when I discovered that I had been using pdksh rather than AT&T's. AT&T's corrected this and I quit persuing it. What technique do I use to broaden the variable's scope? I tried to export the variable with the same results.

Thomas

At least I found why pdksh behaves they way I described. When piping through "while read" loop, everything inside the loop is executed in a subshell. This why my variables were not taking hold.

It may be easier to alter my code to avoide "while read" loops and go back to pdksh than to figure out my file descriptor problem.

Thomas