From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1517 invoked by alias); 30 Oct 2016 15:45:47 -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: 39774 Received: (qmail 1183 invoked from network); 30 Oct 2016 15:45:47 -0000 X-Qmail-Scanner-Diagnostics: from mail-qk0-f169.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.220.169):SA:0(0.0/5.0):. Processed in 0.590832 secs); 30 Oct 2016 15:45:47 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=FREEMAIL_FROM,HTML_MESSAGE, SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: john.reed.riley@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.220.169 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=f2VymlITkkNdAr7FMshLfCJ/IZ12Wmo+y0jgxhlZA1o=; b=xdlNGyBNe3RCsTd4iITeS1/xKHSi9ZYKz7Q+ULS05FvbnUfqo6TukWBhQLUymnJ0LB u+mcXiIJ5P18uBNAdWTqh5Ff/S28jCSJ3VmXXzEN7dPNL1T92Ha+q2bei+lNzhdA8m4P MqMs5a/jBwBxQQAyYrzMfckBs+0kg9QNbgGQRs33iXlkkY95Pa0DfX1p+oWTdhLFj+IL JSlvbNQqWA9HdJoLMt3NxjUWt1Yo5gA0971fkNMeNPKbYVuf40XxFvkvitysOO0Rby+k 1fZtAjjfpLaM48oq+F3i1QjDD6cpAr5uhN/Q7vDUco6Q1Yb9MYla1dz8vDlY/hADssYz Pbxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=f2VymlITkkNdAr7FMshLfCJ/IZ12Wmo+y0jgxhlZA1o=; b=UDc479lHJZa6dsf+4pCN99COI1FrT5JQMt6scMaP0kmOdUFUIOOv0p4RXCWnlW0v6g IcXMVV28ZG5iSqEherzMWgz0+XMI+6XF0ZdwnJuhVBDovWkQwcgORn7VmfAOCiR61gnl 0kkwUqEGpqu97lwOIl8jFIOxrJCtwEaYpiiR+FncQcBT1zroBZPOjHGmgQHuAxaTQxAs PtL/OTrMxMZkCOZ/wTkPd6QVJzU9Q3PV8+xRTRIrIrgZgpVmgSMWqZzp6VZT9l7NHwHp IjklgbIF9SMYOAEK09qeH52W5TP7vvN75khutsTvf61ZL7PtQPlXcaKnzTV4NihQpDqx s1Zw== X-Gm-Message-State: ABUngvfgg0Lu6a/5OEdSSaIKe6/78bSCuChBHUkTMP64yXhs7nq8qIXhJCDbbF8XwGZJQTyqmpoOzbDiw/5Q+w== X-Received: by 10.55.67.67 with SMTP id q64mr21817159qka.133.1477838598476; Sun, 30 Oct 2016 07:43:18 -0700 (PDT) MIME-Version: 1.0 In-Reply-To: <87y416drcq.fsf@ft.bewatermyfriend.org> References: <20161030024723.62832-1-john.reed.riley@gmail.com> <87y416drcq.fsf@ft.bewatermyfriend.org> From: Reed Riley Date: Sun, 30 Oct 2016 10:43:17 -0400 Message-ID: Subject: Re: [PATCH] Fix hexdump command used for mercurial dirstate parsing To: Frank Terbeck Cc: zsh-workers@zsh.org Content-Type: multipart/alternative; boundary=001a114ac170b299cb0540161c65 --001a114ac170b299cb0540161c65 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Damn - I had no idea `xxd` was a part of Vim, sorry! The original version of my patch was `hexdump -n 20 -e '20/1 "%02x"' ${dirstatefile}` - I only switched to xxd at Daniel Shahaf's suggestion. I sadly can't provide a full dirstate file for a repro, but I can provide the relevant part as a hexdump: =E2=9D=AF hexdump dirstate | head -n3 0000000 77 bb a6 65 e9 70 14 6b d2 be 0b 2d a4 00 92 e3 0000010 40 40 88 04 00 00 00 00 00 00 00 00 00 00 00 00 0000020 00 00 00 00 00 00 00 00 6e 00 00 81 a4 00 00 04 =E2=9D=AF hexdump -n20 -e '1/1 "%02x"' dirstate 77bba665e970146bd2be0b2da40092e340* 8804% >>From the limited research I've done, the issue in the output is that '*' is used to represent repetitions: - http://superuser.com/questions/494245/what-does-an-asterisk-mean-in-hexdump= -output - also described (partially?) in `man hexdump` in the description of the `-v` option. In other words, if you have repeated octets in your commit hash, the old command doesn't work properly. So, based on that, there are two versions of the command that work correctly on this particular case for me: hexdump -n 20 -e '20/1 "%02x"' ${dirstatefile} hexdump -n 20 -v -e '1/1 "%02x"' ${dirstatefile} Do you have any preference between them? Thanks, Reed On Sun, Oct 30, 2016 at 7:11 AM, Frank Terbeck wrote: > Hi, > > Reed Riley wrote: > > Normally, the old command works. But very rarely, it outputs a string > > like the following instead: > > =E2=9D=AF hexdump -n20 -e '1/1 "%02x"' .hg/dirstate > > 77bba665e970146bd2be0b2da40092e340* > > 8804 > [...] > > - r_csetid=3D$(hexdump -n 20 -e '1/1 "%02x"' ${dirstatefile}) > > + r_csetid=3D$(xxd -p -l20 ${dirstatefile}) > > I would much rather know, what causes hexdump to behave like that. Is > the way we are using it documented behavior? If so, that would suggest a > bug in hexdump, that should be resolved instead. If no, we're probably > using hexdump in a wrong way =E2=80=94 maybe just in a non-portable way, = and we > should fix the way we're using hexdump. > > Are you able to provides example data, that causes the bug? Maybe even > formulate a supposition as to what it is exactly, that triggers this > behaviour. > > "xxd" is a command shipped with vim. Adding such a dependency is out of > the question for me. It would be conceivable to make the command that is > called in these places configurable via styles. But that is a separate > issue to the one that fixes our use of hexdump. > > > Regards, Frank > --=20 Reed Riley -------------------------------------------- Q: Why is this email five sentences or less? A: http://five.sentenc.es --001a114ac170b299cb0540161c65--