From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Visuwesh Newsgroups: gmane.emacs.bugs Subject: bug#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26 Date: Mon, 16 Jan 2023 09:43:06 +0530 Message-ID: <87r0vv86ct.fsf@gmail.com> References: <83v8l85g8a.fsf@gnu.org> <87wn5npu7h.fsf@gmail.com> <834jsr64tr.fsf@gnu.org> <87r0vvpqac.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="17046"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: "60819-done@debbugs.gnu.org" <60819-done@debbugs.gnu.org>, Eli Zaretskii To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Jan 16 05:14:25 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1pHGt7-00044v-JT for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 16 Jan 2023 05:14:25 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pHGsm-00051z-KB; Sun, 15 Jan 2023 23:14:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pHGsk-00051n-PH for bug-gnu-emacs@gnu.org; Sun, 15 Jan 2023 23:14:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pHGsk-0003nh-H8 for bug-gnu-emacs@gnu.org; Sun, 15 Jan 2023 23:14:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pHGsk-000311-0b for bug-gnu-emacs@gnu.org; Sun, 15 Jan 2023 23:14:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Visuwesh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Jan 2023 04:14:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 60819 X-GNU-PR-Package: emacs Original-Received: via spool by 60819-done@debbugs.gnu.org id=D60819.167384239811532 (code D ref 60819); Mon, 16 Jan 2023 04:14:01 +0000 Original-Received: (at 60819-done) by debbugs.gnu.org; 16 Jan 2023 04:13:18 +0000 Original-Received: from localhost ([127.0.0.1]:60115 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pHGs1-0002zv-Ep for submit@debbugs.gnu.org; Sun, 15 Jan 2023 23:13:17 -0500 Original-Received: from mail-pf1-f194.google.com ([209.85.210.194]:41554) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pHGrz-0002zf-DO for 60819-done@debbugs.gnu.org; Sun, 15 Jan 2023 23:13:15 -0500 Original-Received: by mail-pf1-f194.google.com with SMTP id c85so16785762pfc.8 for <60819-done@debbugs.gnu.org>; Sun, 15 Jan 2023 20:13:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=3x3/83OoM5UeGf1JSHqpxxUfwgKPX3WzBdqqjK7/vE0=; b=QPX1DlgluVgyjoKH+u2SoPMaM5bM6c/pi+GOGY3Q/4H2joDjRfgof9IAybGdHScj6A nbE3WmwmCnnpdaDZzy7IVNYLRkCaS/Qgo3HnC+AZu720HUGGQhpGFA001ke9e0piCUG3 u/EjRI4dMgckujbWy1MzyAYZgnaUGoqBGuXp+IIYXKOsZqeNsDtKxvQRRhIcBEXyUSP+ 57eicR7kjwUEkqHbc710UywInPb7uSNujHUlzNmoDVyL6eEjKyRZifE7wYrDfU5xj7Pr 2Fxebv+FPZOOLrCNiXSPFoWnE9EvBof5RTy6omaLIaSBxlp0THNaA3MiS+YP+g6nXI6s oaAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=3x3/83OoM5UeGf1JSHqpxxUfwgKPX3WzBdqqjK7/vE0=; b=L+1DvULx63RpQxL/uZFvMgM7FsTdG6snF0q0dPR5rDPlE0U/aPbg8KhE50fB9fBlVY kT+x+l2H68BLQ2Nu/KgCXdzGttQ8lz+UnMOmeMEZ2vzFrqwbmVEix8+IvqIl0XszRmxw no0GW6WcfO6sc1EUgnxiyXKkeovUHWRfgi53MTB1ESfvj2T184j4udpY9/Q608SpMTF0 jyqZ8WdofyRscgS63tnGiHIbmdJnfQsWaMHbLS5HQmdDCafPAHKWx8dijhh/PHPRv/74 5b8ke8K71wJLuDG59sDoyHjW3/smB1HjJ11yZXHdzP8QLCVlnMj+pet5tO1dLWhDM8Ct SnxQ== X-Gm-Message-State: AFqh2kqHaNTc2b+j3Dccs0E3FmGRdnwjKO5uXYT2E7ihZjde2j57c+O2 XmBRlUH8LKnjmqA2B0T8Fks= X-Google-Smtp-Source: AMrXdXtf71VDq2r3hHn1TAT15EPxONIE6wbi4k0VQKUSbzCq1VoKycKQTEPpzpvN9Zij9mCx5Gz8vA== X-Received: by 2002:a05:6a00:4393:b0:58c:972f:92cb with SMTP id bt19-20020a056a00439300b0058c972f92cbmr6973360pfb.1.1673842389390; Sun, 15 Jan 2023 20:13:09 -0800 (PST) Original-Received: from localhost ([118.185.152.162]) by smtp.gmail.com with ESMTPSA id w2-20020a627b02000000b0058d8db0e4adsm2395206pfc.171.2023.01.15.20.13.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Jan 2023 20:13:08 -0800 (PST) In-Reply-To: (Drew Adams's message of "Sun, 15 Jan 2023 22:10:28 +0000") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:253463 Archived-At: [=E0=AE=9E=E0=AE=BE=E0=AE=AF=E0=AE=BF=E0=AE=B1=E0=AF=81 =E0=AE=9C=E0=AE=A9= =E0=AE=B5=E0=AE=B0=E0=AE=BF 15, 2023] Drew Adams wrote: > (Restoring the bug-thread removed from cc.) [ I intended to remove the "-done" mail but missed that the non-done email was in the CCs. ] >> >> >From OpenBSD's glob(7) manpage [1], >> >> Note that when matching a pathname, the path separator =E2=80=98/=E2= =80=99, is not >> >> matched by a =E2=80=98?=E2=80=99, or =E2=80=98*=E2=80=99, character = or by a =E2=80=9C[..]=E2=80=9D sequence. Thus, >> >> /usr/*/*/X11 would match /usr/X11R6/lib/X11 and >> >> /usr/X11R6/include/X11 while /usr/*/X11 would not match >> >> either. Likewise, /usr/*/bin would match /usr/local/bin but not >> >> /usr/bin. >> > >> > Thanks, but that's not the issue at hand. What Drew wanted to see was >> > an explicit wording to the effect that a trailing slash makes the >> > wildcard match only directories. >>=20 >> Doesn't it follow from the quoted text? >> If * doesn't match a /, then it can't match a directory. / is not a >> valid character in a filename so dir*/ would only match directories that >> starts with `dir'. > > That it follows wasn't, and isn't, obvious to me. > (And I cited similar text from other sources, so > clearly I'd read such descriptions.) > >> so dir*/ would only match directories that > ^^ >> starts with `dir'. > > "So"? I don't see how that follows. Why would > one suppose that it matches directory names at > all? The glob doc says that `/' in a glob > pattern delimits pattern segments that match > file-name components - nothing more. What text > says that a directory name that matches a glob > pattern ends with `/'? > > [...] > > Can `/'? It can't match a wildcard, at least. > But can a literal `/' in a glob pattern match a > `/' that's in a file-name component itself (i.e., > in the text between the directory separators, > which for Emacs are `/')? Is such a component > even possible? > > I suppose so, but to include `/' in a file-name > component that char would have had to be escaped > when creating the file whose name includes it. > Or some other, equivalent means would have had > to be employed. > > I'm no expert on whether this is even possible, > or how one might do it (including within Emacs, > and `touch' apparently won't do it). But let's > assume you _can_ do it: somehow embed `/' in a > file-name component, so it's _part_ of the file > name. And let's assume you can even do that > at the end of the file name: have the last > file-name component have `/' as its last char. '/' is not a valid file-name component in POSIX systems [1]. There's no way to "escape" the forward slash. > In such a (rare) case I can see how *b*/ would > match a file name whose last char is `/'. To > me, that's the only way in which the text you > cited (and the similar text I cited) could be > saying that a glob pattern with `/' chars in > it could actually match those chars against '/' > chars embedded in a file name itself. > > But I don't think this rare possibility (if it > is a possibility) is what Eli's talking about. > I don't think he's talking about `/' characters > embedded in a file name. > > A `/' at the end of an Emacs absolute file name > isn't within any file-name component (unless - > see previous paragraphs, for a hypothetical > possibility). I understand that Eli isn't talking about / embedded in filenames but the answer to your original question came naturally from glob(7). At least to me, it was an obvious conclusion. > I think Eli is saying that for Emacs such a `/' > is part of a directory's file name, i.e., what > (elisp) `Directory Names" calls the =E2=80=9Cdirectory > file name=E2=80=9D. I understand this to mean what > function `file-name-as-directory' returns: the > file name considered as directory, which Emacs > writes with a `/' at the end. (Per POSIX etc.) > > To me it wasn't obvious that a glob pattern that > ends with `/' imposes a `file-name-as-directory' > interpretation on candidate matches (but that's > exactly what I wanted Emacs's handling of globs > to do). I do think it would help for the doc to > point this out, if that's what's meant. I do. Please see above. In my mind, it is not that glob patterns impose a restriction to match only directories when the patterns with /, it is more so that a wildcard pattern cannot / is why `dir*/' only matches directories that start with "dir". IOW the restriction is implicit. > But I understand that for you (and Eli?) this is > considered obvious. I'll just say that if so, > then maybe it's a bit odd that the until-now > bugged behavior (existing since Day One or at > least as far back as Emacs 20): (1) existed and > (2) hadn't been reported as a bug. Those facts > suggest to me that this hasn't been obvious at > all. Apparently the ls-lisp code never thought > to implement it, and no one noticed that, or at > least never thought it was a bug. Personally, I don't use ls-lisp and I am not a frequent user of glob patterns but I remember reading this "gotcha" somewhere and promptly checked the manpage which was a definitive enough documentation in my mind hence my initial message. 1. https://pubs.opengroup.org/onlinepubs/007904875/basedefs/xbd_chap03.html= #tag_03_169