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

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

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 648 bytes --]

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?

Related to this, why can't an interactive shell be toggled? Suppose I run a
non-interactive program and later want to attach to it say for debugging. At
that point, I attach interactive tty and it becomes interactive. So what are
the issues involved in turning a non-interactive program (from zsh's
definition) to an interactive one?

Thanks.

[-- Attachment #2: Type: text/html, Size: 714 bytes --]

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

[Peter Stephenson]

On Sun, 21 Sep 2008 20:37:13 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> 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.  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.  There's no basic reason why it
shouldn't work if history works elsewhere.

> 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.

-- 
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: fc (history) requires zsh is interactive? Why can't interactive toggled?

[Rocky Bernstein]

On Mon, Sep 22, 2008 at 8:06 AM, Peter Stephenson <pws@csr.com> wrote:
>
> On Sun, 21 Sep 2008 20:37:13 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> 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@csr.com>                  Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070

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

[Peter Stephenson]

"Rocky Bernstein" wrote:
> > 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.

Granted that's a perfectly good general rule, but it's not, in this
case, the "real" problem, which, as I've said many times, is that we
simply don't have anything remotely like the effort to implement all
these entirely reasonable things, never did, and probably never shall.
Many errors are simply there because the general case was much more
difficult than making it work the vast majority of the time.

>> There's no basic reason why it
>> shouldn't work if history works elsewhere.
>
>> Could this be changed please?

As you appear to have some test cases, could you please try removing the
lines in builtin.c:bin_fc() that say

    /* fc is only permitted in interactive shells */
    if (!interact) {
	zwarnnam(nam, "not interactive shell");
	return 1;
    }

and seeing what happens?  I suspect some options really don't work in
this case, but without trying it's hard to tell what they are.  If we're
lucky, it may just be we need to catch a few extra test case lower down
like the one you picked up in up_histent().  Otherwise, it'll have to go
on the queue of things I might get around to one day.

Thanks.

-- 
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: fc (history) requires zsh is interactive? Why can't interactive toggled?

[Rocky Bernstein]

[-- Attachment #1: Type: text/plain, Size: 2834 bytes --]

I removed the interact test and played around with fc and don't see
any difference.
The current regression tests which all work fine.

So here's a suggestion that I believe will have little impact on zsh developers.

Attached should be a two-line patch to #ifdef this code out. Apply it.
If people find problems in fc as a result of this change, I'll fix
these. If we get to a release and people for whatever reason feel the
that life was better disallowing fc unless in interactive mode, then
it is a matter of deleting two lines and you have the old behavior.

I will also remove the interactive flag on zshdb as another means of
getting test coverage there with a program that uses fc without
interactive mode set.

And to show good faith in fixing whatever bugs come up, attached is a
test in an new "fc" file for the bug I recently discovered which by
the way has nothing to do with whether or not interactive is set.

On Mon, Sep 22, 2008 at 10:25 AM, Peter Stephenson <pws@csr.com> wrote:
> "Rocky Bernstein" wrote:
>> > 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.
>
> Granted that's a perfectly good general rule, but it's not, in this
> case, the "real" problem, which, as I've said many times, is that we
> simply don't have anything remotely like the effort to implement all
> these entirely reasonable things, never did, and probably never shall.
> Many errors are simply there because the general case was much more
> difficult than making it work the vast majority of the time.
>
>>> There's no basic reason why it
>>> shouldn't work if history works elsewhere.
>>
>>> Could this be changed please?
>
> As you appear to have some test cases, could you please try removing the
> lines in builtin.c:bin_fc() that say
>
>    /* fc is only permitted in interactive shells */
>    if (!interact) {
>        zwarnnam(nam, "not interactive shell");
>        return 1;
>    }
>
> and seeing what happens?  I suspect some options really don't work in
> this case, but without trying it's hard to tell what they are.  If we're
> lucky, it may just be we need to catch a few extra test case lower down
> like the one you picked up in up_histent().  Otherwise, it'll have to go
> on the queue of things I might get around to one day.
>
> Thanks.
>
> --
> 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
>

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: fc.patch --]
[-- Type: text/x-diff; name=fc.patch, Size: 602 bytes --]

? Test/B06fc.ztst
Index: Src/builtin.c
===================================================================
RCS file: /cvsroot/zsh/zsh/Src/builtin.c,v
retrieving revision 1.207
diff -u -r1.207 builtin.c
--- Src/builtin.c	15 Sep 2008 08:57:27 -0000	1.207
+++ Src/builtin.c	23 Sep 2008 03:17:42 -0000
@@ -1296,10 +1296,12 @@
     Patprog pprog = NULL;
 
     /* fc is only permitted in interactive shells */
+#ifdef FACIST_INTERACTIVE
     if (!interact) {
 	zwarnnam(nam, "not interactive shell");
 	return 1;
     }
+#endif
     if (OPT_ISSET(ops,'p')) {
 	char *hf = "";
 	zlong hs = DEFAULT_HISTSIZE;

[-- Attachment #3: B06fc.ztst --]
[-- Type: application/octet-stream, Size: 215 bytes --]

# Tests of fc command
%prep

 mkdir fc.tmp 
 cd fc.tmp
 print 'fc -l foo' >fcl
 
%test
  $ZTST_testdir/../Src/zsh ./fcl
1:Checking that fc -l foo doesn't core dump history is empty
?./fcl:fc:1: event not found: foo

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

[Peter Stephenson]

On Mon, 22 Sep 2008 23:31:51 -0400
"Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
> I removed the interact test and played around with fc and don't see
> any difference.

I'm really only concerned with the non-interactive behaviour, which
probably only you have probed, so if you're happy with it there's probably
nothing major to worry about.

> Attached should be a two-line patch to #ifdef this code out. Apply it.
> If people find problems in fc as a result of this change, I'll fix
> these. If we get to a release and people for whatever reason feel the
> that life was better disallowing fc unless in interactive mode, then
> it is a matter of deleting two lines and you have the old behavior.

It seems unlikely that will be necessary if you haven't fallen over
anything horrible.

> I will also remove the interactive flag on zshdb as another means of
> getting test coverage there with a program that uses fc without
> interactive mode set.
>
> And to show good faith in fixing whatever bugs come up, attached is a
> test in an new "fc" file for the bug I recently discovered which by
> the way has nothing to do with whether or not interactive is set.

Thanks, both very useful.  I've committed both the changes.

-- 
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: fc (history) requires zsh is interactive? Why can't interactive toggled?

[Rocky Bernstein]

Many thanks!

(If you are in a hurry the rest can be safely skipped.)

I think for those who care about such things -- attaching to a running
non-interactive script and setting up an interactive terminal with
history--  this will be an improvement. No doubt this is a very small
(if not negligible) number. So for those who don't, I don't think the
change will be a drag.

I see a typo in dump history in B06fc.ztst: "dump history" => "dump
when history". I've been writing English just about all of my life and
I still manage to bungle sentences like this.

However sometime before a release I should add more fc test cases, in
addition to any issues that arise down the line. I suspect that (and
dread the time when)  folks take issue with how history is handled in
zshdb (or not handled) and how it interacts when there is interactive
history in the debugged the program.

But with more test cases and more coverage, hopefully we will come to
a better understanding in how this or some particular change effects
things and more confidence that making changes of this kind while
assuring it doesn't break things for others.

So thanks again.

On Tue, Sep 23, 2008 at 4:42 AM, Peter Stephenson <pws@csr.com> wrote:
> On Mon, 22 Sep 2008 23:31:51 -0400
> "Rocky Bernstein" <rocky.bernstein@gmail.com> wrote:
>> I removed the interact test and played around with fc and don't see
>> any difference.
>
> I'm really only concerned with the non-interactive behaviour, which
> probably only you have probed, so if you're happy with it there's probably
> nothing major to worry about.
>
>> Attached should be a two-line patch to #ifdef this code out. Apply it.
>> If people find problems in fc as a result of this change, I'll fix
>> these. If we get to a release and people for whatever reason feel the
>> that life was better disallowing fc unless in interactive mode, then
>> it is a matter of deleting two lines and you have the old behavior.
>
> It seems unlikely that will be necessary if you haven't fallen over
> anything horrible.
>
>> I will also remove the interactive flag on zshdb as another means of
>> getting test coverage there with a program that uses fc without
>> interactive mode set.
>>
>> And to show good faith in fixing whatever bugs come up, attached is a
>> test in an new "fc" file for the bug I recently discovered which by
>> the way has nothing to do with whether or not interactive is set.
>
> Thanks, both very useful.  I've committed both the changes.
>
> --
> 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
>