Closed lsloan closed 2 years ago
This is embarrassing, or maybe it's a good sign: I learned of a syntax that works. So, this may be a non-issue.
When I saw in the documentation that regular expressions were delimited by /
or some non-whitespace character, I immediately thought in terms of vi- or ex-like syntax. So, I thought the ignore case operator would go at the end, like /name/i
.
However, I've learned that yamlpath
uses the Python re
module, which doesn't use that syntax. I've learned that the way to specify the case ignore flag is with (?i)
. Therefore, this example works the way I expected:
yaml-paths -Ls '=~/(?i)name/' example.yaml
It might be helpful to just put a link to Python's re
module in the documentation and refer to it for syntax help.
I will take it as a task to add the re
reference to the documentation; great idea!
Update: Maybe only additions to the documentation are needed. See my next comment below.
I wasn't sure whether this should be a bug report or a feature request, so I opted for the more positive of the two.
Is your feature request related to a problem? Please describe. When using
yaml-paths
, I'd like to be able to do case-insensitive searches. I don't always know whether letters of the string I'm searching for are in upper-, lower-, or mixed-case.Describe the solution you'd like An option or a filter that when searching for
name
will findname
,Name
,NAME
, etc.Describe alternatives you've considered I saw that there wasn't an option for ignoring case, so I looked for other possible solutions. Seeing that the
=~
search operator for regular expressions uses a delimiter, like/
, I thought I'd try adding the case insensitive matching flag following the last delimiter, thus:However, that didn't yield any results. When I changed
name
in the search expression to match the case of letters definitely occurring inexample.yaml
, I still didn't get results.Next, I tried removing the
i
regular expression flag. That yielded results, but only those that exactly matched the case of the search filter. So, that showed that thei
regular expression flag was interfering with the search.The only workaround I could find was:
However, all the search results were in lower case, so it takes additional commands to find the values in their original case.
PS If I have time, I will try to open a pull request with a possible solution for this.