-
-
Notifications
You must be signed in to change notification settings - Fork 321
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
using both inner and outer quotes confuses expr: query. Bug ? #2279
Comments
Here's the three cases above with hledger-1.40, the third one failing:
Here's a custom build that strips (one pair of) enclosing quotes from expr:'s argument. This makes the third case work as OP expected:
Questions: Here's the test journal I'm using. I'm imagining some unusual quotes in the data,
Question: How would a user match those Beancount entries ? This works in old and new versions:
What if you're doing that within an expr: query ? Finding a spelling that does this wasn't easy, but here's one. It still works with both old and new versions (somehow):
There are enough questions that I'm inclined not to touch this myself. I expect I'd merge a PR, if it came with tests clarifying some of these cases. |
In chat, Pixelized reports:
It happens because parseQueryTerm expects to receive
expr:
's argument as an unquoted string; it does not do another round of enclosing-quotes-stripping. So it interprets"assets:cash or not assets"
as a single query term, equivalent toacct:"assets:cash or not assets"
.This is arguably correct behaviour, on the other hand the expectation is understandable. In general, enclosing the full command line argument in quotes is the most robust, like
but we are used to this also working (eg, query docs use this style):
so it seems reasonable to think that this would also work:
It sounds easy enough to have parseQueryTerm check for enclosing quotes and remove them. But will this complicate something else ? Testing needed.
The text was updated successfully, but these errors were encountered: