The venerable old-skool Splunk forums are now closed. Feel free to search for old content here, but new posts are no longer supported.

Instead, please visit the thriving community at answers.splunk.com to ask and answer questions about your Splunk deployment and how to get the most out of it.

Forums: SplunkGeneral: Splunk bug with backslash and quotes - escape character \

Previous Topic: Splunk on AIX 6.1  |   Next Topic: Reindex existing data?


Posts 1–10 of 15

I have a relatively simple search, which includes a phrase enclosed in double quotes. For example:

error OR failed OR severe OR ( sourcetype=access_* ( 404 OR 500 OR 503 ) ) NOT "illegal user"

When I type in the search manually it works fine. When I save it Splunk inserts escape characters before each of the quotes, so that the next time I pull up the search it fails and shows zero results. I have to manually delete the backslashes to get it to work again. Older versions of splunk did not do this.

Please let me know what I need to do to fix this. It's extremely annoying to have to delete the backslashes each time.

This is a known issue and should be fixed in an upcoming service release - sorry for the inconvenience, it bugs me too!

Ok, just wanted to make sure I wasn't doing something wrong.

Nope, you did everything right! I will try to remember to update this post when the bug is fixed, but to be extra sure you can email support at splunk dot com, let them know you are having the issue and ask them to let you know when it is fixed.

Is this one of the issues (SPL-26944, SPL-28136, SPL-28640) that were fixed in release 4.0.9?

Looks like yes: http://www.splunk.com/base/Documentation/latest/ReleaseNotes/4.0.9

Are those issues accessible anywhere on the website?
It seems from the descriptions in the release notes that it just affected "NOT" queries? Or that those were the only ones that were fixed?
The reason I ask is that we have a couple of queries that broke with the same problem (extra escaping of quotes and/or extra quotes, though ours doesn't have any "NOT"s). I just upgraded to 4.0.9 and the problem doesn't seem to have been fixed. For us, anyway. :-)

they're not available publicly. it would be helpful to have an example of a query that behaves that way, and you can either open a support case with it (it should be easy enough to verify it's a bug) or you post it here.

The problem is not fixed in 4.0.9, I can confirm this. I believe the issue is supposed to be re-fixed in 4.0.10, I will try to confirm that this is the case.

Ok, thanks.




1   |   2    Next »