On 10 April 2012 01:13, Lionel Cons <[email protected]> wrote: > Hello, I found another bug with read -d and ksh93: If read -d in a > ksh93 shell reads from a <() pipe I can't interrupt it with ^C: > > Testcase: > Read a string from <() pipe and print it. If the shell hangs hitting > the ^C interrupt will end the shell and return a prompt of the parent > shell: > > zsh returns the expected behaviour: >> zsh -c 'read -d "3" r <(printf "x123€hello\n") ; printf "|%s|\n" "$r"' > ^C >> > > zsh returns the expected behaviour: >> bash -c 'read -d "3" r <(printf "x123€hello\n") ; printf "|%s|\n" "$r"' > ^C >> > > ksh fails the test, it hangs even after repeated use of ^C and had to > be killed from a 2nd xterm: >> /usr/bin/ksh -c 'read -d "3" r <(printf "x123€hello\n") ; printf "|%s|\n" >> "$r"' > ^C^C^C^C^Z^C^C^C^C^C^CTerminated
The hang is not a bug. 'read -d "3" r <(printf "x123€hello\n") ; printf "|%s|\n" "$r"' will have it's <(printf "x123€hello\n") statement replaced by a /dev/fd/N where /dev/fd/N links the parent process running read with the child process running the printf. What you likely wanted is this: ksh -x -c 'read -d "3" r < <(printf "x123€hello\n") ; printf "|%s|\n" "$r"' + read -d 3 r + 0< /dev/fd/3 + printf 'x123€hello\n' + printf '|%s|\n' x12 |x12| IMO that read does not respond to a ^C (interrupt) when waiting for stdin (as your erroneously first example does) is a bug _______________________________________________ ast-users mailing list [email protected] https://mailman.research.att.com/mailman/listinfo/ast-users
