Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: [beta8] history saved on exec doesn't.
- X-seq: zsh-workers 34
- From: P.Stephenson@xxxxxxxxxxxxx
- To: schaefer@xxxxxxxxxxxxxxxxx
- Subject: Re: [beta8] history saved on exec doesn't.
- Date: Wed, 24 May 95 17:55:35 +0100
- In-reply-to: "schaefer@xxxxxxxxxx"'s message of "Wed, 24 May 95 08:42:39 PDT." <9505240842.ZM19150@xxxxxxxxxxxxxxxxx>
schaefer@xxxxxxxxxx wrote:
> I presume "clever exec stuff" really does mean "clever stuff done at
> time of an `exec' zsh builtin" and *not* "clever stuff done whenever
> any call in the exec(2) family is about to be made". That is, I can't
> believe zsh is now saving history every time any non-builtin command
> is run. Please tell me I'm right.
yep
> Then tell me, if I am right, why process substitution would have caused
> history to be saved in the first place. (I completely agree about never
> doing anything like this in subshells in general.)
This is the new code that allows something like $(cmd) to exec the
last command directly from the shell instead of forking as a shortcut.
Certainly nothing funny should have happened here; that was a bug
which the new patch fixes.
> Next, explain "the SHLVL decrement" a bit; I have scripts that depend on
> knowing whether they were exec'd from a login shell or from a shell
> started via my .xsession, and they presently do it by examining SHLVL.
> If SHLVL is suddenly going to start reverting to 1 when a level-2 shell
> does an exec, my standard login routine is going to end up in an infinite
> loop. (As you can tell, I haven't installed any of these betas yet.)
This was added at popular request to avoid `exec zsh' bumping up
SHLVL, since you can't tell how the new shell started off. It's still
now `correct' in the sense that it counts how many higher level zsh's
are present (arguably it's more consistent than before when it counted
just the number of zsh's which had ever started up in its past, which
is not something you usually want to know), but that will be off by
one from the previous one, so it looks like you've found another
incompatibility. In other words, you'd have to check whether SHLVL
was 0 or 1 instead of 1 or 2. (It does go down to zero like it
should, though; I checked.)
> Finally, please tell me there's some way to shut off all this stuff and
> have an exec just be an exec. At least some way to shut off saving of
> history on exec; I don't know who thinks this is useful, but the last
> N things I typically do before any interactive shell would "exec" are
> either stuff from my .zlogin or commands I wouldn't want to repeat unless
> I were about to do *another* exec, and as such I'd rather the history
> were just left alone. Perhaps one of:
>
> alias exec='SAVEHIST=0 exec'
> alias exec='HISTFILE=/dev/null exec'
>
> (Or do we still have to use "exec HISTFILE=/dev/null"?)
No, this syntax for exec now works (which I didn't realise so I've
only just altered the FAQ), but unfortunately it sets the variable too
late. Errr... and you can't actually alias exec (somebody else fix
this, I'm tired of endlessly fixing bugs). The code you need is
SAVEHIST=0; exec
or perhaps you'd better make that
((SHLVL++, SAVEHIST=0)); exec
(In fact, it looks like the main advantage of your upgrading to a more
recent version of zsh would be that you get to complain about the new
features quicker :-/).
--
Peter Stephenson <P.Stephenson@xxxxxxxxxxxxx> Tel: +44 1792 205678 extn. 4461
WWW: http://python.swan.ac.uk/~pypeters/ Fax: +44 1792 295324
Department of Physics, University of Wales, Swansea,
Singleton Park, Swansea, SA2 8PP, U.K.
Messages sorted by:
Reverse Date,
Date,
Thread,
Author