From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13226 invoked by alias); 21 May 2013 05:56:30 -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: 31416 Received: (qmail 11049 invoked from network); 21 May 2013 05:56:25 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: none (ns1.primenet.com.au: domain at brasslantern.com does not designate permitted sender hosts) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:date:message-id:subject:from:to:content-type :x-gm-message-state; bh=vaYwSoP+E0OfD6iCS5/LRxpae63AnMsfbZu5XJ3DBKM=; b=GWGxJJRQ8EWKI1ho+l5JiT0lChxWW3SaNd2AC4s/ocojBTdr45vIh/Uuao5Y+YkmuD IE9SShBy2h+hqYebsTcEBGMjS7LaeUEz43mKOwQkOY62HbI+UX2t1m7nuYlO7YNys7JZ WEyo6tELbqkc0/14JXZ7SHDyRTU5kDsjcQwC+BH4qwuozj4Yz2u3BZf3VVEc24DCW2Yr Wq4Ez2vXCqaq4SvBmNO/N/wSPkj+6hh3TmNIoT8+a2fvOwZO0N0C+M8NwKFnHJCSHZtI bPslAVa55bTyTplezjhFOaOrkKP/DB6K4RmxQQeH3uOTopw7Ai2kLFV6sMiU5ZSzC8fY PLfg== MIME-Version: 1.0 X-Received: by 10.152.28.163 with SMTP id c3mr447443lah.26.1369115775780; Mon, 20 May 2013 22:56:15 -0700 (PDT) Date: Mon, 20 May 2013 22:56:15 -0700 Message-ID: Subject: [PATCH] Re: Quick local CVS change scan, and bug in read? From: Bart Schaefer To: Zsh hackers list Content-Type: multipart/mixed; boundary=089e0160babe78dc6e04dd341bc9 X-Gm-Message-State: ALoCoQlYSqXxt0dtCcY/SpJJ9PpiKuoPZSCzn3PxM9BAztyXWjJ/WsATSQG6yN/i6+mEVpoxjA1H --089e0160babe78dc6e04dd341bc9 Content-Type: text/plain; charset=ISO-8859-1 On Sat, May 18, 2013 at 4:24 PM, Bart Schaefer wrote: > some CVS/Entries files end with the line "D" with none of the usual > field-separator slashes. When the "while IFS=/ read ..." loop > encounters such a line, it assigns type=D but leaves name, version, > date, flags, and branch set to their existing values from the previous > loop pass. I'm pretty sure this is wrong; bash read assigns empty > string to all the "unused" variables in the list. The bug turned out to be very easy to fix. The reason it went unnoticed for so long is, the variables were correctly cleared when bin_read reached EOF. I generally don't like attaching patches rather than in-lining them, but I'm still stuck with gmail for the nonce and it tends to mangle patches in-line, so I'm going to try attaching this one. It's very short. --089e0160babe78dc6e04dd341bc9 Content-Type: application/octet-stream; name="0001-upon-read-of-a-short-line-assign-all-variables-passe.patch" Content-Disposition: attachment; filename="0001-upon-read-of-a-short-line-assign-all-variables-passe.patch" Content-Transfer-Encoding: base64 X-Attachment-Id: f_hgyo56pq0 RnJvbSAxOWI0OWRiN2EzMTM4N2I2NTU0ODE2N2Y3M2FlYWJiYmJlNjBjM2FiIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBCYXJ0b24gU2NoYWVmZXIgPHNjaGFlZmVyQHpzaC5vcmc+CkRh dGU6IE1vbiwgMjAgTWF5IDIwMTMgMjI6NDQ6MDMgLTA3MDAKU3ViamVjdDogW1BBVENIXSB1cG9u ICJyZWFkIiBvZiBhIHNob3J0IGxpbmUsIGFzc2lnbiBhbGwgdmFyaWFibGVzIHBhc3NlZCBhcyBh cmd1bWVudHMuCgpJdCB3YXMgbm90ZWQgdGhhdCAocHJpbnQgMSAyIHwgcmVhZCBvbmUgdHdvIHRo cmVlIGZvdXIpIGFzc2lnbmVkIHZhbHVlcwpvbmx5IHRvICRvbmUgYW5kICR0d28gZXhjZXB0IGlu IHRoZSBjYXNlIHdoZXJlIEVPRiB3YXMgcmVhY2hlZC4KLS0tCiBTcmMvYnVpbHRpbi5jIHwgICAg MiArLQogMSBmaWxlcyBjaGFuZ2VkLCAxIGluc2VydGlvbnMoKyksIDEgZGVsZXRpb25zKC0pCgpk aWZmIC0tZ2l0IGEvU3JjL2J1aWx0aW4uYyBiL1NyYy9idWlsdGluLmMKaW5kZXggY2Q4ODY0My4u YmM5MTU3OCAxMDA2NDQKLS0tIGEvU3JjL2J1aWx0aW4uYworKysgYi9TcmMvYnVpbHRpbi5jCkBA IC01Njc0LDcgKzU2NzQsNyBAQCBiaW5fcmVhZChjaGFyICpuYW1lLCBjaGFyICoqYXJncywgT3B0 aW9ucyBvcHMsIFVOVVNFRChpbnQgZnVuYykpCiAJICAgIHpwdXRzKGJ1Ziwgc3Rkb3V0KTsKIAkg ICAgcHV0Y2hhcignXG4nKTsKIAl9Ci0JaWYgKCFPUFRfSVNTRVQob3BzLCdlJykgJiYgKCpidWYg fHwgZmlyc3QpKSB7CisJaWYgKCFPUFRfSVNTRVQob3BzLCdlJykgJiYgKCpidWYgfHwgZmlyc3Qg fHwgZ290bmwpKSB7CiAJICAgIGlmIChPUFRfSVNTRVQob3BzLCdBJykpIHsKIAkJYWRkbGlua25v ZGUocmVhZGxsLCBidWYpOwogCQlhbCsrOwotLSAKMS43LjAuNAoK --089e0160babe78dc6e04dd341bc9--