trap ERR

trap ERR

[Ray Andrews]

I haven't played around with traps much, but trying this in a script:

    trap 'echo ERROR at $0 $LINENO; return' ERR

    cp file1/tmp
    cp no_such_file/tmp
    cp file2/tmp

    # trap '' ERR

I want to return with the message at any error, and it does return, but 
it seems that the trap remains in effect which puzzles me since when a 
script quits, I expect things to be returned to stock, no?  The 
commented line kills the trap fine, but of course if I return at the 
first error, it's never executed.

Also, I'd expect to 'exit' a script, but it ends up killing the whole 
terminal.  I'm used to using 'return' but now that I stop to think about 
it, that should be wrong, no?

Re: trap ERR

[Ray Andrews]

On 20/02/17 10:08 PM, Ray Andrews wrote:
> I haven't played around with traps much, but trying this in a script:
>
>    trap 'echo ERROR at $0 $LINENO; return' ERR
>
>    cp file1/tmp
>    cp no_such_file/tmp
>    cp file2/tmp
>
>    # trap '' ERR
>
> I want to return with the message at any error, and it does return, 
> but it seems that the trap remains in effect which puzzles me since 
> when a script quits, I expect things to be returned to stock, no?  The 
> commented line kills the trap fine, but of course if I return at the 
> first error, it's never executed.
>
> Also, I'd expect to 'exit' a script, but it ends up killing the whole 
> terminal.  I'm used to using 'return' but now that I stop to think 
> about it, that should be wrong, no?

Pardon, that was a moronic question.  I'm so used to sourcing scrips 
that I mostly forget that there is any such thing as executing them and 
I'm sourcing automatically even when I think I'm executing -- I type the 
little dot so fast I don't even notice it.   I don't execute because I 
don't know how to have access to my functions inside an executed 
script.  Can I?  If so, all the above difficulties go away.

>
>
>
>

Re: trap ERR

[Peter Stephenson]

On Tue, 21 Feb 2017 07:52:02 -0800
Ray Andrews <rayandrews@eastlink.ca> wrote:
> On 20/02/17 10:08 PM, Ray Andrews wrote:
> > I haven't played around with traps much, but trying this in a script:
> >
> >    trap 'echo ERROR at $0 $LINENO; return' ERR
> >
> >    cp file1/tmp
> >    cp no_such_file/tmp
> >    cp file2/tmp
> >
> >    # trap '' ERR
> >
> > I want to return with the message at any error, and it does return, 
> > but it seems that the trap remains in effect which puzzles me since 
> > when a script quits, I expect things to be returned to stock, no?  The 
> > commented line kills the trap fine, but of course if I return at the 
> > first error, it's never executed.

[Z]ERR and DEBUG are special.  If you want to stop them you do so
explicitly. You can append '; trap "" ERR' to the trap, if you want.

> > Also, I'd expect to 'exit' a script, but it ends up killing the whole 
> > terminal.  I'm used to using 'return' but now that I stop to think 
> > about it, that should be wrong, no?
> 
> Pardon, that was a moronic question.  I'm so used to sourcing scrips 
> that I mostly forget that there is any such thing as executing them and 
> I'm sourcing automatically even when I think I'm executing -- I type the 
> little dot so fast I don't even notice it.   I don't execute because I 
> don't know how to have access to my functions inside an executed 
> script.  Can I?  If so, all the above difficulties go away.

There's nothing to stop you using $fpath and autoload in a script.

pws

Re: trap ERR

[Ray Andrews]

On 21/02/17 08:41 AM, Peter Stephenson wrote:
> [Z]ERR and DEBUG are special. If you want to stop them you do so
> explicitly. You can append '; trap "" ERR' to the trap, if you want.

Ha, that's just what I'm trying now.  It seems so ... occult ... but it 
seems to work.

> There's nothing to stop you using $fpath and autoload in a script. 

Yabut that requires one function per file IIRC.  I'll chew on it. Thanks 
Peter.

Re: trap ERR

[Bart Schaefer]

On Feb 21,  8:56am, Ray Andrews wrote:
}
} > There's nothing to stop you using $fpath and autoload in a script. 
} 
} Yabut that requires one function per file IIRC.

There's also nothing to stop you putting your functions in ~/.zshenv
so that they're available in every shell that starts up.  It's all
down to dividing things appropriately across your init files to get
the right balance of having components you need without too much
startup overhead (and proper wariness of functions that redefine any
common commands like "ls" etc.).

Re: trap ERR

[Ray Andrews]

On 21/02/17 09:30 AM, Bart Schaefer wrote:
> On Feb 21,  8:56am, Ray Andrews wrote:
> }
> } > There's nothing to stop you using $fpath and autoload in a script.
> }
> } Yabut that requires one function per file IIRC.
>
> There's also nothing to stop you putting your functions in ~/.zshenv
> so that they're available in every shell that starts up.  It's all
> down to dividing things appropriately across your init files to get
> the right balance of having components you need without too much
> startup overhead (and proper wariness of functions that redefine any
> common commands like "ls" etc.).
>
I've been meaning to throw myself at the init stuff again and figure out 
just how to get use out of all those files. At the moment everything is 
in .zshrc.  I don't execute scripts much because they are 'naked', but 
if I put the whole thing in .zshenv are you saying that every script 
will have everything available?  Starting anew shell only takes a 
second, so I'm not worried about the overhead. And it would sure make it 
easier to leave some tasks cleanly, which I take it is the beauty of 
scripts anyway.  Till now I've just tried to work around  that.

Re: trap ERR

[Bart Schaefer]

On Feb 21, 11:57am, Ray Andrews wrote:
}
} I don't execute scripts much because they are 'naked', but if I put
} the whole thing in .zshenv are you saying that every script will have
} everything available?

If the script starts with "#! /bin/zsh -f" (for example), then no, the
-f option turns off .zshenv too; but any scripts that don't use -f will
read ~/.zshenv, whereas only interactive or login shells read the
others (it's rare but possible for a shell to be a login shell yet not
be interactive).

Generally speaking there are going to be some things that you don't
want to have happen in non-interactive shells, so I wouldn't suggest
blindly "mv ~/.zshrc ~/.zshenv" -- and you should be cautious about
e.g. "ssh somehost somecommand" behaving differently because somehost
has stuff in .zshenv.

Re: trap ERR

[Ray Andrews]

On 21/02/17 08:21 PM, Bart Schaefer wrote:
> Generally speaking there are going to be some things that you don't
> want to have happen in non-interactive shells, so I wouldn't suggest
> blindly "mv ~/.zshrc ~/.zshenv" -- and you should be cautious about
> e.g. "ssh somehost somecommand" behaving differently because somehost
> has stuff in .zshenv.
>
I'll play with it. The first time I read about the init scripts, fact is 
I didn't understand the terminology used. I get it now tho.