From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10959 invoked by alias); 24 Jan 2012 20:28:24 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 30122 Received: (qmail 8486 invoked from network); 24 Jan 2012 20:28:23 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at closedmail.com does not designate permitted sender hosts) From: Bart Schaefer Message-id: <120124122819.ZM31632@torch.brasslantern.com> Date: Tue, 24 Jan 2012 12:28:19 -0800 In-reply-to: <20120121023957.GA2643@daniel3.local> Comments: In reply to Daniel Shahaf "Re: Obscure zsh history overflow with segfault" (Jan 21, 4:39am) References: <87ty3q5ffx.fsf@gmail.com> <20120121023957.GA2643@daniel3.local> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Obscure zsh history overflow with segfault MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 21, 4:39am, Daniel Shahaf wrote: } } Apparently, 'r 100 foo' should re-execute the portion of your history } from event #100 to event 'foo'. } } Sounds like a bad idea... Interesting. Here we are: 1516 /* 1517 * Nasty behaviour results if we use the current history 1518 * line here. Treat it as if it doesn't exist, unless 1519 * that gives us an empty range. 1520 */ 1521 if (last >= curhist) { 1522 last = curhist - 1; 1523 if (first > last) { 1524 unqueue_signals(); 1525 zwarnnam("fc", 1526 "current history line would recurse endlessly, aborted"); 1527 fclose(out); 1528 unlink(fil); 1529 return 1; 1530 } 1531 } In the situation in this bug, first > last is true but last >= curhist is false. I believe that means that even though this is an infinite loop, we don't detect that it will be. However, it's worse than that: If HIST_NO_STORE is not set, then even when last < curhist and first <= last, its possible for the history to contain an "r" command, which will be executed, retrieving a history that contains an "r" command, which ... One possible approach is for bin_fc to refuse to recursively run the "r" command (same for "fc -e -"). However, it's then still possible for the user to shoot himself with "fc -e cat ..." (or any other no-op editor command); so short of disallowing any sort of recursive entry into "fc" when -l is not given, this probably has to be treated as a user error.