In my sql-script I query some data like this:
SELECT *
FROM table.[x/y/z]()
This query works completely fine
However sqlfluff lint returns Found unparsable section.
Sqlfluff parsing all works fine, when I remove the '/'.
Is there a way to configure the sqlfluff parser to ignore code parts, maybe based on a regex pattern?
Related
By default, bracket matching doesn't understand strings and so will match brackets inside of quotes.
Steps to reproduce:
Start the language-configuration-sample extension
Type the following line in the file,
[ "]" ]
Move the cursor to the start of the line and hit Ctrl-\
The open bracket will match with the bracket inside the quotes.
The same behavior happens with anything defined as "brackets" in the config.
I've noticed language extensions like java, python, etc do not have this behavior. How do they get around it? I've looked through their code and haven't seen anything that looks related.
In vue, is there a way to have a value span multiple lines in an .env file. Ex:
Instead of:
someValue=[{"someValue":"Here is a really really long piece which should be split into multiple lines"}]
I want to do something like:
someValue=`[{"someValue":"Here is a really
really long piece which
should be split into multiple lines"}]`
Doing the latter gives me a JSON parsing error if I try to do JSON.parse(someValue) in my code
I don't know if this will work, but I can't format a comment appropriately enough to get the point across so see if this will work:
someValue=[{"someValue":"Here is a really\
really long piece which\
should be split into multiple lines"}]
Where "\" should escape the newline similar to how you can write long bash commands while escaping the newline. I'm not certain the .env interpreter will support it though.
EDIT
Looks like this won't work. This syntax was actually proposed, but I don't think it was incorporated. See motdotla/dotenv#333 (which is what Vue uses to parse .env).
Like #zero298 said, this isn't possible. Likely you could delimit the entry with a character that wouldn't show up normally in the text (^ is a good candidate), then parse it within the application using string.replace('^', '\n');
I am using the Uncrustify plugin for Xcode5 (BBUncrustifyPlugin) to format my code nicely. However when formatting the active file it gives the errors:
Uncrustify Formatter error:
Parsing: XDImageViewController.m as language OC
XDImageViewController.m:33 Unmatched NEWLINE
Looking at this line all I have is a single hash # followed by a new line. like so:
#
#pragma mark - Section header
#
Can anyone tell me if there is a way to get Uncrustify to ignore this error or work around it? I don't see why a hash should cause problems.
Thanks.
When I try to search for something such as "workaround/fix" within Lucene, it throws this error:
org.apache.lucene.queryparser.classic.ParseException: Cannot parse 'workaround/fix': Lexical error at line 1, column 15. Encountered: <EOF> after : "/fix"
at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:131)
at pi.lucengine.LucIndex.main(LucIndex.java:112)
Caused by: org.apache.lucene.queryparser.classic.TokenMgrError: Lexical error at line 1, column 15. Encountered: <EOF> after : "/fix"
at org.apache.lucene.queryparser.classic.QueryParserTokenManager.getNextToken(QueryParserTokenManager.java:1133)
at org.apache.lucene.queryparser.classic.QueryParser.jj_scan_token(QueryParser.java:599)
at org.apache.lucene.queryparser.classic.QueryParser.jj_3R_2(QueryParser.java:482)
at org.apache.lucene.queryparser.classic.QueryParser.jj_3_1(QueryParser.java:489)
at org.apache.lucene.queryparser.classic.QueryParser.jj_2_1(QueryParser.java:475)
at org.apache.lucene.queryparser.classic.QueryParser.Clause(QueryParser.java:226)
at org.apache.lucene.queryparser.classic.QueryParser.Query(QueryParser.java:181)
at org.apache.lucene.queryparser.classic.QueryParser.TopLevelQuery(QueryParser.java:170)
at org.apache.lucene.queryparser.classic.QueryParserBase.parse(QueryParserBase.java:121)
This are my lines 111 and 112:
QueryParser parser = new QueryParser(Version.LUCENE_43, field, analyzer);
Query query = parser.parse(newLine);
What do I need to do to allow it to parse the "/"?
The query parser interprets slashes as the beginning/end or a regex query (as of 4.0, see documentation here).
So, to incorporate slashes into the query, you will need to escape them by adding a backslash (\) before them.
You can handle escaping with QueryParser.escape(String).
I encountered a similar problem when using '/' in lucene queries issued from the elastic search kibana dashboard. I was escaping the '/' characters as indicated in the documentation and still not getting any success. I think this is related to the template bug reported here : https://github.com/elastic/kibana/issues/789. Not sure yet, will update when we update the logstash components
I had a case where when using forward slash with wildcard it just wouldn't return any result, even if escaped it:
+(*16/17*)
+(*16\/17*)
The solution was to add double quote:
+("*16/17*")
+("*16\/17*")
I have many files with small differences. The included file contains this, which tries to differentiate on one part of a longer path:
<!--#if expr="${DOCUMENT_URI}=/internet/"-->Internet<!--#else-->Intranet<!--#endif-->
In the error log I get
AH01337: Could not parse expr "${DOCUMENT_URI}=/internet/" in /opt/apache/htdocs/ssi/time.shtml: Parse error near '$'
I find many variations on this theme, like no braces, parentheses around the inside of the quotes, space before the comment end or =~, but nothing helps. There doesn't seem to be a debug setting for mod_include, which would tell me what's wrong...
Another variant I found is
<!--#if expr='"${DOCUMENT_URI}"=~/internet/'-->
this gives no error. But it always chooses the else branch, likewise with REQUEST_URI, as though the variables were unset. But I can echo them fine. I also tried /.+internet.+/ in case it was anchoring this.
Since these are CGI variables I also tried loading cgid_module – no good either.
As of version 2.3.13, mod_include has switched to the new ap_expr syntax for conditional expressions in #if flow control elements.
Add the SSILegacyExprParser on directive to switch to the old syntax which is compatible with Apache HTTPD version 2.2.x and earlier.
http://httpd.apache.org/docs/current/mod/mod_include.html#ssilegacyexprparser
As many other people noted you can use the v("foo") style, but the examples given in the Apache 2.4 documentation (http://httpd.apache.org/docs/2.4/expr.html#examples) give this form:
<!--#if expr="%{DOCUMENT_URI} =~ /internet/"-->Internet<!--#else-->Intranet<!--#endif-->
Note the % instead of $ on the variable, and the =~ for regex match.
I've just tested this and it works fine.
(Or use SSILegacyExprParser on as also mentioned, to allow for backward-compatibility with the 2.2.x format. But I expect this compatibility will be removed at some point in the distant future..)
I got it working with:
<!--#if expr='v("foo") = "bar"' -->
foo is bar
<!--#endif -->
See Flow Control Elements
Newer Apache versions use ap_expr. I just wanted to add the relevant link: Apache docs. Note that the v function is not yet documented.
The variable resolves to a text string, so it needs to be enclosed in double quotes, and you need to escape those double quotes.... (warning this may be deprecated syntax - I used it on my old Apache 1 and just never changed it when upgrading):
<!--# if expr="\"$DOCUMENT_URI\"=/internet/" -->