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@xxxxxxx> 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@xxxxxxx> Software Engineer
> CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
> Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070
>
? 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:
B06fc.ztst
Description: Binary data