From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23109 invoked by alias); 19 Apr 2013 12:52:50 -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: 31277 Received: (qmail 286 invoked from network); 19 Apr 2013 12:52:46 -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=-6.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_HI, SPF_HELO_PASS autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at samsung.com does not designate permitted sender hosts) X-AuditID: cbfec7f5-b7fd76d000007247-38-51713bbfa9c5 Date: Fri, 19 Apr 2013 13:42:38 +0100 From: Peter Stephenson To: zsh-workers@zsh.org Subject: Re: HIST_IGNORE_DUPS ignores lines which differ by a different number of spaces Message-id: <20130419134238.7a8a05a3@pwslap01u.europe.root.pri> In-reply-to: <20130418210411.3254ac63@pws-pc.ntlworld.com> References: <20130416170518.GD18872@xvii.vinc17.org> <20130418210411.3254ac63@pws-pc.ntlworld.com> Organization: Samsung Cambridge Solution Centre X-Mailer: Claws Mail 3.7.9 (GTK+ 2.22.0; i386-redhat-linux-gnu) MIME-version: 1.0 Content-type: text/plain; charset=US-ASCII Content-transfer-encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42I5/e/4Vd391oWBBlN2q1gcbH7I5MDoserg B6YAxigum5TUnMyy1CJ9uwSujAs9r9kKmjkqTk+4zNrAeIiti5GTQ0LAROLEidnsELaYxIV7 64HiXBxCAksZJY6/v80E4Sxnkti34BpYB4uAqsSOr1NYQWw2AUOJqZtmM4LYIgLiEmfXnmcB sYUFoiQm3p3ADGLzCthLvJ83kwnE5hSwkvg98xCYLSSQInHx4i8wm19AX+Lq309MEFfYS8y8 coYRoldQ4sfke2AzmQW0JDZva2KFsOUlNq95yzyBUWAWkrJZSMpmISlbwMi8ilE0tTS5oDgp PddIrzgxt7g0L10vOT93EyMkCL/uYFx6zOoQowAHoxIPb6NEQaAQa2JZcWXuIUYJDmYlEd7l ZoWBQrwpiZVVqUX58UWlOanFhxiZODilGhjT711/tmTDcTe9HbeT24zmuB+171EUilthv8nk 0L51YvyvGVSPuEQH/Pjb1Ff7fHH+apYMn9jC96u9DxhtPrt1oeGSDrcQi7DeH9Ms/Y+4vb+Z 8P/cDY3pVfnKawTr0rYHTj5/p11oywfGTWyvJl+/0+AuLBzhb5TIkh1ru/jKqdU7iw/pKk5V YinOSDTUYi4qTgQAIdGi3SACAAA= On Thu, 18 Apr 2013 21:04:11 +0100 Peter Stephenson wrote: > My best guess is it's got something to do with freehistdata(), which > appears to be the only way the hash table can affect the history ring. Revised theory: when the new node gets added, it retrieves the old node (addhistnode() in hashtable.c). Because of the name mangling it retrieves the previous line if that's the same up to (any, even significant) white space, even if HIST_IGNORE_DUPS isn't set. (This is what's bamboozling me the most.) Because there's an old node (at all, even if it doesn't match completely) it gets marked as HIST_DUP by addhistnode(). Then logic elsewhere removes it. It's just occurred to me that while it might get *marked* with HIST_DUP undconditionally, the logic to remove duplicates only kicks in if HIST_IGNORE_DUPS is set. That might explain why NO_HIST_IGNORE_DUPS works at all. Is this jogging any memories? The code is (by strong zsh tradition) undocumented. pws