Re: fc (history) requires zsh is interactive? Why can't interactive toggled?

["Rocky Bernstein" <rocky.bernstein@xxxxxxxxx>]

On Mon, Sep 22, 2008 at 8:06 AM, Peter Stephenson <pws@xxxxxxx> wrote:
>
> On Sun, 21 Sep 2008 20:37:13 -0400
> "Rocky Bernstein" <rocky.bernstein@xxxxxxxxx> wrote:
> > When I run fc -l (history) from a zsh script that isn't interactive I get
> > the message
> >  not interactive shell
> >
> > Why is it that fc -l needs an interactive shell? One can put entries in the
> > history and one can use vared to cycle through them, so what is it about an
> > interactive shell that is important here?
>
> When non-interactive, history isn't loaded at the start and needs loading
> for the command you're running or by special interaction.

Right, but a command processors has to know to do that dance. It's in
Functions/Misc/zcalc, and in sticky-note which were suggested as
examples of command processors.

> So "fc -l"
> hasn't been very useful and the error message tends to be more helpful than
> simply doing nothing because you're in a non-interactive shell with, the
> vast majority of the time, no history.

The problem is that an error message which prevents functioning of a
command should only be given when there *is* an error, not in
anticipation of a situation which sometimes is an error. ;-) If there
is history in the history list, then fc -l should show it, and if
there is no history it could either report no history and/or suggest
that not being in an interactive mode might be one (but not the only)
reason why.

> There's no basic reason why it
> shouldn't work if history works elsewhere.

Could this be changed please?

>
> > Related to this, why can't an interactive shell be toggled?
>
> No basic reason, again, but it's a complicated support nightmare making
> things changeable at run time rather than, as now, once when the shell
> starts up.  For example, turning on job control in the middle of a
> hitherto non-interactive shell changes the nature of what's stored in the
> job table.  All that could in principle be fixed, it's just work, and
> likely to be fairly low priority since we have very little effort
> available for new large-scale tasks, particularly those which are
> liable to introduce bugs.

Ok. I think this needs to be done one step at a time. If one can issue
instructions to turn on various pieces that were disabled by virtue of
being non-interactive (like setting/reading history files),  then
changing all of this in one shot isn't all that important.

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