all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Visuwesh <visuweshm@gmail.com>
To: Drew Adams <drew.adams@oracle.com>
Cc: "60819-done@debbugs.gnu.org" <60819-done@debbugs.gnu.org>,
	Eli Zaretskii <eliz@gnu.org>
Subject: bug#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26
Date: Mon, 16 Jan 2023 09:43:06 +0530	[thread overview]
Message-ID: <87r0vv86ct.fsf@gmail.com> (raw)
In-Reply-To: <CO6PR10MB5473AE0117CCC855D618A0B1F3C09@CO6PR10MB5473.namprd10.prod.outlook.com> (Drew Adams's message of "Sun, 15 Jan 2023 22:10:28 +0000")

[ஞாயிறு ஜனவரி 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 ‘/’, is not
>> >>  matched by a ‘?’, or ‘*’, character or by a “[..]” 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.
>> 
>> 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 “directory
> file name”.  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





  reply	other threads:[~2023-01-16  4:13 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-14 22:28 bug#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26 Drew Adams
2023-01-15  8:55 ` Eli Zaretskii
2023-01-15 17:04   ` Drew Adams
2023-01-15 17:25     ` Eli Zaretskii
2023-01-15 17:45     ` Visuwesh
2023-01-15 18:16       ` Eli Zaretskii
     [not found]         ` <87r0vvpqac.fsf@gmail.com>
2023-01-15 22:10           ` Drew Adams
2023-01-16  4:13             ` Visuwesh [this message]
2023-01-16 13:44               ` Eli Zaretskii
     [not found] ` <handler.60819.D60819.167377296010937.notifdone@debbugs.gnu.org>
     [not found]   ` <jwv1qbxhlfc.fsf-monnier+emacs@gnu.org>
2023-12-20 23:39     ` bug#60819: closed (Re: bug#60819: 28.2; `ls-lisp.el' regression introduced in Emacs 26) Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r0vv86ct.fsf@gmail.com \
    --to=visuweshm@gmail.com \
    --cc=60819-done@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    --cc=eliz@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.