I kicked up a couple bugs while testing the variations on the way
"read -p" is now handled. In the following example I start by testing
"read -p" for generating a prompt -- a rather poor prompt, but it's a
lead-up to what I'm showing later. There are no problems with "read -p"
in prompt mode. Next, I start a co-process and do several successful
variations on printing to the co-process. But, there are problems when I
try to read back what was printed. As the comments in the example
describe "read x <&p" and "read -px" (no space between the p and x) have
problems.
$ read -p x
x1
$ print $REPLY
1
$ read -px
x2
$ print $REPLY
2
$ while read -r line
> do
> [[ "$line" == [Qq] ]] && break
> print -r -- "$line" >> /tmp/test
> print -r "read: $line"
> done |&
[1] 40391
$ print -up 'Testing'
$ print 1 >&p
$ print -p 2
$ print -p 3
$ read -up x
$ print $x
read: Testing
#
# The next read hangs. Control-C returns the shell prompt. The
# co-process pipe is not read ($x still has the value of the previous
# read). <&p works in ksh-20120612, but not in ksh-20140929.
#
$ read x <&p
^C$ print $x
read: Testing
$ read -p x
$ print $x
read: 1
$ #
$ # The next read hangs hard. The system load jumps. After a long pause
$ # (> 1 minute) the error message appears followed by the bus error.
$ # Debugging with gdb reveals that the optget() loop in b_read() is
$ # being called repeatedly to case 'p' (line 230 in
$ # src/cmd/ksh93/bltins/read.c) because of the argv-- at line 237. The
$ # behavior with ksh-20120612 was to declare x an invalid option
$ # without hanging and without dieing with a bus error.
$ #
$ read -px
^C
^\
^Z
ksh: read: -px: invalid variable name
Bus error
I also did some digging with gdb for the "read x <&p" problem. I set
a breakpoint at line 337 in src/cmd/kdh93/bltins/read.c, which looks
like this:
r=sh_readline(shp,argv,readfn,fd,flags,len,timeout);
Then, I ran the shell, created the co-process as in the example above,
did the same prints to the co-process and ran "read -up x". At the
breakpoint the variable, fd, was 5, the same as shp->cpipe[0]. Then, I
continued and ran "read x <&p". This time the variable, fd, was 0
(zero), while shp->cpipe[0] was, of course, still 5. So, the problem
here appears to be that <&p is associated with stdin instead of the
co-process pipe. After I continued the read hung as before. I typed
control-C and did a where in gdb. I attached the output of the where
command in read_hang_where.txt.
Terrence Doyle
#0 0x920303a8 in poll$UNIX2003 ()
#1 0x001d8c00 in sfpkrd (fd=0, argbuf=0x176e080, n=32768, rc=10, tm=-1,
action=-1) at /Source/AST/2014-09-29/src/lib/libast/sfio/sfpkrd.c:142
#2 0x0004678c in ed_read (context=0x1735fc0, fd=0, buff=0x176e080 "",
size=32768, reedit=0) at /Source/AST/2014-09-29/src/cmd/ksh93/edit/edit.c:890
#3 0x00064a50 in piperead (iop=0x269f20, buff=0x176e080, size=32768,
handle=0x174cb90) at /Source/AST/2014-09-29/src/cmd/ksh93/sh/io.c:2084
#4 0x001de088 in sfrd (f=0x269f20, buf=0x176e080, n=32768, disc=0x174cb90) at
/Source/AST/2014-09-29/src/lib/libast/sfio/sfrd.c:259
#5 0x001d3548 in _sffilbuf (f=0x269f20, n=-1) at
/Source/AST/2014-09-29/src/lib/libast/sfio/sffilbuf.c:105
#6 0x001d449c in sfgetr (f=0x269f20, rc=10, type=0) at
/Source/AST/2014-09-29/src/lib/libast/sfio/sfgetr.c:81
#7 0x00012f38 in sh_readline (shp=0x266124, names=0x174aca0, readfn=0x0, fd=0,
flags=0, size=0, timeout=0) at
/Source/AST/2014-09-29/src/cmd/ksh93/bltins/read.c:667
#8 0x000119c8 in b_read (argc=2, argv#8 0x000119c8 in b_read (argc=2, argv#8
0x000119c8 in b_read (argc=2, argv#8ea#8 0x000119c8 in b_read (argc=2, argv#8
0x000119c8 in b_read (argc=2,
argv#8rce/AST/2014-09-29/src/cmd/ksh93/sh/xec.c:1387
#10 0x00022e94 in exfile (shp=0x266124, iop=0x269f20, fno=0) at
/Source/AST/2014-09-29/src/cmd/ksh93/sh/main.c:610
#11 0x00022130 in sh_main (ac=2, av=0xbfffede4, userinit=0) at
/Source/AST/2014-09-29/src/cmd/ksh93/sh/main.c:382
#12 0x00001928 in main (argc=2, argv=0xbfffede4) at
/Source/AST/2014-09-29/src/cmd/ksh93/sh/pmain.c:45
_______________________________________________
ast-developers mailing list
ast-developers@lists.research.att.com
http://lists.research.att.com/mailman/listinfo/ast-developers
