From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 456 invoked by alias); 31 May 2018 18:15:56 -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: List-Unsubscribe: X-Seq: 42906 Received: (qmail 28476 invoked by uid 1010); 31 May 2018 18:15:55 -0000 X-Qmail-Scanner-Diagnostics: from mail-wm0-f66.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(74.125.82.66):SA:0(-1.9/5.0):. Processed in 3.386229 secs); 31 May 2018 18:15:55 -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=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM, RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL,SPF_PASS, T_DKIM_INVALID autolearn=ham autolearn_force=no version=3.4.1 X-Envelope-From: tamelingdaniel@gmail.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:subject:message-id:mail-followup-to:references :mime-version:content-disposition:in-reply-to; bh=gHVBxVmx1HfXfVddZd8MTCv9MRuqvR958OgkHmY8u5U=; b=l5u3lOzoqN3uElcyyR4ZdDv//Ob4su+71HbnL8VM1WOwBDZdywEVw8+8EiuAP9IhAT cH7yQk2VM8ajK8MgXNVVZ55xF+LDagsrKzqJSCEz57xErn7f5cspMmnPVPbVySqJ6YYN BzzNh8UHAXLrGWH+5CmQBH6zdvyUuJ/m6O+JDWooycTGEPdnWA8uby1QLVbjsDAYN2W5 9cGsfxS/lbkS5l4Eoo6q63vcHWCTGopmQF4QHvX4kg2qZ6lG0owugbX8fRENq1KXKnjc E0ahhxRP7sOqy7qC7zAy3CK8EFZRPbHL9dfmsH31fHyNiiMSyXlsgtEN1sFZvW31Vmh/ AchA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:subject:message-id:mail-followup-to :references:mime-version:content-disposition:in-reply-to; bh=gHVBxVmx1HfXfVddZd8MTCv9MRuqvR958OgkHmY8u5U=; b=gwSe6WHun2sic2Jp4LnYD5wmMS95UfSIcAxF4hUZChbg6cDMXIiMzMEkLdCDvyz3Jx lzcEn29K/01AvTqxzadX8bSFlq6uChWv9yXb7f1f5GVni4Z2R4QgLKLmOdsGn2K5lxE9 iFuvg/WUvjSxTdCUQlRMc1Nw2MSy+YJtEKGUcASaSuKZ5HoUfoOVrLXtQEVf76R2rg0U ByeTYG1plV+qXYV2OiwDwUzXlAVTQ8YrsVjBChDrpHF7hzFD6otbvjQVYz8sgSiiCDaN xqi8KQiwnWjefICLq1nyCBjWVLIi9MM2IaUCabVy4jts8sWG6eoyuXywsKdjX5h9NA8e lyAw== X-Gm-Message-State: ALKqPwfx1ybBeFkW70lc5EzOG38180S8hgm0mdYNVmuMNms4BttdLpEf 3KUuVHPvr7102NK4kL8Jb7hdeA== X-Google-Smtp-Source: ADUXVKIEHOXUer4JCV1WwqBp/jQzziNXgmsQyph5cIBfGBieRg7XBa9pTzb1h43cMzeJY4s2+TQO9g== X-Received: by 2002:a1c:6c09:: with SMTP id h9-v6mr657922wmc.138.1527790547767; Thu, 31 May 2018 11:15:47 -0700 (PDT) Date: Thu, 31 May 2018 20:15:46 +0200 From: Daniel Tameling To: zsh-workers@zsh.org Subject: Re: [Bug] Strange Globing Behaviour when used with sudo Message-ID: <20180531181546.osffv3ysjzaxjfid@Daniels-MacBook-Air.local> Mail-Followup-To: zsh-workers@zsh.org References: <1527707719.3469997.1390875592.73AD29B6@webmail.messagingengine.com> <20180530202349.GA10754@osmium.lan> <20180531094403.05b62bee@camnpupstephen.cam.scsc.local> <20180531084938eucas1p19a854d9e9ea17428cd6549f56a283356~zroN76sl33019130191eucas1p1K@eucas1p1.samsung.com> <3977A049-90E6-4EDD-9E4C-8D2FF38593A3@kba.biglobe.ne.jp> <20180531152941eucas1p2c45927fa47f727224e2da98b4f6a7604~zxFgS-BM50307003070eucas1p2G@eucas1p2.samsung.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20180531152941eucas1p2c45927fa47f727224e2da98b4f6a7604~zxFgS-BM50307003070eucas1p2G@eucas1p2.samsung.com> On Thu, May 31, 2018 at 04:29:39PM +0100, Peter Stephenson wrote: > On Thu, 31 May 2018 20:39:45 +0900 > Jun T wrote: > > If we want to workaround this "bug", we need to check st_mode of dummy > > somewhere in glob.c. > > The key point is probably the return from statfullpath(), but as far as > ad-hoc workarounds go you're on your own, I'm afraid. > I came up with a patch, but it's more a proof of concept. It fixes the issue at hand, but I am not sure about it's side effects so I didn't clean it up. What is happening is the following: the problem arises when statfullpath is called in glob.c at the following place: } else if (!checked) { if (statfullpath(s, &buf, 1)) { unqueue_signals(); return; } As s is NULL and buf is in the example ./file/, statfullpath adds to buf a . so that it's "./file/.". At the end of the function stat is called for this path, which should return a non-zero value, but which doesn't happen with sudo on Mac OS X. Instead it returns incorrectly zero, which is then the return value of statfullpath, and thus unqueue_signals(); return; isn't called, and we get matches. So one possibility to fix this is to call stat before adding the . to ./file/, and the return non-zero if it is not a directory. But again, I don't know whether this fix would introduce some other bugs. I'm also not sure whether there are even more "bugs" because Mac OS behaves so strangely with sudo. -- Best, Daniel diff --git a/Src/glob.c b/Src/glob.c index 66a95329f..19a8766f9 100644 --- a/Src/glob.c +++ b/Src/glob.c @@ -294,6 +294,8 @@ statfullpath(const char *s, struct stat *st, int l) * Don't add the '.' if the path so far is empty, since * then we get bogus empty strings inserted as files. */ + stat(buf, st); + return !S_ISDIR(st->st_mode); buf[pathpos - pathbufcwd] = '.'; buf[pathpos - pathbufcwd + 1] = '\0'; l = 0;