Bug? Output not flushed?

Bug? Output not flushed?

[Bart Schaefer]

Easily reproduced:

% { print XXX; return 0; } >| /tmp/newfile; print $(</tmp/newfile)
% print $(</tmp/newfile)
XXX

That is, when a return statement appears in a current-shell complex
list, the output is not flushed until the parser reaches the top level
again.  If the return statement is removed, all is well:

% { print YYY; } >| /tmp/newfile; print $(</tmp/newfile)
YYY
%

Any idea where to start looking for this?

Re: Bug? Output not flushed?

[Mikael Magnusson]

On 9/15/23, Bart Schaefer <schaefer@brasslantern.com> wrote:
> Easily reproduced:
>
> % { print XXX; return 0; } >| /tmp/newfile; print $(</tmp/newfile)
> % print $(</tmp/newfile)
> XXX
>
> That is, when a return statement appears in a current-shell complex
> list, the output is not flushed until the parser reaches the top level
> again.

I'm not sure if that diagnosis is correct, look at this:
% { print XXX; return 0; } >| /tmp/newfile; echo hello; print $(</tmp/newfile)

and if you put a sleep 10 in there, it still completes immediately,
ie, does the return just return from the whole statement? Isn't that
actually expected since it's not in a function or subshell?

>  If the return statement is removed, all is well:
>
> % { print YYY; } >| /tmp/newfile; print $(</tmp/newfile)
> YYY
> %
>
> Any idea where to start looking for this?

-- 
Mikael Magnusson

Re: Bug? Output not flushed?

[Bart Schaefer]

On Fri, Sep 15, 2023 at 10:05 AM Mikael Magnusson <mikachu@gmail.com> wrote:
>
> I'm not sure if that diagnosis is correct, look at this:
> % { print XXX; return 0; } >| /tmp/newfile; echo hello; print $(</tmp/newfile)
>
> ie, does the return just return from the whole statement?

Hrm.  I was trying to come up with an example that DID NOT depend on
my ${ ... } nofork patch, but the semantics of return seem to make
that impossible.

If you have my full set of nofork patches installed:

% set -vx
% print IN ${ print NOFORK; return 0; } OUT
>| /tmp/zshw44kFq { print NOFORK; return 0;  ;}
+Src/zsh:3> print NOFORK
+Src/zsh:3> return 0
REPLY="$(</tmp/zshw44kFq)"
+Src/zsh:3> print IN OUT
IN OUT

The redirection has happened, the print has happened, and the
assignment to REPLY has happened, but the file was empty when read.
Unless something is actually aborting the $(...) ... will have to dig
further.

Thanks for the observation.

[PATCH] ? Parse error does not always set $? (Was: Bug? Output not flushed?)

[Bart Schaefer]

On Fri, Sep 15, 2023 at 10:30 AM Bart Schaefer
<schaefer@brasslantern.com> wrote:
>
> Unless something is actually aborting the $(...)

Ah, part of the problem is upstream.

Is there any reason parse_string() should be discarding errflag?  All
tests still pass with this change:

diff --git a/Src/exec.c b/Src/exec.c
index 3a8b3e951..f6902fd39 100644
--- a/Src/exec.c
+++ b/Src/exec.c
@@ -286,6 +286,7 @@ parse_string(char *s, int reset_lineno)
 {
     Eprog p;
     zlong oldlineno;
+    int xerrflag;

     zcontext_save();
     inpush(s, INP_LINENO, NULL);
@@ -299,7 +300,9 @@ parse_string(char *s, int reset_lineno)
     lastval = 1;
     strinend();
     inpop();
+    xerrflag = errflag;
     zcontext_restore();
+    errflag = xerrflag;
     return p;
 }

That's not the only thing that was needed for the original nofork
problem, but the rest isn't relevant here.

Re: [PATCH] ? Parse error does not always set $? (Was: Bug? Output not flushed?)

[Bart Schaefer]

On Fri, Sep 15, 2023 at 3:22 PM Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> Is there any reason parse_string() should be discarding errflag?

There seem to be a couple of things that might be affected by this,
although the only one I can readily reproduce is with "trap":

Before:
zsh:1: parse error near `}'
zsh:trap:1: couldn't parse trap command

After:
zsh:1: parse error near `}'

Probably better to go at it a different way.  Ignore workers/52149.