From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14274 invoked from network); 23 Sep 2008 03:32:10 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 23 Sep 2008 03:32:10 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 24389 invoked from network); 23 Sep 2008 03:32:02 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 23 Sep 2008 03:32:02 -0000 Received: (qmail 21424 invoked by alias); 23 Sep 2008 03:31:57 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 25727 Received: (qmail 21414 invoked from network); 23 Sep 2008 03:31:57 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 23 Sep 2008 03:31:57 -0000 Received: from wa-out-1112.google.com (wa-out-1112.google.com [209.85.146.179]) by bifrost.dotsrc.org (Postfix) with ESMTP id EFE9F80307AB for ; Tue, 23 Sep 2008 05:31:52 +0200 (CEST) Received: by wa-out-1112.google.com with SMTP id v27so1227539wah.21 for ; Mon, 22 Sep 2008 20:31:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=sIG7Xmd3ci00H6ZRxUrcnZDZ8N6WeqiobS43K6XnPHw=; b=wZ7qq3fOgszOVw+9bC0b5lLHjr+t0tZO1BquB/rg1dDPMLtaOyucQ/ZUdUNxl7q7NA trw+qlN/3+OP4FG2AJ2H97AjcCKYUw3xvjZWzuEIkQ2bFmyHoy+GRD7nLhe/xxfqLAZ5 lWnGGyhQMujEZVwEa8dFM3JSuxgV0Jtm/yxKU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=xuN6k9BO30VgKzctkpXwDOSgMbPDxr3w5Z/wgQfKp8/risO1WhmRD9dahFmeq0dh23 eGYsjLXT0j4LL1pvLxWKSypsqNFg+UHGw6D/2TzKUWlSWJwR3GrfWsXjn5jCA2Y6mHGf W2M/HlY3gBEfAcH+zhglo8uuc4geveXTMPyrg= Received: by 10.114.169.20 with SMTP id r20mr5664880wae.198.1222140711298; Mon, 22 Sep 2008 20:31:51 -0700 (PDT) Received: by 10.114.159.2 with HTTP; Mon, 22 Sep 2008 20:31:51 -0700 (PDT) Message-ID: <6cd6de210809222031n12743897l3e4474593a9a780a@mail.gmail.com> Date: Mon, 22 Sep 2008 23:31:51 -0400 From: "Rocky Bernstein" To: "Peter Stephenson" Subject: Re: fc (history) requires zsh is interactive? Why can't interactive toggled? Cc: "Zsh hackers list" In-Reply-To: <200809221425.m8MEPcWg015191@news01.csr.com> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_49631_32964190.1222140711296" References: <6cd6de210809211737o564e47a4jf7f92ada4cd970dc@mail.gmail.com> <20080922130602.4746e4d1@news01> <6cd6de210809220658x26698b78ga08f95eaa42644c@mail.gmail.com> <200809221425.m8MEPcWg015191@news01.csr.com> X-Virus-Scanned: ClamAV 0.92.1/8314/Tue Sep 23 02:50:20 2008 on bifrost X-Virus-Status: Clean ------=_Part_49631_32964190.1222140711296 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline 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 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 Software Engineer > CSR PLC, Churchill House, Cambridge Business Park, Cowley Road > Cambridge, CB4 0WZ, UK Tel: +44 (0)1223 692070 > ------=_Part_49631_32964190.1222140711296 Content-Type: text/x-diff; name=fc.patch Content-Transfer-Encoding: base64 X-Attachment-Id: f_flfywyty0 Content-Disposition: attachment; filename=fc.patch PyBUZXN0L0IwNmZjLnp0c3QKSW5kZXg6IFNyYy9idWlsdGluLmMKPT09PT09PT09PT09PT09PT09 PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PQpSQ1MgZmls ZTogL2N2c3Jvb3QvenNoL3pzaC9TcmMvYnVpbHRpbi5jLHYKcmV0cmlldmluZyByZXZpc2lvbiAx LjIwNwpkaWZmIC11IC1yMS4yMDcgYnVpbHRpbi5jCi0tLSBTcmMvYnVpbHRpbi5jCTE1IFNlcCAy MDA4IDA4OjU3OjI3IC0wMDAwCTEuMjA3CisrKyBTcmMvYnVpbHRpbi5jCTIzIFNlcCAyMDA4IDAz OjE3OjQyIC0wMDAwCkBAIC0xMjk2LDEwICsxMjk2LDEyIEBACiAgICAgUGF0cHJvZyBwcHJvZyA9 IE5VTEw7CiAKICAgICAvKiBmYyBpcyBvbmx5IHBlcm1pdHRlZCBpbiBpbnRlcmFjdGl2ZSBzaGVs bHMgKi8KKyNpZmRlZiBGQUNJU1RfSU5URVJBQ1RJVkUKICAgICBpZiAoIWludGVyYWN0KSB7CiAJ endhcm5uYW0obmFtLCAibm90IGludGVyYWN0aXZlIHNoZWxsIik7CiAJcmV0dXJuIDE7CiAgICAg fQorI2VuZGlmCiAgICAgaWYgKE9QVF9JU1NFVChvcHMsJ3AnKSkgewogCWNoYXIgKmhmID0gIiI7 CiAJemxvbmcgaHMgPSBERUZBVUxUX0hJU1RTSVpFOwo= ------=_Part_49631_32964190.1222140711296 Content-Type: application/octet-stream; name=B06fc.ztst Content-Transfer-Encoding: base64 X-Attachment-Id: f_flfz0i7c1 Content-Disposition: attachment; filename=B06fc.ztst IyBUZXN0cyBvZiBmYyBjb21tYW5kCiVwcmVwCgogbWtkaXIgZmMudG1wIAogY2QgZmMudG1wCiBw cmludCAnZmMgLWwgZm9vJyA+ZmNsCiAKJXRlc3QKICAkWlRTVF90ZXN0ZGlyLy4uL1NyYy96c2gg Li9mY2wKMTpDaGVja2luZyB0aGF0IGZjIC1sIGZvbyBkb2Vzbid0IGNvcmUgZHVtcCBoaXN0b3J5 IGlzIGVtcHR5Cj8uL2ZjbDpmYzoxOiBldmVudCBub3QgZm91bmQ6IGZvbwo= ------=_Part_49631_32964190.1222140711296--