-
-
Notifications
You must be signed in to change notification settings - Fork 299
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
Comments
Idea and proposed syntax courtesy of @hanche |
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 |
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. |
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. |
If this is not implemented, I think at least I'd prefer a replacement for likely the most common occurrence: |
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 In other shells, this is trivial, as in |
@hanche, Can't your "at least one" case be written as
More complicated scenarios are more easily, and probably safely, handled using the 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 |
Oh sorry, it seems I am being stupid. Hopefully it is temporary. Perhaps due to the discussion of regexps, I conflated the use of |
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
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
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
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
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
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
* 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
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 codepointsI don't quite like the last example though, as
-5
looks like negative five. It is technically unambiguous in this case, but still weird.The text was updated successfully, but these errors were encountered: