coproc does not work in subshell

2020-10-02 Thread Hyunho Cho 
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

2020-10-02 Thread Chet Ramey 
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)

2020-10-02 Thread Daniel Colascione 




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.