trap DEBUG should get run beforehand, not afterwards.

trap DEBUG should get run beforehand, not afterwards.

[Rocky Bernstein]

Think for example about whether you'd like to know that 'rm -fr *' is
about to occur or just occurred.

ksh introduced trap DEBUG and bash, and zsh copied it. Both ksh and
bash originally ran after the statement; I guess because that is same
as other traps. However both have switched so that it is run before
the statement.

Alas, it's impossible to contemplate writing any sort of serious
debugger unless  "trap DEBUG" gets run beforehand.

Should I attempt a patch?

Re: trap DEBUG should get run beforehand, not afterwards.

[Peter Stephenson]

"Rocky Bernstein" wrote:
> Think for example about whether you'd like to know that 'rm -fr *' is
> about to occur or just occurred.
> 
> ksh introduced trap DEBUG and bash, and zsh copied it. Both ksh and
> bash originally ran after the statement; I guess because that is same
> as other traps. However both have switched so that it is run before
> the statement.
> 
> Alas, it's impossible to contemplate writing any sort of serious
> debugger unless  "trap DEBUG" gets run beforehand.

Use the option DEBUG_BEFORE_CMD.

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

Re: trap DEBUG should get run beforehand, not afterwards.

[Rocky Bernstein]

Thanks!

A minor quibble is that the default is set in a way that will likely
cause confusion and the learning zsh-specific remedy . Are most of the
zsh defaults set so that they are compatible with ksh88 and bash 2.05a
and before?

If there is someone out there that has a program that requires trap
DEBUG to run afterwards I'd be interested in hearing.

Am having other problems with trap DEBUG and something causing an exit
condition without any sort of error indicating the why the exit is
raised and although I know probably where it is raised, I can't figure
out why it should be raised. However I've not been able to get a
simple example that shows the problem yet.





On Wed, Jul 30, 2008 at 4:23 AM, Peter Stephenson <pws@csr.com> wrote:
> "Rocky Bernstein" wrote:
>> Think for example about whether you'd like to know that 'rm -fr *' is
>> about to occur or just occurred.
>>
>> ksh introduced trap DEBUG and bash, and zsh copied it. Both ksh and
>> bash originally ran after the statement; I guess because that is same
>> as other traps. However both have switched so that it is run before
>> the statement.
>>
>> Alas, it's impossible to contemplate writing any sort of serious
>> debugger unless  "trap DEBUG" gets run beforehand.
>
> Use the option DEBUG_BEFORE_CMD.
>
> --
> Peter Stephenson <pws@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070
>

Re: trap DEBUG should get run beforehand, not afterwards.

[Richard Hartmann]

On Wed, Jul 30, 2008 at 10:23, Peter Stephenson <pws@csr.com> wrote:

> Use the option DEBUG_BEFORE_CMD.

This should probably be referenced in zshmisc, section SPECIAL
FUNCTIONS.

Though I agree that, generally, defaulting to running it in advance
would be better.


Richard

Re: trap DEBUG should get run beforehand, not afterwards.

[Bart Schaefer]

On Jul 30,  9:24am, Rocky Bernstein wrote:
}
} A minor quibble is that the default is set in a way that will likely
} cause confusion and the learning zsh-specific remedy . Are most of the
} zsh defaults set so that they are compatible with ksh88 and bash 2.05a
} and before?

No, they're set so that they are compatible with previous versions of
zsh.  You'll find, as you follow the -workers list more, that we're
very concerned -- a lot more so than most OSS projects nowadays, it
seems to me, but also rightly so in my opinion -- with breaking the
expectations of long-time users.

Re: trap DEBUG should get run beforehand, not afterwards.

[Rocky Bernstein]

On Wed, Jul 30, 2008 at 9:38 AM, Bart Schaefer
<schaefer@brasslantern.com> wrote:
> On Jul 30,  9:24am, Rocky Bernstein wrote:
> }
> } A minor quibble is that the default is set in a way that will likely
> } cause confusion and the learning zsh-specific remedy . Are most of the
> } zsh defaults set so that they are compatible with ksh88 and bash 2.05a
> } and before?
>
> No, they're set so that they are compatible with previous versions of
> zsh.  You'll find, as you follow the -workers list more, that we're
> very concerned -- a lot more so than most OSS projects nowadays, it
> seems to me, but also rightly so in my opinion -- with breaking the
> expectations of long-time users.
>

Sure. I understand. Is there any evidence that this would break any
expectations? That's the other question I asked.