Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support a [count:x] wildcard qualifier #849

Open
xiaq opened this issue Aug 11, 2019 · 9 comments
Open

Support a [count:x] wildcard qualifier #849

xiaq opened this issue Aug 11, 2019 · 9 comments

Comments

@xiaq
Copy link
Member

xiaq commented Aug 11, 2019

Should work similarly to regular expression's {n}, matching number of codepoints, with support for ranges. Examples:

  • *[count:5] matches 5 codepoints
  • *[count:5-10] matches 5 to 10 codepoints
  • *[count:5-] matches 5 or more codepoints
  • *[count:-5] matches 5 or fewer codepoints

I don't quite like the last example though, as -5 looks like negative five. It is technically unambiguous in this case, but still weird.

@xiaq
Copy link
Member Author

xiaq commented Aug 11, 2019

Idea and proposed syntax courtesy of @hanche

@krader1961
Copy link
Contributor

Rather than introducing another, seldom used, modifier I think allowing a modifier to be a lambda is preferable. Yes, I know I have a PR #1018 (issue #1015) under review to introduce a type: modifier 😄 But I expect that to be used at least two orders of magnitude more often than filtering on the length of of the file name. Allowing a lambda lets the user use Elvish to filter the list of pathnames.

@xiaq
Copy link
Member Author

xiaq commented May 22, 2020

This is a local qualifier on how many characters a wildcard matches, not a global modifier on the length of the full filename.

@krader1961
Copy link
Contributor

This is a local qualifier on how many characters a wildcard matches, not a global modifier on the length of the full filename.

Understood, but it is still a niche feature that can be implemented via a callback. The callback can easily test the length of the full path or just the final component.

@krader1961
Copy link
Contributor

Note that it appears that most of these niche wildcard modifiers exist in bash/ksh/zsh are because those shells don't support a callback to decide if the expansion should be accepted or rejected.

@hanche
Copy link
Contributor

hanche commented May 23, 2020

If this is not implemented, I think at least I'd prefer a replacement for likely the most common occurrence: [count:1-] meaning “at least one”. So *[set:ab][nonempty] could match one or more a or b, while ?[set:ab][nonempty] could match exactly one of those.

@hanche
Copy link
Contributor

hanche commented May 23, 2020

Here's another issue. How do you write a wildcard pattern that will match filenames containing at least one digit? At present, I don't think you can. But, assuming that a quoted empty string will separate adjacent wildcards, you could say *''*[digit][count:1]* or *''?[digit][nonempty]*. To make it look a little less hacky, we might allow empty modifiers instead: *[]*[digit][count:1]*.

In other shells, this is trivial, as in *[0-9]*. (I have to admit that the wildcards are my least favourite part of the elvish language. But the added power of modifiers is nice, so I am conflicted about them.)

@krader1961
Copy link
Contributor

@hanche, Can't your "at least one" case be written as *?[set:ab]*? Same for filenames containing at least one digit: *?[digit]*. That works for me:

~/tmp> rm *
~/tmp> touch xay xby xcy a1 b2 c4 
~/tmp> put *?[set:ab]*
▶ a1
▶ b2
▶ xay
▶ xby
~/tmp> put *?[digit]*
▶ a1
▶ b2
▶ c4

More complicated scenarios are more easily, and probably safely, handled using the re: and str: modules in a callback.

I too frequently want to match filenames that contain specific characters but that already seems to be adequately supported. I don't even need all ten fingers to count the number of times in the past twenty years I've needed to do anything more complicated than your "exactly one" or "at least one" cases. When I needed that capability I simply ran the matching filenames through a filter like grep.

@hanche
Copy link
Contributor

hanche commented May 24, 2020

Oh sorry, it seems I am being stupid. Hopefully it is temporary. Perhaps due to the discussion of regexps, I conflated the use of ? in wildcards with that in a regexp, thinking of it as “maybe it's there, and maybe not”. My bad. Yes, you're right, that covers it.

@xiaq xiaq removed the A:Language label Oct 28, 2020
krader1961 added a commit to krader1961/elvish that referenced this issue Dec 28, 2020
This is based on elves#1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `find` with Elvish builtins. This is a baby
step towards that goal.

Related elves#849
krader1961 added a commit to krader1961/elvish that referenced this issue Dec 28, 2020
This is based on elves#1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `realpath` and `find` with Elvish builtins. This
is a baby step towards that goal.

Related elves#849
krader1961 added a commit to krader1961/elvish that referenced this issue Dec 28, 2020
This is based on elves#1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `realpath` and `find` with Elvish builtins. This
is a baby step towards that goal.

Related elves#849
krader1961 added a commit to krader1961/elvish that referenced this issue Dec 28, 2020
This is based on elves#1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `realpath` and `find` with Elvish builtins. This
is a baby step towards that goal.

Related elves#849
krader1961 added a commit to krader1961/elvish that referenced this issue Dec 28, 2020
This is based on elves#1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `realpath` and `find` with Elvish builtins. This
is a baby step towards that goal.

Related elves#849
krader1961 added a commit to krader1961/elvish that referenced this issue Jan 12, 2021
This is based on elves#1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `realpath` and `find` with Elvish builtins. This
is a baby step towards that goal.

Related elves#849
xiaq pushed a commit that referenced this issue Jan 16, 2021
* Introduce the `path:` module

This is based on #1084 by @kolbycrouch
submitted five months ago. It addresses all of the feedback on that
change and includes other documentation and unit test improvements. It
also includes a couple of extensions to the original P.R., such as a
`path:is-abs` command.

I decided to resurrect that change because I want better support for
filesystem path manipulation so that users can replace non-portable
external commands such as `realpath` and `find` with Elvish builtins. This
is a baby step towards that goal.

Related #849

* Add a `path:is-regular` command

This adds a `path:is-regular` command.  This is for symmetry with the
`path:is-dir` command and the glob `[type:regular]` modifier.

It also adds support for symlinks in the `testutil.Applydir` function
and change the path unit test to use it.

* Rename path:real to path:eval-symlinks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants