coproc does not work in subshell
Machine: x86_64 OS: linux-gnu Compiler: gcc Compilation CFLAGS: -g -O2 -fdebug-prefix-map=/build/bash-a6qmCk/bash-5.0=. -fstack-protector-strong -Wformat -Werror=format-security -Wall -Wno-parentheses -Wno-format-security uname output: Linux EliteBook 5.4.0-42-generic #46-Ubuntu SMP Fri Jul 10 00:24:02 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux Machine Type: x86_64-pc-linux-gnu Bash Version: 5.0 Patch Level: 17 Release Status: release bash$ coproc while read -r line; do eval expr "$line"; done [1] 172053 bash$ echo "1 + 2" >& ${COPROC[1]}; read -r <& ${COPROC[0]}; echo $REPLY # OK 3 bash$ echo $( echo "1 + 3" >& ${COPROC[1]}; read -r <& ${COPROC[0]}; echo $REPLY ) # command substitution : OK 4 bash$ cat <( echo "1 + 4" >& ${COPROC[1]}; read -r <& ${COPROC[0]}; echo $REPLY ) # process substitution : OK 5 bash$ ( echo "1 + 5" >& ${COPROC[1]}; read -r <& ${COPROC[0]}; echo $REPLY ) # ERROR : subshell does not work bash: ${COPROC[1]}: Bad file descriptor bash: ${COPROC[0]}: Bad file descriptor 3
Re: coproc does not work in subshell
On 10/2/20 7:59 AM, Hyunho Cho wrote: > bash$ ( echo "1 + 5" >& ${COPROC[1]}; read -r <& ${COPROC[0]}; echo > $REPLY ) # ERROR : subshell does not work > bash: ${COPROC[1]}: Bad file descriptor > bash: ${COPROC[0]}: Bad file descriptor > 3 Yes, this is correct. Subshells close coproc file descriptors they inherit. This is to prevent deadlock and processes not terminating because there are still open file descriptors to child processes. If you want to manage the file descriptors yourself, you can dup the coproc file descriptors and make sure they're closed appropriately for your needs. -- ``The lyf so short, the craft so long to lerne.'' - Chaucer ``Ars longa, vita brevis'' - Hippocrates Chet Ramey, UTech, CWRUc...@case.eduhttp://tiswww.cwru.edu/~chet/
Re: execve E2BIG (Argument list too long)
On September 30, 2020 8:44:40 AM Andreas Schwab wrote: On Sep 30 2020, Daniel Colascione wrote: It might be worth asking lkml to lift this restriction You will have bad luck with that. The limit has been introduced for security reasons. What "security reasons"? You'd still be subject to the stack ulimit, which you can set to whatever you want.