zsh-workers
 help / color / Atom feed
* Test release: 5.6.2-test-3
@ 2019-01-05  7:08 dana
  2019-01-05 17:49 ` Peter Stephenson
                   ` (4 more replies)
  0 siblings, 5 replies; 39+ messages in thread
From: dana @ 2019-01-05  7:08 UTC (permalink / raw)
  To: Zsh workers

I've tagged 5.6.2-test-3 and uploaded the artefacts to:

https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3

Hope i did this right. If someone could please glance at it to make sure that
would be nice. Thanks Daniel and Peter for helping me.

PS: Building the docs on macOS is an insane ordeal. After messing with it for
almost an hour i finally got to the point where i had to install X11 to
generate the PDF and decided it just wasn't worth it. I ended up building on
an old Linux lap-top. If anyone's done this on macOS before and knows a trick
to it that doesn't require a million weird dependencies, please let me know

PPS: Notes/docs on zsh.org were never updated for 5.6.x. I haven't done that
now, but i'll look into it later

dana


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-05  7:08 Test release: 5.6.2-test-3 dana
@ 2019-01-05 17:49 ` Peter Stephenson
  2019-01-05 18:42   ` dana
  2019-01-05 20:58   ` Martijn Dekker
  2019-01-06  2:37 ` Axel Beckert
                   ` (3 subsequent siblings)
  4 siblings, 2 replies; 39+ messages in thread
From: Peter Stephenson @ 2019-01-05 17:49 UTC (permalink / raw)
  To: Zsh workers

On Sat, 2019-01-05 at 01:08 -0600, dana wrote:
> I've tagged 5.6.2-test-3 and uploaded the artefacts to:
> 
> https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3
> 
> Hope i did this right. If someone could please glance at it to make sure that
> would be nice. Thanks Daniel and Peter for helping me.

Looks pretty much OK, thanks.

One thing, now I've been forced to do a proper comparison for once, is
that it looks like the Doc/help directory you've supplied isn't up to
date --- at least it's different from what I get and what I've got shows
signs of recent additions.  Tru removing Doc/help.txt and making in that
directory again.  I dare say the dependencies for that aren't complete.
(I'd love to be able to move to rake and have all this dynamic but that
isn't going to happen.)

By the way, in case anyone's infuriated by trying to automate downloads
from Sourceforge, it *does* work with wget (I've got 1.19.4 from Ubuntu
18.04 as I've finally joined the modern world and bought a laptop with
Ubuntu pre-installed):

wget https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3/zsh-5.6.2-test-3.tar.xz/download

except that the file you get is called "download", but a bit of
scripting will fix that.

pws


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-05 17:49 ` Peter Stephenson
@ 2019-01-05 18:42   ` dana
  2019-01-05 20:58   ` Martijn Dekker
  1 sibling, 0 replies; 39+ messages in thread
From: dana @ 2019-01-05 18:42 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: Zsh workers

On 5 Jan 2019, at 11:49, Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
>One thing, now I've been forced to do a proper comparison for once, is
>that it looks like the Doc/help directory you've supplied isn't up to
>date --- at least it's different from what I get and what I've got shows
>signs of recent additions.  Tru removing Doc/help.txt and making in that
>directory again.  I dare say the dependencies for that aren't complete.

Hmm, no idea what i did wrong, it was a fresh clone so there shouldn't have
been any junk in the repo. But i did it again and now it looks right, so....
Sorry about that. I'll double-check it the next time i do one of these.

dana


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-05 17:49 ` Peter Stephenson
  2019-01-05 18:42   ` dana
@ 2019-01-05 20:58   ` Martijn Dekker
  2019-01-05 21:55     ` Daniel Shahaf
  1 sibling, 1 reply; 39+ messages in thread
From: Martijn Dekker @ 2019-01-05 20:58 UTC (permalink / raw)
  To: Zsh hackers list

Op 05-01-19 om 18:49 schreef Peter Stephenson:
> wget https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3/zsh-5.6.2-test-3.tar.xz/download
> 
> except that the file you get is called "download", but a bit of
> scripting will fix that.

To get the correct file name, you can use URLs like:
https://download.sourceforge.net/zsh/zsh-5.6.2-test-3.tar.xz

- M.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-05 20:58   ` Martijn Dekker
@ 2019-01-05 21:55     ` Daniel Shahaf
  0 siblings, 0 replies; 39+ messages in thread
From: Daniel Shahaf @ 2019-01-05 21:55 UTC (permalink / raw)
  To: zsh-workers

Martijn Dekker wrote on Sat, 05 Jan 2019 21:58 +0100:
> Op 05-01-19 om 18:49 schreef Peter Stephenson:
> > wget https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3/zsh-5.6.2-test-3.tar.xz/download
> > 
> > except that the file you get is called "download", but a bit of
> > scripting will fix that.

No need for scripting; just pass --content-disposition to wget (the flag
takes no argument).

> 
> To get the correct file name, you can use URLs like:
> https://download.sourceforge.net/zsh/zsh-5.6.2-test-3.tar.xz

Should we use this link on http://zsh.sf.net/Arc/source.html and in the
release email announcement?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-05  7:08 Test release: 5.6.2-test-3 dana
  2019-01-05 17:49 ` Peter Stephenson
@ 2019-01-06  2:37 ` Axel Beckert
  2019-01-06 15:12 ` Jun T.
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 39+ messages in thread
From: Axel Beckert @ 2019-01-06  2:37 UTC (permalink / raw)
  To: zsh-workers

Hi dana,

On Sat, Jan 05, 2019 at 01:08:02AM -0600, dana wrote:
> I've tagged 5.6.2-test-3 and uploaded the artefacts to:
> 
> https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3

JFTR: The test suite failures on 32-bit architectures are indeed gone
with this:
https://buildd.debian.org/status/package.php?p=zsh&suite=experimental

		Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: abe@deuxchevaux.org  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: abe@noone.org  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-05  7:08 Test release: 5.6.2-test-3 dana
  2019-01-05 17:49 ` Peter Stephenson
  2019-01-06  2:37 ` Axel Beckert
@ 2019-01-06 15:12 ` Jun T.
  2019-01-06 16:37   ` dana
  2019-01-21 12:54 ` ETA for zsh 5.7? (was: Test release: 5.6.2-test-3) Axel Beckert
  2019-01-21 23:00 ` Bug with traps and exit Martijn Dekker
  4 siblings, 1 reply; 39+ messages in thread
From: Jun T. @ 2019-01-06 15:12 UTC (permalink / raw)
  To: zsh-workers


> 2019/01/05 16:08, dana <dana@dana.is> wrote:
> 
> PS: Building the docs on macOS is an insane ordeal. After messing with it for
> almost an hour i finally got to the point where i had to install X11 to
> generate the PDF and decided it just wasn't worth it. I ended up building on
> an old Linux lap-top. If anyone's done this on macOS before and knows a trick
> to it that doesn't require a million weird dependencies, please let me know

Are you having problems while trying to install yodl?
Or yodl has been successfully installed but still
can't generate PDF?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-06 15:12 ` Jun T.
@ 2019-01-06 16:37   ` dana
  2019-01-06 16:43     ` Daniel Shahaf
                       ` (2 more replies)
  0 siblings, 3 replies; 39+ messages in thread
From: dana @ 2019-01-06 16:37 UTC (permalink / raw)
  To: Jun T.; +Cc: zsh-workers

On 6 Jan 2019, at 09:12, Jun T. <takimoto-j@kba.biglobe.ne.jp> wrote:
>Are you having problems while trying to install yodl?
>Or yodl has been successfully installed but still
>can't generate PDF?

I've got yodl — cherry-picked from MacPorts, since Homebrew doesn't have it.
Building the man/HTML pages with that is no problem once i've got it.

For the PDF, i needed TeX, which the normal Homebrew repo also doesn't have i
guess because it's similarly complicated to build on macOS. Homebrew Cask has
the MacTeX distribution, but the full thing is over 3 GiB, which is silly. I
found the 'basic' distribution, though, and then i needed to manually install
the texinfo thing for it, and after all that i thought i'd be OK, but
apparently TeX needs X11 to generate the PDF for some reason (font stuff, i
assume).

On balance, X11 is probably smaller and easier to install than TeX. Still, it
felt excessive.

dana


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-06 16:37   ` dana
@ 2019-01-06 16:43     ` Daniel Shahaf
  2019-01-06 16:56       ` dana
  2019-01-06 21:34     ` Daniel Tameling
  2019-01-07  3:25     ` Jun T
  2 siblings, 1 reply; 39+ messages in thread
From: Daniel Shahaf @ 2019-01-06 16:43 UTC (permalink / raw)
  To: zsh-workers

dana wrote on Sun, 06 Jan 2019 10:37 -0600:
> On 6 Jan 2019, at 09:12, Jun T. <takimoto-j@kba.biglobe.ne.jp> wrote:
> >Are you having problems while trying to install yodl?
> >Or yodl has been successfully installed but still
> >can't generate PDF?
> 
> I've got yodl — cherry-picked from MacPorts, since Homebrew doesn't have it.
> Building the man/HTML pages with that is no problem once i've got it.
> 
> For the PDF, i needed TeX, which the normal Homebrew repo also doesn't have i
> guess because it's similarly complicated to build on macOS. Homebrew Cask has
> the MacTeX distribution, but the full thing is over 3 GiB, which is silly. I
> found the 'basic' distribution, though, and then i needed to manually install
> the texinfo thing for it, and after all that i thought i'd be OK, but
> apparently TeX needs X11 to generate the PDF for some reason (font stuff, i
> assume).
> 
> On balance, X11 is probably smaller and easier to install than TeX. Still, it
> felt excessive.

I doubt that you need the entire 3 GiB of it.  I have only
2.3 GiB of texlive-* packages installed [1], and I use TeX for non-zsh
stuff too.  It's probably pulling half of CTAN (the TeX library
packages archive), while you only need core LaTeX and whichever
\usepackage{} packages yodl and texinfo need

Cheers,

Daniel

[1] dpkg -L $(dpkg -l texlive | awk '{print $2}') | perl -lnE '$a += -s if -e; end { say $a }'

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-06 16:43     ` Daniel Shahaf
@ 2019-01-06 16:56       ` dana
  0 siblings, 0 replies; 39+ messages in thread
From: dana @ 2019-01-06 16:56 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: zsh-workers

On 6 Jan 2019, at 10:43, Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>I doubt that you need the entire 3 GiB of it.  I have only
>2.3 GiB of texlive-* packages installed [1]

Yeah. On Ubuntu i was able to just do `apt-get build-dep zsh` and it installed
the right packages for it. Without X11 (which i already had obv), it wasn't
too extreme

dana


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-06 16:37   ` dana
  2019-01-06 16:43     ` Daniel Shahaf
@ 2019-01-06 21:34     ` Daniel Tameling
  2019-01-07  3:25     ` Jun T
  2 siblings, 0 replies; 39+ messages in thread
From: Daniel Tameling @ 2019-01-06 21:34 UTC (permalink / raw)
  To: zsh-workers

On Sun, Jan 06, 2019 at 10:37:20AM -0600, dana wrote:
> On 6 Jan 2019, at 09:12, Jun T. <takimoto-j@kba.biglobe.ne.jp> wrote:
> >Are you having problems while trying to install yodl?
> >Or yodl has been successfully installed but still
> >can't generate PDF?
> 
> I've got yodl — cherry-picked from MacPorts, since Homebrew doesn't have it.
> Building the man/HTML pages with that is no problem once i've got it.
> 
> For the PDF, i needed TeX, which the normal Homebrew repo also doesn't have i
> guess because it's similarly complicated to build on macOS. Homebrew Cask has
> the MacTeX distribution, but the full thing is over 3 GiB, which is silly. I
> found the 'basic' distribution, though, and then i needed to manually install
> the texinfo thing for it, and after all that i thought i'd be OK, but
> apparently TeX needs X11 to generate the PDF for some reason (font stuff, i
> assume).
> 
> On balance, X11 is probably smaller and easier to install than TeX. Still, it
> felt excessive.
> 
> dana
> 

Hi,

you might want to try MacPorts also for TeX. They split the whole
distribution up into smaller packages:
https://trac.macports.org/wiki/TeXLivePackages
If you're lucky, texlive-basic is already enough. I think the package
has some hidden X11 dependencies, so if you're really lucky, that's
all you need. If not, there is also the xorg package, which feels
significantly smaller than TeX, but I might be mistaken on that one.

I have both, TeX and X11, installed but stilled failed to build the
entire documentation because roff2ps is missing. So this might not be
the end for you if you want to try it again.

--
Best,
Daniel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-06 16:37   ` dana
  2019-01-06 16:43     ` Daniel Shahaf
  2019-01-06 21:34     ` Daniel Tameling
@ 2019-01-07  3:25     ` Jun T
  2019-01-07  7:02       ` dana
  2 siblings, 1 reply; 39+ messages in thread
From: Jun T @ 2019-01-07  3:25 UTC (permalink / raw)
  To: zsh-workers


> 2019/01/07 1:37, dana <dana@dana.is> wrote:
> 
> For the PDF, i needed TeX, which the normal Homebrew repo also doesn't have i
> guess because it's similarly complicated to build on macOS. Homebrew Cask has
> the MacTeX distribution, but the full thing is over 3 GiB, which is silly. I
> found the 'basic' distribution, though, and then i needed to manually install
> the texinfo thing for it, and after all that i thought i'd be OK, but
> apparently TeX needs X11 to generate the PDF for some reason (font stuff, i
> assume).

I'm using the binary distribution from http://www.tug.org/mactex/
(MacTeX.pkg, 3.2GB) and it works fine. It also includes gs (ghostscript)
and ps2pdf. Of course X11 is NOT required.

# I haven't tried the BasicTeX.pkg and don't know whether it works or not.

Can you create PDF from a simple LaTeX source by pdflatex command?


> 2019/01/07 6:34, Daniel Tameling <tamelingdaniel@gmail.com> wrote:
> 
> I have both, TeX and X11, installed but stilled failed to build the
> entire documentation because roff2ps is missing. So this might not be
> the end for you if you want to try it again.

I'm using /usr/bin/groff in place of roff2ps and it seems to work.
Create a script like

#!/bin/sh
groff -T ps "$@"

name it roff2ps, and put it somewhere in your PATH.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Test release: 5.6.2-test-3
  2019-01-07  3:25     ` Jun T
@ 2019-01-07  7:02       ` dana
  0 siblings, 0 replies; 39+ messages in thread
From: dana @ 2019-01-07  7:02 UTC (permalink / raw)
  To: Jun T; +Cc: zsh-workers

On 6 Jan 2019, at 21:25, Jun T <takimoto-j@kba.biglobe.ne.jp> wrote:
>I'm using the binary distribution from http://www.tug.org/mactex/
>(MacTeX.pkg, 3.2GB) and it works fine. It also includes gs (ghostscript)
>and ps2pdf. Of course X11 is NOT required.
>
># I haven't tried the BasicTeX.pkg and don't know whether it works or not.
>
>Can you create PDF from a simple LaTeX source by pdflatex command?

I didn't have a TeX file so i just tried to make the docs again. This time it
worked. I wish i could say what error i got before, but it's scrolled off my
buffer by now. I think it might have been the one Phil was getting in
workers/33415, which is what got it into my head that X11 was required.

Anyway, i guess it works. Thanks everyone for trying to help, and sorry for
the apparently unnecessary complaining :/

dana


^ permalink raw reply	[flat|nested] 39+ messages in thread

* ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-05  7:08 Test release: 5.6.2-test-3 dana
                   ` (2 preceding siblings ...)
  2019-01-06 15:12 ` Jun T.
@ 2019-01-21 12:54 ` Axel Beckert
  2019-01-21 14:26   ` Peter Stephenson
  2019-01-21 23:00 ` Bug with traps and exit Martijn Dekker
  4 siblings, 1 reply; 39+ messages in thread
From: Axel Beckert @ 2019-01-21 12:54 UTC (permalink / raw)
  To: zsh-workers

Hi,

On Sat, Jan 05, 2019 at 01:08:02AM -0600, dana wrote:
> I've tagged 5.6.2-test-3 and uploaded the artefacts to:
> 
> https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3

Any ETA for the final 5.7 release?

We're very close to the freeze[1] for Debian 10 Buster and I'd like to be
able to ship zsh 5.7 with it.

[1] https://release.debian.org/buster/freeze_policy.html

I use it on at least two machines (my workstation at home and my
thinkpad) and I didn't run into any issues so far.

		Kind regards, Axel
-- 
PGP: 2FF9CD59612616B5      /~\  Plain Text Ribbon Campaign, http://arc.pasp.de/
Mail: abe@deuxchevaux.org  \ /  Say No to HTML in E-Mail and Usenet
Mail+Jabber: abe@noone.org  X
https://axel.beckert.ch/   / \  I love long mails: https://email.is-not-s.ms/

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-21 12:54 ` ETA for zsh 5.7? (was: Test release: 5.6.2-test-3) Axel Beckert
@ 2019-01-21 14:26   ` Peter Stephenson
  2019-01-21 19:14     ` Mikael Magnusson
  0 siblings, 1 reply; 39+ messages in thread
From: Peter Stephenson @ 2019-01-21 14:26 UTC (permalink / raw)
  To: zsh-workers

On Mon, 2019-01-21 at 13:54 +0100, Axel Beckert wrote:
> On Sat, Jan 05, 2019 at 01:08:02AM -0600, dana wrote:
> > 
> > I've tagged 5.6.2-test-3 and uploaded the artefacts to:
> > 
> > https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3
> Any ETA for the final 5.7 release?

I'm not waiting for anything myself.

pws

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-21 14:26   ` Peter Stephenson
@ 2019-01-21 19:14     ` Mikael Magnusson
  2019-01-21 19:32       ` Mikael Magnusson
  2019-01-21 19:32       ` Mikael Magnusson
  0 siblings, 2 replies; 39+ messages in thread
From: Mikael Magnusson @ 2019-01-21 19:14 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

On 1/21/19, Peter Stephenson <p.stephenson@samsung.com> wrote:
> On Mon, 2019-01-21 at 13:54 +0100, Axel Beckert wrote:
>> On Sat, Jan 05, 2019 at 01:08:02AM -0600, dana wrote:
>> >
>> > I've tagged 5.6.2-test-3 and uploaded the artefacts to:
>> >
>> > https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3
>> Any ETA for the final 5.7 release?
>
> I'm not waiting for anything myself.

commit de31fe1f93890bce6cac1d443c7213b61fc512f5 breaks all colors in
my prompt, so I'd rather not see a release without this fixed.

-- 
Mikael Magnusson

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-21 19:14     ` Mikael Magnusson
@ 2019-01-21 19:32       ` Mikael Magnusson
  2019-01-21 21:56         ` Sebastian Gniazdowski
  2019-01-21 19:32       ` Mikael Magnusson
  1 sibling, 1 reply; 39+ messages in thread
From: Mikael Magnusson @ 2019-01-21 19:32 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

On 1/21/19, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 1/21/19, Peter Stephenson <p.stephenson@samsung.com> wrote:
>> On Mon, 2019-01-21 at 13:54 +0100, Axel Beckert wrote:
>>> On Sat, Jan 05, 2019 at 01:08:02AM -0600, dana wrote:
>>> >
>>> > I've tagged 5.6.2-test-3 and uploaded the artefacts to:
>>> >
>>> > https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3
>>> Any ETA for the final 5.7 release?
>>
>> I'm not waiting for anything myself.
>
> commit de31fe1f93890bce6cac1d443c7213b61fc512f5 breaks all colors in
> my prompt, so I'd rather not see a release without this fixed.

With the commit reverted,
% print -P %F{10}hello|cat -v
^[[38;5;10mhello

With the commit applied,
% print -P %F{10}hello|cat -v
^[[38;5;8;5;10mhello

I don't know what the purpose of the commit is, the message is very
unclear, it also doesn't appear to modify any documentation. I have
fg_start_code defined in zle_highlight and it worked up to that
commit. Blindly appending 8;5; to my custom start code seems extremely
broken and I have no idea under what circumstances it would ever be
correct to do so. In fact it directly contradicts the documentation:

fg_start_code (\e[3)
   The  start  of the escape sequence for the foreground colour.  This
is followed by an ASCII digit representing the colour.

8;5; is clearly not an ASCII digit.

-- 
Mikael Magnusson

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-21 19:14     ` Mikael Magnusson
  2019-01-21 19:32       ` Mikael Magnusson
@ 2019-01-21 19:32       ` Mikael Magnusson
  1 sibling, 0 replies; 39+ messages in thread
From: Mikael Magnusson @ 2019-01-21 19:32 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

On 1/21/19, Mikael Magnusson <mikachu@gmail.com> wrote:
> On 1/21/19, Peter Stephenson <p.stephenson@samsung.com> wrote:
>> On Mon, 2019-01-21 at 13:54 +0100, Axel Beckert wrote:
>>> On Sat, Jan 05, 2019 at 01:08:02AM -0600, dana wrote:
>>> >
>>> > I've tagged 5.6.2-test-3 and uploaded the artefacts to:
>>> >
>>> > https://sourceforge.net/projects/zsh/files/zsh-test/5.6.2-test-3
>>> Any ETA for the final 5.7 release?
>>
>> I'm not waiting for anything myself.
>
> commit de31fe1f93890bce6cac1d443c7213b61fc512f5 breaks all colors in
> my prompt, so I'd rather not see a release without this fixed.

With the commit reverted,
% print -P %F{10}hello|cat -v
^[[38;5;10mhello

With the commit applied,
% print -P %F{10}hello|cat -v
^[[38;5;8;5;10mhello

I don't know what the purpose of the commit is, the message is very
unclear, it also doesn't appear to modify any documentation. I have
fg_start_code defined in zle_highlight and it worked up to that
commit. Blindly appending 8;5; to my custom start code seems extremely
broken and I have no idea under what circumstances it would ever be
correct to do so. In fact it directly contradicts the documentation:

fg_start_code (\e[3)
   The  start  of the escape sequence for the foreground colour.  This
is followed by an ASCII digit representing the colour.

8;5; is clearly not an ASCII digit.

-- 
Mikael Magnusson

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-21 19:32       ` Mikael Magnusson
@ 2019-01-21 21:56         ` Sebastian Gniazdowski
  2019-01-22  9:29           ` Peter Stephenson
  0 siblings, 1 reply; 39+ messages in thread
From: Sebastian Gniazdowski @ 2019-01-21 21:56 UTC (permalink / raw)
  To: Mikael Magnusson; +Cc: Peter Stephenson, zsh-workers

[-- Attachment #1: Type: text/plain, Size: 2238 bytes --]

On Mon, 21 Jan 2019 at 20:32, Mikael Magnusson <mikachu@gmail.com> wrote:

> With the commit applied,
> % print -P %F{10}hello|cat -v
> ^[[38;5;8;5;10mhello

Following debugs shows that:
1. For color > 7, a termcap-route was being used, ignoring the fg_start_code
2. For color <= 7, the same termap-route was being used ignoring the
fg_start_code.
3. The fg_start_code-route is used only for colors <= 7 in some
other circumstances (I'm occuring this normally for an
region_highlight--&-colors<=7-utilizing code.)

http://sprunge.us/GcRDpx
(also attached as debug.txt)

So basically, Mikachu has following setting:

zle_highlight=( fg_start_code:$'\e[38;5;' )

It's always using termcap for color >= 8,, because of this line ~1983
in prompt.c::

    if (!def && (colour > 7 || use_termcap)) {

But also, the `use_termcap' is apparently always being set if colur > 7.

But the new code, NEVER IGNORES fg_start_code if it's different from
the default «\e[». So the code starts to finally use the fg_start_code
and problems appear. The problems come from the fact that: the are
additional fields needed in zle_highlight, to make it fully usable.
With the new code it IS usable as it is basically USED after all when
set, so e.g. a debugging code (the X04 tests) can use the
zle_highlight mechanism reliably.

> Blindly appending 8;5; to my custom start code seems extremely
> broken and I have no idea under what circumstances it would ever be
> correct to do so. In fact it directly contradicts the documentation:
>
> fg_start_code (\e[3)
>    The  start  of the escape sequence for the foreground colour.  This
> is followed by an ASCII digit representing the colour.
>
> 8;5; is clearly not an ASCII digit.

Ok, but the documentation also misses the fact that in the OLD code,
for col > 7 termcap is used anyway, and also the same for col <= 7, if
the color is invoked in `print -P %F{5}' and possibly other situations
(but not always, region_highlight utilizing the first 8 colors does
use fg_start_code also in the old code).

--
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

[-- Attachment #2: debug.txt --]
[-- Type: text/plain, Size: 2875 bytes --]


Doing: print -P %F{10}hello | cat -v

The debug logs (code at the bottom):

Yes, using termcap, color:10 / tccolors:256 / use_termcap:268435456
Yes, using termcap, color:10 / tccolors:256 / use_termcap:268435456
NOT, using termcap, 7 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
Yes, using termcap, 63 / 256 / 268435456
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
NOT, using termcap, 7 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
Yes, using termcap, 63 / 256 / 268435456
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]


Doing: print -P %F{5}hello | cat -v

Yes, using termcap, 5 / 256 / 268435456
Yes, using termcap, 5 / 256 / 268435456
NOT, using termcap, 7 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
Yes, using termcap, 63 / 256 / 268435456
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
NOT, using termcap, 7 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]
Yes, using termcap, 63 / 256 / 268435456
NOT, using termcap, 0 / 256 / 0
Appended [^[[38;5;] to the colseq_buf[^[[38;5;]




diff --git a/Src/prompt.c b/Src/prompt.c
index 959ed8e3d..1941b8ec9 100644
--- a/Src/prompt.c
+++ b/Src/prompt.c
@@ -1987,6 +1987,14 @@ set_colour_attribute(int atr, int fg_bg, int flags)
 	 */
 	if (tccan(tc) && (tccolours < 0 || colour < tccolours))
 	{
+            
+            FILE *f = fopen("/tmp/reply", "a+");
+            if ( f ) {
+                fprintf(f, "Yes, using termcap, color:%d / tccolours:%d / use_termcap:%d\n", colour, tccolours, use_termcap);
+                fflush(f);
+                fclose(f);
+            }
+
 	    if (is_prompt)
 	    {
 		if (!bv->dontcount) {
@@ -2010,6 +2018,13 @@ set_colour_attribute(int atr, int fg_bg, int flags)
 	 */
 	if (colour > 7)
 	    return;
+    } else {
+        FILE *f = fopen("/tmp/reply", "a+");
+        if ( f ) {
+            fprintf(f, "NOT, using termcap, %d / %d / %d\n", colour, tccolours, use_termcap);
+            fflush(f);
+            fclose(f);
+        }
     }
 
     if ((do_free = (colseq_buf == NULL))) {
@@ -2019,6 +2034,11 @@ set_colour_attribute(int atr, int fg_bg, int flags)
 
     strcpy(colseq_buf, fg_bg_sequences[fg_bg].start);
 
+    FILE *f = fopen("/tmp/reply", "a+");
+    fprintf(f, "Appended [%s] to the colseq_buf[%s]\n", fg_bg_sequences[fg_bg].start, colseq_buf);
+    fflush(f);
+    fclose(f);
+
     ptr = colseq_buf + strlen(colseq_buf);
     if (def) {
 	strcpy(ptr, fg_bg_sequences[fg_bg].def);




^ permalink raw reply	[flat|nested] 39+ messages in thread

* Bug with traps and exit
  2019-01-05  7:08 Test release: 5.6.2-test-3 dana
                   ` (3 preceding siblings ...)
  2019-01-21 12:54 ` ETA for zsh 5.7? (was: Test release: 5.6.2-test-3) Axel Beckert
@ 2019-01-21 23:00 ` Martijn Dekker
  2019-11-24  5:54   ` Martijn Dekker
  4 siblings, 1 reply; 39+ messages in thread
From: Martijn Dekker @ 2019-01-21 23:00 UTC (permalink / raw)
  To: zsh-workers

Found a strange issue with traps and 'exit'.

Test script:

trap 'printf $1; exit; printf $2' USR1
fn() {
        printf 1
        kill -s usr1 $$
        printf 2
}
printf 0
fn A B
printf 3

Every shell outputs 01A, except zsh, which outputs 01A2.

This means the execution of the fn() function is not interrupted. The
USR1 trap executes 'exit' and does not execute the rest of the trap
action, but instead of exiting the shell, zsh continues to execute fn()
and then exits.

Confirmed down to zsh 5.0.8 (didn't test earlier versions).

- M.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: ETA for zsh 5.7? (was: Test release: 5.6.2-test-3)
  2019-01-21 21:56         ` Sebastian Gniazdowski
@ 2019-01-22  9:29           ` Peter Stephenson
  0 siblings, 0 replies; 39+ messages in thread
From: Peter Stephenson @ 2019-01-22  9:29 UTC (permalink / raw)
  To: Zsh Hackers' List

It sounds like something needs doing to the colour management before the
release, but from the emails so far I have no clue what --- it's not
clear to me even if removing the last patch (or even more?) is generally
better.  But I'll wait to see if some sort of enlightenment emerges.

No one responded to Daniel's comment on the file completion patch, and I
didn't have anything particularly helpful to add at the time.  As you
might guess from the original post, four lines of not very complicated
shell code in response to a specific user request for optional behaviour
fits comfortably within my own normal operating parameters, which are
obviously what I'm applying here, but I note the objection, and look
forward to the day when someone else is sending round these sorts of
emails and will be making their own decisions.

pws



^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-01-21 23:00 ` Bug with traps and exit Martijn Dekker
@ 2019-11-24  5:54   ` Martijn Dekker
  2019-11-25 16:42     ` Sebastian Gniazdowski
                       ` (2 more replies)
  0 siblings, 3 replies; 39+ messages in thread
From: Martijn Dekker @ 2019-11-24  5:54 UTC (permalink / raw)
  To: zsh-workers

Op 22-01-19 om 00:00 schreef Martijn Dekker:
> Found a strange issue with traps and 'exit'.
> 
> Test script:
> 
> trap 'printf $1; exit; printf $2' USR1
> fn() {
>          printf 1
>          kill -s usr1 $$
>          printf 2
> }
> printf 0
> fn A B
> printf 3
> 
> Every shell outputs 01A, except zsh, which outputs 01A2.
> 
> This means the execution of the fn() function is not interrupted. The
> USR1 trap executes 'exit' and does not execute the rest of the trap
> action, but instead of exiting the shell, zsh continues to execute fn()
> and then exits.
> 
> Confirmed down to zsh 5.0.8 (didn't test earlier versions).

A related issue (possibly the same?) with a much simpler test case:

trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
kill -s INT $$

zsh prints 'woops', but shouldn't.

- M.

-- 
modernish -- harness the shell
https://github.com/modernish/modernish

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-11-24  5:54   ` Martijn Dekker
@ 2019-11-25 16:42     ` Sebastian Gniazdowski
  2019-12-10 19:23     ` Martijn Dekker
  2019-12-16  5:27     ` The bug from workers/44922 (was: " Daniel Shahaf
  2 siblings, 0 replies; 39+ messages in thread
From: Sebastian Gniazdowski @ 2019-11-25 16:42 UTC (permalink / raw)
  To: Martijn Dekker; +Cc: Zsh hackers list

On Sun, 24 Nov 2019 at 23:52, Martijn Dekker <martijn@inlv.org> wrote:
> A related issue (possibly the same?) with a much simpler test case:
>
> trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> kill -s INT $$
>
> zsh prints 'woops', but shouldn't.

One thing – this one doesn't reproduce in the exact sense – either
from the command line or from a script. Second – however, this prints
the "test":

trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
kill -s INT $$
print test

when run as a script or from command line. But I guess that the
default INT trap is a 'return' which doesn't cause the shell to exit?
This isn't stated exactly in the manual.

-- 
Sebastian Gniazdowski
News: https://twitter.com/ZdharmaI
IRC: https://kiwiirc.com/client/chat.freenode.net:+6697/#zplugin
Blog: http://zdharma.org

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-11-24  5:54   ` Martijn Dekker
  2019-11-25 16:42     ` Sebastian Gniazdowski
@ 2019-12-10 19:23     ` Martijn Dekker
  2019-12-11  2:40       ` Daniel Shahaf
  2019-12-12 10:14       ` Peter Stephenson
  2019-12-16  5:27     ` The bug from workers/44922 (was: " Daniel Shahaf
  2 siblings, 2 replies; 39+ messages in thread
From: Martijn Dekker @ 2019-12-10 19:23 UTC (permalink / raw)
  To: zsh-workers

Op 24-11-19 om 06:54 schreef Martijn Dekker:
[...]
> A related issue (possibly the same?) with a much simpler test case:
> 
> trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> kill -s INT $$
> 
> zsh prints 'woops', but shouldn't.

Ping?

Is this just being missed, or is it considered too unimportant?

Thanks,

- M.

-- 
modernish -- harness the shell
https://github.com/modernish/modernish

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-10 19:23     ` Martijn Dekker
@ 2019-12-11  2:40       ` Daniel Shahaf
  2019-12-12 10:14       ` Peter Stephenson
  1 sibling, 0 replies; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-11  2:40 UTC (permalink / raw)
  To: Martijn Dekker; +Cc: zsh-workers

Martijn Dekker wrote on Tue, Dec 10, 2019 at 20:23:37 +0100:
> Op 24-11-19 om 06:54 schreef Martijn Dekker:
> [...]
> > A related issue (possibly the same?) with a much simpler test case:
> > 
> > trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> > kill -s INT $$
> > 
> > zsh prints 'woops', but shouldn't.
> 
> Ping?
> 
> Is this just being missed, or is it considered too unimportant?

Missed, I think.  Maybe because this thread is a subthread of the 5.6.2-test-3
release announcement?

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-10 19:23     ` Martijn Dekker
  2019-12-11  2:40       ` Daniel Shahaf
@ 2019-12-12 10:14       ` Peter Stephenson
  2019-12-13 14:26         ` Martijn Dekker
  1 sibling, 1 reply; 39+ messages in thread
From: Peter Stephenson @ 2019-12-12 10:14 UTC (permalink / raw)
  To: zsh-workers

On Tue, 2019-12-10 at 20:23 +0100, Martijn Dekker wrote:
> Op 24-11-19 om 06:54 schreef Martijn Dekker:
> [...]
> > 
> > A related issue (possibly the same?) with a much simpler test case:
> > 
> > trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> > kill -s INT $$
> > 
> > zsh prints 'woops', but shouldn't.
> Ping?
> 
> Is this just being missed, or is it considered too unimportant?

Are you saying there's a fix for this we need to apply?  I haven't seen
one.

pws


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-12 10:14       ` Peter Stephenson
@ 2019-12-13 14:26         ` Martijn Dekker
  2019-12-13 14:49           ` Peter Stephenson
  0 siblings, 1 reply; 39+ messages in thread
From: Martijn Dekker @ 2019-12-13 14:26 UTC (permalink / raw)
  To: zsh-workers

Op 12-12-19 om 11:14 schreef Peter Stephenson:
> On Tue, 2019-12-10 at 20:23 +0100, Martijn Dekker wrote:
>> Op 24-11-19 om 06:54 schreef Martijn Dekker:
>> [...]
>>>   
>>> A related issue (possibly the same?) with a much simpler test case:
>>>   
>>> trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
>>> kill -s INT $$
>>>   
>>> zsh prints 'woops', but shouldn't.
>> Ping?
>>   
>> Is this just being missed, or is it considered too unimportant?
> 
> Are you saying there's a fix for this we need to apply?  I haven't seen
> one.

No, I'm saying my nearly year-old bug report seems to be being either 
overlooked or ignored.

I don't have the expertise to fix this myself. Signal handling in C is 
beyond me. I could give it a try, but it would likely be wrong and/or 
broken, so I figure I might as well not waste your time or mine.

So far, zsh maintainers have been receptive to bug reports (mine and 
others) even if the reporter can't provide a fix. Has that changed?

I mean, I'm not trying to criticise anyone. I fully understand if you 
only want bug report with patches. It's just that that isn't how things 
seem to have worked so far.

- M.

-- 
modernish -- harness the shell
https://github.com/modernish/modernish

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-13 14:26         ` Martijn Dekker
@ 2019-12-13 14:49           ` Peter Stephenson
  2019-12-14 11:28             ` Daniel Shahaf
  0 siblings, 1 reply; 39+ messages in thread
From: Peter Stephenson @ 2019-12-13 14:49 UTC (permalink / raw)
  To: zsh-workers

On Fri, 2019-12-13 at 15:26 +0100, Martijn Dekker wrote:
> So far, zsh maintainers have been receptive to bug reports (mine and 
> others) even if the reporter can't provide a fix. Has that changed?

No, you're doing the right thing, just checking I wasn't missing
anything.

As you know, getting anyone interested in looking at things is very
difficult.  I'm taking more of a back seat myself, unless I can see
something glaring.  Anyone is more than welcome to jump in while
the old guard is still looking on to help.

pws


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-13 14:49           ` Peter Stephenson
@ 2019-12-14 11:28             ` Daniel Shahaf
  2019-12-15 18:59               ` Peter Stephenson
  0 siblings, 1 reply; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-14 11:28 UTC (permalink / raw)
  To: zsh-workers

Peter Stephenson wrote on Fri, Dec 13, 2019 at 14:49:40 +0000:
> As you know, getting anyone interested in looking at things is very
> difficult.  I'm taking more of a back seat myself, unless I can see
> something glaring.  Anyone is more than welcome to jump in while
> the old guard is still looking on to help.

I don't know about others, but I'm not even sure where to begin fixing this.
I can find the code handling traps easily enough ('intrap', etc), and I know
where the code handling functions is (doshfunc()), but how to proceed?  Would
the right fix be to add some code in the end of runshfunc(), after
unqueue_signals(), that checks whether a trap has been executed and called
'exit'…?

If anyone else want to jump in, please do!

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-14 11:28             ` Daniel Shahaf
@ 2019-12-15 18:59               ` Peter Stephenson
  2019-12-16  5:24                 ` Daniel Shahaf
  0 siblings, 1 reply; 39+ messages in thread
From: Peter Stephenson @ 2019-12-15 18:59 UTC (permalink / raw)
  To: zsh-workers

On Sat, 2019-12-14 at 11:28 +0000, Daniel Shahaf wrote:
> Peter Stephenson wrote on Fri, Dec 13, 2019 at 14:49:40 +0000:
> > As you know, getting anyone interested in looking at things is very
> > difficult.  I'm taking more of a back seat myself, unless I can see
> > something glaring.  Anyone is more than welcome to jump in while
> > the old guard is still looking on to help.
> 
> I don't know about others, but I'm not even sure where to begin fixing this.
> I can find the code handling traps easily enough ('intrap', etc), and I know
> where the code handling functions is (doshfunc()), but how to proceed?  Would
> the right fix be to add some code in the end of runshfunc(), after
> unqueue_signals(), that checks whether a trap has been executed and called
> 'exit'…?

OK, so this is deliberately somewhat wordier than if I was just replying
to the message myself, to try to get my thinking across.  So please bear
with me.

Frankly, I'm never sure where to begin fixing *anything* that's not
immediately obvious.  The first step in something like this is to
identify key points where things need to happen and may or may not
actually be happening, and then work out whether we're hitting those
points, and if not, why not, and if so, why it's doing something
different there from what it should (which may include setting something
up differently for a future action, in this case on signal delivery).

> trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> kill -s INT $$
> 
> zsh prints 'woops', but shouldn't.

Martijn is presumably saying the trap - INT within the trap should reset
it so the interrupt stops the rest of the trap being dlievered.  So does
it reset it?  Actually, there's some important information below so you
probably don't need to, but what you'd have to do is trace through to
see what's happening on the "trap - INT" on the trap by getting the
shell to stop when it executes the trap command in the signal caught by
the kill.  The trap is set by the bin_trap() handler; zhandler() is
called if the shell is handling an interrupt, though not if the
interrupt is set up to kill or suspend the shell or whatever.

One easy and obvious thing to try is to simplify:

trap - INT; kill -S INT $$; echo foo

That doesn't echo "foo"; that's because the INT is delivered
immedately.  The shell doesn't exit if it's interactive, but we do get
returned immediately to the command line.

In fact, to shortcut the investigation, I think the key point here is to
note that the trap is executed inside the signal handler (see the other
recent thread on signal handlers).  So we'd expect the "kill -s INT"
inside the trap to be delivered after the first trap has exited.  So
that's probably why you get "whoops".  So is that really a problem?
You'll have to disucss that with Martijn.  Obviously that's not going to
change fundamentally without a complete rewrite, and this looks to me a
rather silly experiment anywawy --- it looks to me like it's abusing the
mechanism to reissue a signal within something designed to handle the
signal and then expect that to do something within that same handler ---
but I don't want to have to go on deciding all this by myself, so feel
free to disagree and discuss further.

pws


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-15 18:59               ` Peter Stephenson
@ 2019-12-16  5:24                 ` Daniel Shahaf
  2019-12-16  6:37                   ` Bart Schaefer
  2019-12-16 10:09                   ` Peter Stephenson
  0 siblings, 2 replies; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-16  5:24 UTC (permalink / raw)
  To: Peter Stephenson; +Cc: zsh-workers

Peter,

Thanks for all the details.

I'm afraid there are two distinct bugs being discussed in this thread.  One is
workers/44922, which you analyzed in detail.  I'll follow up about that one
with Martijn.  However, the bug I was confused about how to get started on is
workers/44007 (also in this thread):

> trap 'printf $1; exit; printf $2' USR1
> fn() {
>         printf 1
>         kill -s usr1 $$
>         printf 2
> }
> printf 0
> fn A B
> printf 3

Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.
This suggests the 'exit' inhibits «printf $2» and «printf 3» from running, but
doesn't inhibit «printf 2» (without a dollar sign) from running.  How would
you approach something like this?  I'm guessing bin_exit should set a global
volatile int variable to '1' if it's called from a signal handler, but where
would that variable be checked?

Thanks,

Daniel


Peter Stephenson wrote on Sun, Dec 15, 2019 at 18:59:21 +0000:
> On Sat, 2019-12-14 at 11:28 +0000, Daniel Shahaf wrote:
> > Peter Stephenson wrote on Fri, Dec 13, 2019 at 14:49:40 +0000:
> > > As you know, getting anyone interested in looking at things is very
> > > difficult.  I'm taking more of a back seat myself, unless I can see
> > > something glaring.  Anyone is more than welcome to jump in while
> > > the old guard is still looking on to help.
> > 
> > I don't know about others, but I'm not even sure where to begin fixing this.
> > I can find the code handling traps easily enough ('intrap', etc), and I know
> > where the code handling functions is (doshfunc()), but how to proceed?  Would
> > the right fix be to add some code in the end of runshfunc(), after
> > unqueue_signals(), that checks whether a trap has been executed and called
> > 'exit'…?
> 
> OK, so this is deliberately somewhat wordier than if I was just replying
> to the message myself, to try to get my thinking across.  So please bear
> with me.
> 
> Frankly, I'm never sure where to begin fixing *anything* that's not
> immediately obvious.  The first step in something like this is to
> identify key points where things need to happen and may or may not
> actually be happening, and then work out whether we're hitting those
> points, and if not, why not, and if so, why it's doing something
> different there from what it should (which may include setting something
> up differently for a future action, in this case on signal delivery).
> 
> > trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> > kill -s INT $$
> > 
> > zsh prints 'woops', but shouldn't.
> 
> Martijn is presumably saying the trap - INT within the trap should reset
> it so the interrupt stops the rest of the trap being dlievered.  So does
> it reset it?  Actually, there's some important information below so you
> probably don't need to, but what you'd have to do is trace through to
> see what's happening on the "trap - INT" on the trap by getting the
> shell to stop when it executes the trap command in the signal caught by
> the kill.  The trap is set by the bin_trap() handler; zhandler() is
> called if the shell is handling an interrupt, though not if the
> interrupt is set up to kill or suspend the shell or whatever.
> 
> One easy and obvious thing to try is to simplify:
> 
> trap - INT; kill -S INT $$; echo foo
> 
> That doesn't echo "foo"; that's because the INT is delivered
> immedately.  The shell doesn't exit if it's interactive, but we do get
> returned immediately to the command line.
> 
> In fact, to shortcut the investigation, I think the key point here is to
> note that the trap is executed inside the signal handler (see the other
> recent thread on signal handlers).  So we'd expect the "kill -s INT"
> inside the trap to be delivered after the first trap has exited.  So
> that's probably why you get "whoops".  So is that really a problem?
> You'll have to disucss that with Martijn.  Obviously that's not going to
> change fundamentally without a complete rewrite, and this looks to me a
> rather silly experiment anywawy --- it looks to me like it's abusing the
> mechanism to reissue a signal within something designed to handle the
> signal and then expect that to do something within that same handler ---
> but I don't want to have to go on deciding all this by myself, so feel
> free to disagree and discuss further.
> 
> pws
> 

^ permalink raw reply	[flat|nested] 39+ messages in thread

* The bug from workers/44922 (was: Re: Bug with traps and exit
  2019-11-24  5:54   ` Martijn Dekker
  2019-11-25 16:42     ` Sebastian Gniazdowski
  2019-12-10 19:23     ` Martijn Dekker
@ 2019-12-16  5:27     ` " Daniel Shahaf
  2 siblings, 0 replies; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-16  5:27 UTC (permalink / raw)
  To: Martijn Dekker; +Cc: zsh-workers

Good morning Martijn,

Martijn Dekker wrote on Sun, Nov 24, 2019 at 06:54:18 +0100:
> Op 22-01-19 om 00:00 schreef Martijn Dekker:
> > Found a strange issue with traps and 'exit'.
> > 
> > Test script:
> > 
> > trap 'printf $1; exit; printf $2' USR1
> > fn() {
> >          printf 1
> >          kill -s usr1 $$
> >          printf 2
> > }
> > printf 0
> > fn A B
> > printf 3
> > 
> > Every shell outputs 01A, except zsh, which outputs 01A2.
> > 
> > This means the execution of the fn() function is not interrupted. The
> > USR1 trap executes 'exit' and does not execute the rest of the trap
> > action, but instead of exiting the shell, zsh continues to execute fn()
> > and then exits.
> > 
> > Confirmed down to zsh 5.0.8 (didn't test earlier versions).
> 
> A related issue (possibly the same?) with a much simpler test case:
> 
> trap 'echo SIGINT; trap - INT; kill -s INT $$; echo woops' INT
> kill -s INT $$
> 
> zsh prints 'woops', but shouldn't.

As Peter observed in 45037, could you elaborate on why the inner 'kill' should
abort execution of the trap?

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-16  5:24                 ` Daniel Shahaf
@ 2019-12-16  6:37                   ` Bart Schaefer
  2019-12-17  7:31                     ` Daniel Shahaf
  2019-12-16 10:09                   ` Peter Stephenson
  1 sibling, 1 reply; 39+ messages in thread
From: Bart Schaefer @ 2019-12-16  6:37 UTC (permalink / raw)
  To: Daniel Shahaf; +Cc: Peter Stephenson, zsh-workers

On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>
> workers/44007 (also in this thread):
>
> > trap 'printf $1; exit; printf $2' USR1
> > fn() {
> >         printf 1
> >         kill -s usr1 $$
> >         printf 2
> > }
> > printf 0
> > fn A B
> > printf 3
>
> Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.

Have a look at the "shell_exiting" global manipulated in builtin.c.
(Some comments still refer to "in_exit" which IIRC was replaced by
"shell_exiting".)

> This suggests the 'exit' inhibits «printf $2» and «printf 3» from running, but
> doesn't inhibit «printf 2» (without a dollar sign) from running.  How would
> you approach something like this?  I'm guessing bin_exit should set a global
> volatile int variable to '1' if it's called from a signal handler, but where
> would that variable be checked?

Note that "from_where" in zexit() already indicates whether we are
coming from a signal, but bin_break (which handles BIN_EXIT) does not
treat "in a signal handler" as "coming from a signal" when calling
zexit().  This is why the function continues running -- zexit() passes
from_where = 2 ("can't actually exit yet"), I suspect in order to
allow running an EXIT trap set by the function itself.

The trouble is that we also have to treat differently the cases of the
trap having been set inside the function, and the trap existing
outside the function when the function is called.  Trivially treating
exit from a handler the same as being killed by signal whose default
behavior is to exit, leads to failures in the test suite.

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-16  5:24                 ` Daniel Shahaf
  2019-12-16  6:37                   ` Bart Schaefer
@ 2019-12-16 10:09                   ` Peter Stephenson
  1 sibling, 0 replies; 39+ messages in thread
From: Peter Stephenson @ 2019-12-16 10:09 UTC (permalink / raw)
  To: zsh-workers

On Mon, 2019-12-16 at 05:24 +0000, Daniel Shahaf wrote:
> > trap 'printf $1; exit; printf $2' USR1
> > fn() {
> >         printf 1
> >         kill -s usr1 $$
> >         printf 2
> > }
> > printf 0
> > fn A B
> > printf 3
> Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.
> This suggests the 'exit' inhibits «printf $2» and «printf 3» from running, but
> doesn't inhibit «printf 2» (without a dollar sign) from running.  How would
> you approach something like this?  I'm guessing bin_exit should set a global
> volatile int variable to '1' if it's called from a signal handler, but where
> would that variable be checked?

Looks like Bart's already come up with the major gotchas in this case
--- there are some deliberate delays in handling around exiting and this
might well interact badly with an asynchronous signal.

pws


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-16  6:37                   ` Bart Schaefer
@ 2019-12-17  7:31                     ` Daniel Shahaf
  2019-12-17 20:29                       ` Peter Stephenson
  0 siblings, 1 reply; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-17  7:31 UTC (permalink / raw)
  To: zsh-workers

Bart Schaefer wrote on Sun, Dec 15, 2019 at 22:37:53 -0800:
> On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >
> > workers/44007 (also in this thread):
> >
> > > trap 'printf $1; exit; printf $2' USR1
> > > fn() {
> > >         printf 1
> > >         kill -s usr1 $$
> > >         printf 2
> > > }
> > > printf 0
> > > fn A B
> > > printf 3
> >
> > Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.
> 
> Have a look at the "shell_exiting" global manipulated in builtin.c.

Okay, so as far I can tell, the flow is:

- fn() called

- signal sent

- signal received

- trap called

- exit called

- zexit(ZEXIT_DEFERRED) called, and returns immediately

  + Note: shell_exiting is NOT incremented, because the || condition in zexit() short circuits

- exit_pending is set

- The remainder of the trap is skipped (I assume that's because bin_break() set retflag?)

- The remainder of fn() is executed

- At the end of doshfunc(), exit_pending is tested and zexit(ZEXIT_NORMAL) is called

I have not verified every single detail here in the debugger, but hopefully I'm
not too far off the mark.

So, I'm still not sure what to do... but I'm guessing that when execution of
the trap ends, something-or-other clears retflag, so the 'list' that's the body
of fn() continues execution?  Does this sound about right?

> (Some comments still refer to "in_exit" which IIRC was replaced by
> "shell_exiting".)

It was one comment.  I've updated it.

> > This suggests the 'exit' inhibits «printf $2» and «printf 3» from running, but
> > doesn't inhibit «printf 2» (without a dollar sign) from running.  How would
> > you approach something like this?  I'm guessing bin_exit should set a global
> > volatile int variable to '1' if it's called from a signal handler, but where
> > would that variable be checked?
> 
> Note that "from_where" in zexit() already indicates whether we are
> coming from a signal, but bin_break (which handles BIN_EXIT) does not
> treat "in a signal handler" as "coming from a signal" when calling
> zexit().  This is why the function continues running -- zexit() passes
> from_where = 2 ("can't actually exit yet"), I suspect in order to
> allow running an EXIT trap set by the function itself.
> 
> The trouble is that we also have to treat differently the cases of the
> trap having been set inside the function, and the trap existing
> outside the function when the function is called.

Why?

> Trivially treating exit from a handler the same as being killed by signal
> whose default behavior is to exit, leads to failures in the test suite.

Could you show the patch you tested here (even though it doesn't work)?  Did you
make bin_break() call zexit(…, intrap ? ZEXIT_SIGNAL : <incumbent value>)?

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-17  7:31                     ` Daniel Shahaf
@ 2019-12-17 20:29                       ` Peter Stephenson
  2019-12-18  0:31                         ` Daniel Shahaf
  0 siblings, 1 reply; 39+ messages in thread
From: Peter Stephenson @ 2019-12-17 20:29 UTC (permalink / raw)
  To: zsh-workers

On Tue, 2019-12-17 at 07:31 +0000, Daniel Shahaf wrote:
>Bart Schaefer wrote on Sun, Dec 15, 2019 at 22:37:53 -0800:
>>On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
>>>
>>> workers/44007 (also in this thread):
>>>
>>>> trap 'printf $1; exit; printf $2' USR1
>>>> fn() {
>>>>          printf 1
>>>>          kill -s usr1 $$
>>>>          printf 2
>>>> }
>>>> printf 0
>>>> fn A B
>>>> printf 3
>>> 
>>> Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.
.....
> - exit_pending is set
>
> - The remainder of the trap is skipped (I assume that's because
> bin_break() set retflag?)
>
> - The remainder of fn() is executed

I guess this is where the problem is.  We should presumably continue to
skip through the function, too.  We may be reesetting "breaks" when we
shouldn't be, for example, or failing to propagate some other condition,
perhaps just the effect of the exit_pending.

>> The trouble is that we also have to treat differently the cases of the
>> trap having been set inside the function, and the trap existing
>> outside the function when the function is called.
>
> Why?

I'm not sure that's necessarily ture of USR1 traps --- I can't think of
why the *effect* would be different, even if the trap is local to the
function --- but one of our big headaches is EXIT traps which in zsh are
triggered at the end of the enclosing context.  (An exit in an exit
trap is even worse).  Luckily, we don't have to deal with exit traps
in this case, but we do have to be sure we're not doing anything that
will have a knock-on effect there.

pws


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-17 20:29                       ` Peter Stephenson
@ 2019-12-18  0:31                         ` Daniel Shahaf
  2019-12-31  2:03                           ` Daniel Shahaf
  0 siblings, 1 reply; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-18  0:31 UTC (permalink / raw)
  To: Peter Stephenson, zsh-workers

Peter Stephenson wrote on Tue, 17 Dec 2019 20:29 +00:00:
> On Tue, 2019-12-17 at 07:31 +0000, Daniel Shahaf wrote:
> >Bart Schaefer wrote on Sun, Dec 15, 2019 at 22:37:53 -0800:
> >>On Sun, Dec 15, 2019 at 9:25 PM Daniel Shahaf <d.s@daniel.shahaf.name> wrote:
> >>>
> >>> workers/44007 (also in this thread):
> >>>
> >>>> trap 'printf $1; exit; printf $2' USR1
> >>>> fn() {
> >>>>          printf 1
> >>>>          kill -s usr1 $$
> >>>>          printf 2
> >>>> }
> >>>> printf 0
> >>>> fn A B
> >>>> printf 3
> >>> 
> >>> Here, Martijn was saying that zsh should print 01A but in fact prints 01A2.
> .....
> > - exit_pending is set
> >
> > - The remainder of the trap is skipped (I assume that's because
> > bin_break() set retflag?)
> >
> > - The remainder of fn() is executed
> 
> I guess this is where the problem is.  We should presumably continue to
> skip through the function, too.  We may be reesetting "breaks" when we
> shouldn't be, for example, or failing to propagate some other condition,
> perhaps just the effect of the exit_pending.

Okay, I'll see if I can find time to trace this further.  Might cheat and do
.
    -int retflag;
    +int retflag_real;
    +#define retflag (retflag_real || exit_pending)
    (& have all the places that assign to retflag assign to retflag_real instead)
.
to smoke test if retflag being reset really is the problem.

About 'breaks', it's possible that we overwrite it, too, but in
this example 'loops' and 'breaks' should both be zero so that won't
be visible.

> >> The trouble is that we also have to treat differently the cases of the
> >> trap having been set inside the function, and the trap existing
> >> outside the function when the function is called.
> >
> > Why?
> 
> I'm not sure that's necessarily ture of USR1 traps --- I can't think of
> why the *effect* would be different, even if the trap is local to the
> function --- but one of our big headaches is EXIT traps which in zsh are
> triggered at the end of the enclosing context.  (An exit in an exit
> trap is even worse).  Luckily, we don't have to deal with exit traps
> in this case, but we do have to be sure we're not doing anything that
> will have a knock-on effect there.

I'll be happy if there's a 5.8.1 but no 5.8.2. :)

Cheers,

Daniel

^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-18  0:31                         ` Daniel Shahaf
@ 2019-12-31  2:03                           ` Daniel Shahaf
  2019-12-31 13:46                             ` Daniel Shahaf
  0 siblings, 1 reply; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-31  2:03 UTC (permalink / raw)
  To: zsh-workers; +Cc: Martijn Dekker

[-- Attachment #1: Type: text/plain, Size: 77 bytes --]

I'm attaching an expected-to-fail regression test for 44007.

Cheers,

Daniel

[-- Warning: decoded text below may be mangled --]
[-- Attachment #2: 0001-In-the-test-suite-allow-test-cases-to-be-marked-as-e.patch --]
[-- Type: text/x-patch; name="0001-In-the-test-suite-allow-test-cases-to-be-marked-as-e.patch", Size: 4569 bytes --]

From b49f856b21eba759e503164a97b61343b9cbbf34 Mon Sep 17 00:00:00 2001
From: Daniel Shahaf <danielsh@apache.org>
Date: Tue, 31 Dec 2019 01:52:03 +0000
Subject: [PATCH 1/2] In the test suite, allow test cases to be marked as
 expected to fail.

See next commit for a use-case.
---
 Test/B01cd.ztst      |  4 +++-
 Test/ztst.zsh        | 30 ++++++++++++++++++++++++++++--
 Util/ztst-syntax.vim |  2 +-
 3 files changed, 32 insertions(+), 4 deletions(-)

diff --git a/Test/B01cd.ztst b/Test/B01cd.ztst
index f79e18f..977cbdf 100644
--- a/Test/B01cd.ztst
+++ b/Test/B01cd.ztst
@@ -70,11 +70,13 @@
 # the expected status returned by the code when run, or - if it is
 # irrelevant.  An optional set of single-letter flags follows the status
 # or -.  The following are understood:
-#  . d   Don't diff stdout against the expected stdout.
+#  . d  Don't diff stdout against the expected stdout.
 #   D   Don't diff stderr against the expected stderr.
 #   q   All redirection lines given in the test script (not the lines
 #       actually produced by the test) are subject to ordinary quoted shell
 #       expansion (i.e. not globbing).
+#   f   Test is expected to fail. If the test's exit code, stdout, and stderr
+#       match, report a problem; otherwise, carry on to the next test case.
 # This can be followed by a `:' and a message describing the
 # test, which will be printed if the test fails, along with a
 # description of the failure that occurred.  The `:' and message are
diff --git a/Test/ztst.zsh b/Test/ztst.zsh
index a4c6252..0c71f9d 100755
--- a/Test/ztst.zsh
+++ b/Test/ztst.zsh
@@ -366,6 +366,7 @@ ZTST_test() {
   local last match mbegin mend found substlines
   local diff_out diff_err
   local ZTST_skip
+  integer expected_to_fail
 
   while true; do
     rm -f $ZTST_in $ZTST_out $ZTST_err
@@ -460,8 +461,21 @@ $ZTST_curline"
 	fi
       fi
 
+      if [[ $ZTST_flags = *f* ]]; then
+        expected_to_fail=1
+        ZTST_xfail_diff() { ZTST_diff "$@" > /dev/null }
+        ZTST_diff=ZTST_xfail_diff
+      else
+        expected_to_fail=0
+        ZTST_diff=ZTST_diff
+      fi
+
       # First check we got the right status, if specified.
       if [[ $ZTST_xstatus != - && $ZTST_xstatus != $ZTST_status ]]; then
+        if (( expected_to_fail )); then
+          ZTST_verbose 1 "Test failed, as expected."
+          continue
+        fi
 	ZTST_testfailed "bad status $ZTST_status, expected $ZTST_xstatus from:
 $ZTST_code${$(<$ZTST_terr):+
 Error output:
@@ -480,7 +494,11 @@ $(<$ZTST_terr)"
 	rm -rf $ZTST_out
 	print -r -- "${(e)substlines}" >$ZTST_out
       fi
-      if [[ $ZTST_flags != *d* ]] && ! ZTST_diff $diff_out -u $ZTST_out $ZTST_tout; then
+      if [[ $ZTST_flags != *d* ]] && ! $ZTST_diff $diff_out -u $ZTST_out $ZTST_tout; then
+        if (( expected_to_fail )); then
+          ZTST_verbose 1 "Test failed, as expected."
+          continue
+        fi
 	ZTST_testfailed "output differs from expected as shown above for:
 $ZTST_code${$(<$ZTST_terr):+
 Error output:
@@ -488,15 +506,23 @@ $(<$ZTST_terr)}"
 	return 1
       fi
       if [[ $ZTST_flags = *q* && -s $ZTST_err ]]; then
+        if (( expected_to_fail )); then
+          ZTST_verbose 1 "Test failed, as expected."
+          continue
+        fi
 	substlines="$(<$ZTST_err)"
 	rm -rf $ZTST_err
 	print -r -- "${(e)substlines}" >$ZTST_err
       fi
-      if [[ $ZTST_flags != *D* ]] && ! ZTST_diff $diff_err -u $ZTST_err $ZTST_terr; then
+      if [[ $ZTST_flags != *D* ]] && ! $ZTST_diff $diff_err -u $ZTST_err $ZTST_terr; then
 	ZTST_testfailed "error output differs from expected as shown above for:
 $ZTST_code"
 	return 1
       fi
+      if (( expected_to_fail )); then
+        ZTST_testfailed "test was expected to fail, but passed."
+        return 1
+      fi
     fi
     ZTST_verbose 1 "Test successful."
     [[ -n $last ]] && break
diff --git a/Util/ztst-syntax.vim b/Util/ztst-syntax.vim
index 8d8becf..f0c82d7 100644
--- a/Util/ztst-syntax.vim
+++ b/Util/ztst-syntax.vim
@@ -28,7 +28,7 @@ syn include @zsh                   syntax/zsh.vim
 syn match  ztstPayload             /^\s\+\zs.*/ contains=@zsh
 
 syn match  ztstExitCode            /^\d\+\|^-/                nextgroup=ztstFlags
-syn match  ztstFlags               /[.dDq]*:/       contained nextgroup=ztstTestName contains=ztstColon
+syn match  ztstFlags               /[.dDqf]*:/      contained nextgroup=ztstTestName contains=ztstColon
 syn match  ztstColon               /:/              contained
 syn region ztstTestName            start=// end=/$/ contained 
 
-- 
2.20.1


[-- Warning: decoded text below may be mangled --]
[-- Attachment #3: 0002-Add-an-expected-to-fail-test-for-workers-44007.patch --]
[-- Type: text/x-patch; name="0002-Add-an-expected-to-fail-test-for-workers-44007.patch", Size: 1860 bytes --]

From 87b1f05911e3369897307f81c04b8ed4db240d6e Mon Sep 17 00:00:00 2001
From: Daniel Shahaf <danielsh@apache.org>
Date: Tue, 31 Dec 2019 01:52:32 +0000
Subject: [PATCH 2/2] Add an expected-to-fail test for workers/44007.

---
 Etc/BUGS           | 14 ++------------
 Test/C03traps.ztst | 15 +++++++++++++++
 2 files changed, 17 insertions(+), 12 deletions(-)

diff --git a/Etc/BUGS b/Etc/BUGS
index 3fbe818..8112299 100644
--- a/Etc/BUGS
+++ b/Etc/BUGS
@@ -26,16 +26,6 @@ skipped when STTY=... is set for that command
 41203 and others: Make it easier to maintain C modules out of tree.
 (May require defining a stable API for modules, see 41254)
 ------------------------------------------------------------------------
-44007 - Martijn - exit in trap executes rest of function (prints "fn2")
-[[[
-trap 'echo $1; exit; echo $2' USR1
-fn() {
-  echo fn1
-  kill -USR1 $$
-  echo fn2
-}
-echo out1
-fn trap1 trap2
-echo out2
-]]]
+44007 - Martijn - exit in trap executes rest of function
+See test case in Test/C03traps.ztst.
 ------------------------------------------------------------------------
diff --git a/Test/C03traps.ztst b/Test/C03traps.ztst
index 4aebd92..8fdd780 100644
--- a/Test/C03traps.ztst
+++ b/Test/C03traps.ztst
@@ -881,6 +881,21 @@ F:Must be tested with a top-level script rather than source or function
   $ZTST_testdir/../Src/zsh -f <<<'fn() { exit 0; }; trap fn EXIT; false'
 0:Explicit exit status overrides implicit: script-like code path
 
+ $ZTST_testdir/../Src/zsh -f <<<$'
+ trap \'printf $1; exit; printf $2\' USR1
+ fn() {
+         printf fn1
+         kill -s USR1 $$
+         printf fn2
+ }
+ printf out1
+ fn trap1 trap2
+ printf out2
+ '
+0f:(workers/44007) function execution continues after 'exit' in trap
+>out1fn1trap1
+# As of 5.7.1-test-2, the output was "out1fn1trap1fn2".
+
 %clean
 
   rm -f TRAPEXIT
-- 
2.20.1


^ permalink raw reply	[flat|nested] 39+ messages in thread

* Re: Bug with traps and exit
  2019-12-31  2:03                           ` Daniel Shahaf
@ 2019-12-31 13:46                             ` Daniel Shahaf
  0 siblings, 0 replies; 39+ messages in thread
From: Daniel Shahaf @ 2019-12-31 13:46 UTC (permalink / raw)
  To: zsh-workers

Daniel Shahaf wrote on Tue, 31 Dec 2019 02:03 +00:00:
> Attachments:
> * 0001-In-the-test-suite-allow-test-cases-to-be-marked-as-e.patch

The XFAIL handling for the stderr comparison was put in the wrong
place.  Will fix.

> * 0002-Add-an-expected-to-fail-test-for-workers-44007.patch

The expected exit code is zero.  I think that's correct but I'll change
the expectation to "-" (don't check the exit code) before committing, to
maximize the chance of the test being flagged as XPASS (= expected to
fail, but passed) if we stop printing "fn2".

Cheers,

Daniel
[sorry, I can't easily do an inline quoted reply from here]

^ permalink raw reply	[flat|nested] 39+ messages in thread

end of thread, back to index

Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2019-01-05  7:08 Test release: 5.6.2-test-3 dana
2019-01-05 17:49 ` Peter Stephenson
2019-01-05 18:42   ` dana
2019-01-05 20:58   ` Martijn Dekker
2019-01-05 21:55     ` Daniel Shahaf
2019-01-06  2:37 ` Axel Beckert
2019-01-06 15:12 ` Jun T.
2019-01-06 16:37   ` dana
2019-01-06 16:43     ` Daniel Shahaf
2019-01-06 16:56       ` dana
2019-01-06 21:34     ` Daniel Tameling
2019-01-07  3:25     ` Jun T
2019-01-07  7:02       ` dana
2019-01-21 12:54 ` ETA for zsh 5.7? (was: Test release: 5.6.2-test-3) Axel Beckert
2019-01-21 14:26   ` Peter Stephenson
2019-01-21 19:14     ` Mikael Magnusson
2019-01-21 19:32       ` Mikael Magnusson
2019-01-21 21:56         ` Sebastian Gniazdowski
2019-01-22  9:29           ` Peter Stephenson
2019-01-21 19:32       ` Mikael Magnusson
2019-01-21 23:00 ` Bug with traps and exit Martijn Dekker
2019-11-24  5:54   ` Martijn Dekker
2019-11-25 16:42     ` Sebastian Gniazdowski
2019-12-10 19:23     ` Martijn Dekker
2019-12-11  2:40       ` Daniel Shahaf
2019-12-12 10:14       ` Peter Stephenson
2019-12-13 14:26         ` Martijn Dekker
2019-12-13 14:49           ` Peter Stephenson
2019-12-14 11:28             ` Daniel Shahaf
2019-12-15 18:59               ` Peter Stephenson
2019-12-16  5:24                 ` Daniel Shahaf
2019-12-16  6:37                   ` Bart Schaefer
2019-12-17  7:31                     ` Daniel Shahaf
2019-12-17 20:29                       ` Peter Stephenson
2019-12-18  0:31                         ` Daniel Shahaf
2019-12-31  2:03                           ` Daniel Shahaf
2019-12-31 13:46                             ` Daniel Shahaf
2019-12-16 10:09                   ` Peter Stephenson
2019-12-16  5:27     ` The bug from workers/44922 (was: " Daniel Shahaf

zsh-workers

Archives are clonable: git clone --mirror http://inbox.vuxu.org/zsh-workers

Example config snippet for mirrors

Newsgroup available over NNTP:
	nntp://inbox.vuxu.org/vuxu.archive.zsh.workers


AGPL code for this site: git clone https://public-inbox.org/public-inbox.git