4.3.11 TRAPEXIT() on cygwin

4.3.11 TRAPEXIT() on cygwin

[Anthony Heading]

Hello,

This seems to be a bug with the new packaged build of zsh 4.3.11 on
cygwin?

Anthony


=> uname -a
CYGWIN_NT-6.1-WOW64 W3GRNMN1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686
Cygwin
 
---
=> echo $ZSH_VERSION
4.3.10
=> TRAPEXIT() { echo hello >&2 }
=> x=$(ls)
=>

---
=> echo $ZSH_VERSION
4.3.11
=> TRAPEXIT() { echo hello >&2 }
=> x=$(ls)
hello
=>

Re: 4.3.11 TRAPEXIT() on cygwin

[Mikael Magnusson]

On 11 January 2011 01:16, Anthony Heading <anthony@ajrh.net> wrote:
> Hello,
>
> This seems to be a bug with the new packaged build of zsh 4.3.11 on
> cygwin?
>
> Anthony
>
>
> => uname -a
> CYGWIN_NT-6.1-WOW64 W3GRNMN1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686
> Cygwin
>
> ---
> => echo $ZSH_VERSION
> 4.3.10
> => TRAPEXIT() { echo hello >&2 }
> => x=$(ls)
> =>
>
> ---
> => echo $ZSH_VERSION
> 4.3.11
> => TRAPEXIT() { echo hello >&2 }
> => x=$(ls)
> hello
> =>

See 27947: http://www.zsh.org/mla/workers/2010/msg00399.html

-- 
Mikael Magnusson

Re: 4.3.11 TRAPEXIT() on cygwin

[Anthony Heading]

Errm,  yes I remember seeing that discussion, but it was basically about
pipelines,  traps set within subshells, and implicit vs explicit exits.

I don't believe this is the same thing.

Anthony


On Tue, 11 Jan 2011 01:46 +0100, "Mikael Magnusson" <mikachu@gmail.com>
wrote:
> On 11 January 2011 01:16, Anthony Heading <anthony@ajrh.net> wrote:
> > Hello,
> >
> > This seems to be a bug with the new packaged build of zsh 4.3.11 on
> > cygwin?
> >
> > Anthony
> >
> >
> > => uname -a
> > CYGWIN_NT-6.1-WOW64 W3GRNMN1 1.7.7(0.230/5/3) 2010-08-31 09:58 i686
> > Cygwin
> >
> > ---
> > => echo $ZSH_VERSION
> > 4.3.10
> > => TRAPEXIT() { echo hello >&2 }
> > => x=$(ls)
> > =>
> >
> > ---
> > => echo $ZSH_VERSION
> > 4.3.11
> > => TRAPEXIT() { echo hello >&2 }
> > => x=$(ls)
> > hello
> > =>
> 
> See 27947: http://www.zsh.org/mla/workers/2010/msg00399.html
> 
> -- 
> Mikael Magnusson
> 

Re: 4.3.11 TRAPEXIT() on cygwin

[Mikael Magnusson]

On 11 January 2011 02:46, Anthony Heading <anthony@ajrh.net> wrote:
> Errm,  yes I remember seeing that discussion, but it was basically about
> pipelines,  traps set within subshells, and implicit vs explicit exits.
>
> I don't believe this is the same thing.
>
> Anthony

Please don't top post.

>From the referenced mail:
> Other cases I missed before include anything along the lines of:
>
> echo $( trap 'echo exiting' EXIT)
>
> or similar substitutions.  That's quite clearly a subshell entering to
> the same extent a ( ... ) is.

How is that different from what you wrote?
Which would be quoted here for reference if you hadn't top posted. ;)

-- 
Mikael Magnusson

Re: 4.3.11 TRAPEXIT() on cygwin

[Anthony Heading]

On Tue, 11 Jan 2011 02:50 +0100, "Mikael Magnusson" <mikachu@gmail.com>
wrote:
> > echo $( trap 'echo exiting' EXIT)
> >
> > or similar substitutions.  That's quite clearly a subshell entering to
> > the same extent a ( ... ) is.
> 
> How is that different from what you wrote?

Well, the examples you quote are traps set within a subshell, which may
or may not propagate higher.

My problem is that the subshell is inheriting the parent trap action.

That seems obviously different, and POSIX seems pretty clear:

    When a subshell is entered, traps that are not being ignored shall
    be set to the default actions, except in the case of a command
    substitution containing only a single trap command, when the traps
    need not be altered.

Anthony

Re: 4.3.11 TRAPEXIT() on cygwin

[Mikael Magnusson]

On 11 January 2011 03:54, Anthony Heading <anthony@ajrh.net> wrote:
> On Tue, 11 Jan 2011 02:50 +0100, "Mikael Magnusson" <mikachu@gmail.com>
> wrote:
>> > echo $( trap 'echo exiting' EXIT)
>> >
>> > or similar substitutions.  That's quite clearly a subshell entering to
>> > the same extent a ( ... ) is.
>>
>> How is that different from what you wrote?
>
> Well, the examples you quote are traps set within a subshell, which may
> or may not propagate higher.
>
> My problem is that the subshell is inheriting the parent trap action.
>
> That seems obviously different, and POSIX seems pretty clear:
>
>    When a subshell is entered, traps that are not being ignored shall
>    be set to the default actions, except in the case of a command
>    substitution containing only a single trap command, when the traps
>    need not be altered.

Ah, the manpage says this
       ( list )
              Execute  list  in a subshell.  Traps set by the trap
builtin are reset
              to their default values while executing list.

and it is true:
% trap 'echo hello >&2' EXIT
% a=$(ls)
% TRAPEXIT() { echo function hello >&2 }
% a=$(ls)
function hello

-- 
Mikael Magnusson

Re: 4.3.11 TRAPEXIT() on cygwin

[Mikael Magnusson]

On 11 January 2011 04:25, Mikael Magnusson <mikachu@gmail.com> wrote:
>>    When a subshell is entered, traps that are not being ignored shall
>>    be set to the default actions, except in the case of a command
>>    substitution containing only a single trap command, when the traps
>>    need not be altered.
>
> Ah, the manpage says this
>       ( list )
>              Execute  list  in a subshell.  Traps set by the trap
> builtin are reset
>              to their default values while executing list.
>
> and it is true:
> % trap 'echo hello >&2' EXIT
> % a=$(ls)
> % TRAPEXIT() { echo function hello >&2 }
> % a=$(ls)
> function hello

One might take issue with this statement in the manpage though,

The  functions  beginning  `TRAP'  may alternatively be defined with the trap
builtin:  this may be preferable for some uses, as they are then run  in  the
environment  of  the calling process, rather than in their own function envi‐
ronment.  Apart from the difference in calling procedure and  the  fact  that
the function form appears in lists of functions, the forms

              TRAPNAL() {
               # code
              }

       and

              trap '
               # code
              ' NAL

       are equivalent.


-- 
Mikael Magnusson

Re: 4.3.11 TRAPEXIT() on cygwin

[Peter Stephenson]

This tries to summarize the differences I know about.

Index: Doc/Zsh/func.yo
===================================================================
RCS file: /cvsroot/zsh/zsh/Doc/Zsh/func.yo,v
retrieving revision 1.25
diff -p -u -r1.25 func.yo
--- Doc/Zsh/func.yo	18 Feb 2009 17:17:27 -0000	1.25
+++ Doc/Zsh/func.yo	11 Jan 2011 09:34:58 -0000
@@ -348,19 +348,28 @@ enditem()
 
 findex(trap, use of)
 The functions beginning `tt(TRAP)' may alternatively be defined with the
-tt(trap) builtin:  this may be preferable for some uses, as they are then
-run in the environment of the calling process, rather than in their own
-function environment.  Apart from the difference in calling procedure and
-the fact that the function form appears in lists of functions, the forms
+tt(trap) builtin:  this may be preferable for some uses.  The forms
 
 example(TRAPNAL+LPAR()RPAR() { 
  # code
 })
 
-and
+('function traps') and
 
 example(trap '
  # code
 ' NAL)
 
-are equivalent.
+('list traps') are equivalent in most ways, the exceptions being the
+following:
+
+startitemize()
+itemiz(Function traps have all the properties of normal functions,
+appearing in the list of functions and being called with their own
+function context rather than the context where the trap was triggered.)
+itemiz(The return status from function traps is special, whereas a return
+from a list trap causes the surrounding context to return with the given
+status.)
+itemiz(Function traps are not reset within subshells, in accordance with
+zsh behaviour; list traps are reset, in accordance with POSIX behaviour.)
+enditemize()

-- 
Peter Stephenson <pws@csr.com>            Software Engineer
Tel: +44 (0)1223 692070                   Cambridge Silicon Radio Limited
Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, UK


Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom

Re: 4.3.11 TRAPEXIT() on cygwin

[Bart Schaefer]

On Jan 11,  9:38am, Peter Stephenson wrote:
}
} This tries to summarize the differences I know about.

The other thing worth mentioning is that you can't have both of them
at once.  If you set a list trap, it supplants the function trap in
the same scope, and vice-versa.

Also you can't restore the previously scoped trap by removing the new
one -- "unfunction TRAPEXIT" deletes the trap entirely.

This, however, might be a bug:

----
% trap 'print list' EXIT; unfunction TRAPEXIT; print exiting; exit
unfunction: no such hash table element: TRAPEXIT
exiting
----

Removing the TRAPEXIT function deletes the EXIT list trap even if there
is no TRAPEXIT function.