Re: PATCH (and another bug report): Re: zsh script and SIGCONT

Re: PATCH (and another bug report): Re: zsh script and SIGCONT

[Sven Wischnowsky]

I wrote:

> Bart Schaefer wrote:
> 
> > ...
> > 
> > So I was about to suggest that we should simply turn off MONITOR during
> > `.' and `source', since it's rather bizarre to have the loop keep going
> > leaving behind a trail of suspended jobs until the job table fills.
> > But then I tried in in bash -- where the lack of NOTIFY means that you
> > don't even find out about the string of suspended jobs until the loop
> > exits -- and now I'm not so sure.
> 
> Interesting, hadn't thought about trying bash.

Just for the record: ksh makes the whole thing unsuspensible and tcsh
uses its usual cunning to suspend the sleep, exit loop and `source'
and leave you with only the suspended sleep as a job.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH (and another bug report): Re: zsh script and SIGCONT

[Bart Schaefer]

On Dec 14, 10:13am, Sven Wischnowsky wrote:
} Subject: Re: PATCH (and another bug report): Re: zsh script and SIGCONT
}
} Bart Schaefer wrote:
} 
} > So I was about to suggest that we should simply turn off MONITOR during
} > `.' and `source' [...]
} 
} [...] Somehow I think it should either suspend the `.' or the loop
} (the top-level construct in the sourced file). The latter if we think
} of the sourced file as an equivalent of command line input.

If it's going to suspend anything, it should be the `.'.  It's NOT
equivalent to command-line input, because zsh doesn't deal with infinite
typeahead.  It's closest to executing a shell function, with no local
parameter context.

However, we certainly don't want startup rc-files to get backgrounded
if one of them happens to do something that gives the user time to press
^Z.  And I can see an argument for wanting to be able to suspend an
individual command without interrupting startup processing entirely.
And it definitely doesn't make any sense to background *that*.

It's a tricky situation.  The only useful criteria seems to me to be
whether the user can reasonably expect to get back to a shell prompt when
he presses ^Z.  If the `.' command is going to violate that expectation,
then at least the doc should say so somewhere.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH (and another bug report): Re: zsh script and SIGCONT

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> So I was about to suggest that we should simply turn off MONITOR during
> `.' and `source', since it's rather bizarre to have the loop keep going
> leaving behind a trail of suspended jobs until the job table fills.
> But then I tried in in bash -- where the lack of NOTIFY means that you
> don't even find out about the string of suspended jobs until the loop
> exits -- and now I'm not so sure.

Interesting, hadn't thought about trying bash.

But still, somehow it feels wrong. Somehow I think it should either
suspend the `.' or the loop (the top-level construct in the sourced
file). The latter if we think of the sourced file as an equivalent of
command line input.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH (and another bug report): Re: zsh script and SIGCONT

[Bart Schaefer]

On Dec 13, 10:25am, Zefram wrote:
} Subject: Re: PATCH (and another bug report): Re: zsh script and SIGCONT
}
} Bart Schaefer wrote:
} >Even worse than this ... if you read the script with ". p2", then ^Z only
} >stops the "sleep 1" and the loop keeps going.  All three cases ought to
} >behave the same as executing the loop at the top-level prompt.
} 
} They can't.  A while loop requested in the current shell *can't* be
} backgrounded after being started, any more than you could background
} a builtin.

Have you tried it lately?

The conclusion we reached was that if you explicitly suspend the loop, you
accept the same consequences as if you backgrounded it in the first place.
(Just as if you interrupted it with ^C.)  This was intended to apply only
to interactive shells (and now it does).

} The loop has to be able to affect shell variables and so
} on, which means it has to execute in the shell process.

That, is probably the reason for this:

On Dec 13, 12:00pm, Sven Wischnowsky wrote:
} 
} In line 725/726 in exec.c we explicitly turn the list_pipe handling
} off if we are sourcing. Removing these two lines makes it work in the
} way you (and I) expect it. However, this is an explicit test and since 
} I don't have any idea why we did that, I won't produce a patch for it
} now.

I can see where one should reasonably assume that a script read with `.'
is specifically intended to modify the state of the current shell, and
therefore should never be forked off once it has started.  (This begs
the question of whether ". script &" is ever reasonable, but we can't
do anything about that.)

So I was about to suggest that we should simply turn off MONITOR during
`.' and `source', since it's rather bizarre to have the loop keep going
leaving behind a trail of suspended jobs until the job table fills.
But then I tried in in bash -- where the lack of NOTIFY means that you
don't even find out about the string of suspended jobs until the loop
exits -- and now I'm not so sure.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH (and another bug report): Re: zsh script and SIGCONT

[Sven Wischnowsky]

Bart Schaefer wrote:

> ...
> 
> Even worse than this ... if you read the script with ". p2", then ^Z only
> stops the "sleep 1" and the loop keeps going.  All three cases ought to
> behave the same as executing the loop at the top-level prompt.
> 
> I spent a while trying to trace through this, but it's nearly impossible
> to use a debugger in combination with tty stop signals, and zsh's job
> control is one of those places where "reading zsh source code makes you
> go blind," as Tom Christiansen has said.

Yes, real fun, isn't it... sigh.

> I believe the script case has something to do with both zsh and sleep
> getting the TSTP (which zsh doesn't have a special handler for); zsh forks
> to background the entire while loop, and therefore the parent shell exits
> from the loop -- but so does the forked child, for reasons that I can't
> follow.
> 
> However, in the case of a script, zsh doesn't need to do any of this; the
> script can start and stop as its own process.

Sounds reasonable.

>  So the following appears
> to fix the script case, but I still don't know what's going on with ".".

In line 725/726 in exec.c we explicitly turn the list_pipe handling
off if we are sourcing. Removing these two lines makes it work in the
way you (and I) expect it. However, this is an explicit test and since 
I don't have any idea why we did that, I won't produce a patch for it
now. Mainly because I don't think I'll have the time today to find out
why we added this test... if anyone has the time to look in the
archive...

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

Re: PATCH (and another bug report): Re: zsh script and SIGCONT

[Zefram]

Bart Schaefer wrote:
>Even worse than this ... if you read the script with ". p2", then ^Z only
>stops the "sleep 1" and the loop keeps going.  All three cases ought to
>behave the same as executing the loop at the top-level prompt.

They can't.  A while loop requested in the current shell *can't* be
backgrounded after being started, any more than you could background
a builtin.  The loop has to be able to affect shell variables and so
on, which means it has to execute in tthe shell process.  Of course,
if it's explicitly backgrounded when started, that's a different matter.

-zefram

PATCH (and another bug report): Re: zsh script and SIGCONT

[Bart Schaefer]

On Dec 12, 11:50am, Danny Dulai wrote:
} Subject: RE: zsh script and SIGCONT
}
} (~) % exec zsh  
} (~) % echo $ZSH_VERSION 
} 3.1.6-pws-11
} (~) % cat p2
} while :; do
}     echo helu;
}     sleep 1
} done
} (~) % zsh p2
} helu
} helu
} 
} zsh: 5896 suspended  zsh p2
} (~) % bg
} [1]  + continued  zsh p2
} (~) % 
} [1]  + 5896 done       zsh p2

Even worse than this ... if you read the script with ". p2", then ^Z only
stops the "sleep 1" and the loop keeps going.  All three cases ought to
behave the same as executing the loop at the top-level prompt.

I spent a while trying to trace through this, but it's nearly impossible
to use a debugger in combination with tty stop signals, and zsh's job
control is one of those places where "reading zsh source code makes you
go blind," as Tom Christiansen has said.

I believe the script case has something to do with both zsh and sleep
getting the TSTP (which zsh doesn't have a special handler for); zsh forks
to background the entire while loop, and therefore the parent shell exits
from the loop -- but so does the forked child, for reasons that I can't
follow.

However, in the case of a script, zsh doesn't need to do any of this; the
script can start and stop as its own process.  So the following appears
to fix the script case, but I still don't know what's going on with ".".

Index: Src/exec.c
===================================================================
@@ -945,7 +945,7 @@
 		    jn->stat & STAT_DONE &&
 		    lastval2 & 0200)
 		    killpg(mypgrp, lastval2 & ~0200);
-		if (!list_pipe_child && !lpforked && !subsh &&
+		if (!list_pipe_child && !lpforked && !subsh && jobbing &&
 		    (list_pipe || last1 || pline_level) &&
 		    ((jn->stat & STAT_STOPPED) ||
 		     (list_pipe_job && pline_level &&

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com