Re: I/O to shell function in zsh coproc

Re: I/O to shell function in zsh coproc

[Peter Stephenson]

On Sat, 05 Feb 2011 10:08:16 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> You're right, there is a bug there.  I'm not immediately sure where to
> fix it, but there's a workaround.
> 
> The bug is that when you do 'coproc shellfunction', zsh has to fork a
> subshell to run the shellfunction in another process.  The trouble is
> that the subshell therefore gets copies of the coprocess descriptors
> that are open in the parent shell.

(More dirty washing also moved to zsh-workers.)

It's not as simple as setting FD_CLOEXEC for coproc descriptors, then?

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/

Re: I/O to shell function in zsh coproc

[Bart Schaefer]

On Feb 6,  7:00pm, Peter Stephenson wrote:
} Subject: Re: I/O to shell function in zsh coproc
}
} On Sat, 05 Feb 2011 10:08:16 -0800
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > The bug is that when you do 'coproc shellfunction', zsh has to fork a
} > subshell to run the shellfunction in another process.  The trouble is
} > that the subshell therefore gets copies of the coprocess descriptors
} > that are open in the parent shell.
} 
} It's not as simple as setting FD_CLOEXEC for coproc descriptors, then?

No, because the subshell never performs an exec().  This all happens only
when a shell construct is involved -- if, case, loops, functions, etc.

The right thing almost happens if I modify entersubsh() to close coprocin
and coprocout when ESUB_ASYNC is set:

schaefer<501> coproc while read line; do print -r -- "$line:u"; done
[1] 27394
schaefer<502> print -p foo
schaefer<503> read -ep
FOO
schaefer<504> coproc exit
[2] 27395
[1]  - done       while read line; do; print -r -- "$line:u"; done
[2]  + done       exit

So far, so good, but:

schaefer<505> coproc while read line; do print -r -- "$line:u"; done
[1] 27396
schaefer<506> ( print -p foo )
schaefer<507> read -ep
FOO
schaefer<508> ( print -p foo ) &
print: -p: no coprocess
[2] 27398
[2]  + exit 1     ( print -p foo; )

Oops, that last should not fail; entersubsh() [or execpline2() if we
want to handle it one step higher up the call stack] needs to know
exactly when the job that it's forking *is* the coprocess job, not
just that it's an asynchronous shell job.

Currently that appears to mean adding both another Z_* flag alongside
Z_ASYNC et al., and a corresponding ESUB_* flag -- I tried but failed
to figure out a way to use only the latter.  Maybe there's some other
clue that I'm missing, here.

Re: I/O to shell function in zsh coproc

[Peter Stephenson]

Slightly tangential, but I did notice this chunk appears to be wrong.

The value of coprocin and coprocout when they're not in use is -1, not
0, which is of course a valid file descriptor.  So unless there actually
is a coprocess we're always attempting to close file -1.  In my opinion
this isn't very useful.

Index: Src/exec.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/exec.c,v
retrieving revision 1.187
diff -p -u -r1.187 exec.c
--- Src/exec.c	16 Dec 2010 13:55:36 -0000	1.187
+++ Src/exec.c	15 Feb 2011 18:53:28 -0000
@@ -3218,10 +3218,14 @@ execcmd(Estate state, int input, int out
 			_exit(1);
 		}
 		closem(FDT_INTERNAL);
-		if (coprocin)
+		if (coprocin != -1) {
 		    zclose(coprocin);
-		if (coprocout)
+		    coprocin = -1;
+		}
+		if (coprocout != -1) {
 		    zclose(coprocout);
+		    coprocout = -1;
+		}
 #ifdef HAVE_GETRLIMIT
 		if (!forked)
 		    setlimits(NULL);

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/