global zlogout

global zlogout

[Carlos Carvalho]

I've just grabed Zoltan's release, after MANY trials :-( Without
ncftp's nifty appending get I wouldn't have managed...

I noticed that the global zlogout is not sourced if NORCS is set. I
think this is wrong, it should always be executed, just like the
global zshenv.

Carlos

Re: global zlogout

[Zoltan Hidvegi]

> 
> I've just grabed Zoltan's release, after MANY trials :-( Without
> ncftp's nifty appending get I wouldn't have managed...
> 
> I noticed that the global zlogout is not sourced if NORCS is set. I
> think this is wrong, it should always be executed, just like the
> global zshenv.

I think that the same holds for the vanilla beta10.  zlogout should be
executed if zlogin (or zprofile) executed on login.  Currently zlogout
executed only on exit from login shells if NO_RCS is not set.

Zoltan

global zlogout and .zlogout

[Richard Coleman]

> > I've just grabed Zoltan's release, after MANY trials :-( Without
> > ncftp's nifty appending get I wouldn't have managed...
> > 
> > I noticed that the global zlogout is not sourced if NORCS is set. I
> > think this is wrong, it should always be executed, just like the
> > global zshenv.
> 
> I think that the same holds for the vanilla beta10.  zlogout should be
> executed if zlogin (or zprofile) executed on login.  Currently zlogout
> executed only on exit from login shells if NO_RCS is not set.

I'm going back through old mail, so I was looking at this problem
again.  I'm want to know what everyone this is the most usual
behavoir.

Currently in the zsh baseline, the global zlogout is only
executed for a login shell if NO_RCS is not set and the shell is
interactive.  This is definitely wrong.  My first reaction is to have
the global zlogout always executed (regardless of NO_RCS) when a login
shell is exiting.  This is the way the global zlogin file is handled.

Also, I now realize another potential problem.  When the init scripts
are sourced when the shell is starting up, there is a hack (setting the
sourcelevel to 32768) that prevents an error in these scripts from tripping
ERREXIT.  This same should probably apply to the global zlogout and .zlogout.

What does everyone think?

rc

Re: global zlogout and .zlogout

[Carlos Carvalho]

Richard Coleman (coleman@math.gatech.edu) wrote on 18 October 1995 01:59:

 >> > I've just grabed Zoltan's release, after MANY trials :-( Without
 >> > ncftp's nifty appending get I wouldn't have managed...
 >> > 
 >> > I noticed that the global zlogout is not sourced if NORCS is set. I
 >> > think this is wrong, it should always be executed, just like the
 >> > global zshenv.

 >I'm want to know what everyone this is the most usual behavoir.

Is this a local dialect? :-)

 >Currently in the zsh baseline, the global zlogout is only
 >executed for a login shell if NO_RCS is not set and the shell is
 >interactive.  This is definitely wrong.  My first reaction is to have
 >the global zlogout always executed (regardless of NO_RCS) when a login
 >shell is exiting.

This is exactly what I said above.

 >This is the way the global zlogin file is handled.

No, because you can set NO_RCS in your .zshenv. That's why I say above
"just like the global zshenv", which is the only one that's always
executed.

Anyway, we agree on zlogout.

 >Also, I now realize another potential problem.  When the init scripts
 >are sourced when the shell is starting up, there is a hack (setting the
 >sourcelevel to 32768) that prevents an error in these scripts from tripping
 >ERREXIT.  This same should probably apply to the global zlogout and .zlogout.

Only to the global one. The user's one is his problem.

Carlos

Re: global zlogout and .zlogout

[Richard Coleman]

>  >> > I noticed that the global zlogout is not sourced if NORCS is set. I
>  >> > think this is wrong, it should always be executed, just like the
>  >> > global zshenv.
> 
>  >I'm want to know what everyone this is the most usual behavoir.
> 
> Is this a local dialect? :-)

That's what I get for writing e-mail at 2am.  I meant to say I want to know
what everyone thinks is the preferred behavior.

>  >Currently in the zsh baseline, the global zlogout is only
>  >executed for a login shell if NO_RCS is not set and the shell is
>  >interactive.  This is definitely wrong.  My first reaction is to have
>  >the global zlogout always executed (regardless of NO_RCS) when a login
>  >shell is exiting.
> 
> This is exactly what I said above.

Yes, I know.  Just repeating it for emphasis (I like to hear myself talk :-)

>  >This is the way the global zlogin file is handled.
> 
> No, because you can set NO_RCS in your .zshenv. That's why I say above
> "just like the global zshenv", which is the only one that's always
> executed.

I meant to say the global zshenv, not the global zlogin.  But the more I
think about it, I'm no longer happy with this idea.  There should be
someway to suppress the sourcing of the global zlogout.  But you don't
want users to be able to do this.  I believe it was Zoltan who mentioned
sourcing the global zlogout only if the global zlogin was sourced.  That is
easy to do.  Before anything is changed, I would like to know for what
purposes are people using the global zlogout file.

>  >Also, I now realize another potential problem.  When the init scripts
>  >are sourced when the shell is starting up, there is a hack (setting the
>  >sourcelevel to 32768) that prevents an error in these scripts from tripping
>  >ERREXIT.  This same should probably apply to the global zlogout and .zlogout.
> 
> Only to the global one. The user's one is his problem.

ERREXIT is suppressed for all the init script (both global and personal).
Seems like the same should be the case for the global zlogout and .zlogout.

rc

Re: global zlogout and .zlogout

[Zoltan Hidvegi]

> I meant to say the global zshenv, not the global zlogin.  But the more I
> think about it, I'm no longer happy with this idea.  There should be
> someway to suppress the sourcing of the global zlogout.  But you don't
> want users to be able to do this.  I believe it was Zoltan who mentioned
> sourcing the global zlogout only if the global zlogin was sourced.  That is
> easy to do.  Before anything is changed, I would like to know for what
> purposes are people using the global zlogout file.

The is no way to prevent the user to avoid the global zlogout.  Anyone can
exit the shell with kill -9 $$.  One can even put kill -9 $$ into her .zlogout
which is executed before the global zlogout.  That's why I think that we can
use no_rcs to decide whether zlogout should be executed or not.

> >  >Also, I now realize another potential problem.  When the init scripts
> >  >are sourced when the shell is starting up, there is a hack (setting the
> >  >sourcelevel to 32768) that prevents an error in these scripts from tripping
> >  >ERREXIT.  This same should probably apply to the global zlogout and .zlogout.
> > 
> > Only to the global one. The user's one is his problem.
> 
> ERREXIT is suppressed for all the init script (both global and personal).
> Seems like the same should be the case for the global zlogout and .zlogout.

That's right.  But this is because an errexit during the init scripts may lock
out a user from her shell.  An init script should not exit to give a chance to
the user to correct her mistake.  In logout scripts there is no such danger I
think but as you said it depends on the function of the global zlogout script.

But there are other things which can be changed here.  Currently the order of
sourcing in a login shell is:

GLOBAL_ZSHENV, .zshenv, GLOBAL_ZPROFILE, .zprofile, GLOBAL_ZSHRC, .zshrc,
GLOBAL_ZLOGIN, .zlogin

This means that a clever user can avoid every global init scripts except the
GLOBAL_ZSHENV.  So everything which must be executed should be put here.  But
we must keep it small and fast since it is executed on all zsh invocations.
One solution may be to execute all of the user init scripts after the global
ones.   The global zlogin can be an exception here since zprofile has similar
functions.

Cheers,
  Zoltan

global zlogout

[Carlos Carvalho]

I forgot to say that it's only sourced if job control is enabled,
which I think is also incorrect.

Carlos