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/" -->
Related
I exported and imported posts from our old wordpress website into our new wordpress website. I've got all sorts of issues with backslashes messing up the formatting in the browser. How can I fix this?
Here are some examples of what it looks like in post_content:
<img class=\\\"aligncenter wp-image-40904 size-full\\\" title=\\\"Mom\\\'s Blog - banner\\\" src=\\\"/uploads/moms_blog_banner_v2.png\\\" alt=\\\"Infusing Love: A Mom\\\'s View\\\" width=\\\"744\\\" height=\\\"242\\\" />\nOprah Winfrey has been quoted, \\\"I always say moms have the toughest job in the world.\\\" Everybody knows Oprah is right more often than not.\nWhat would the job description for a mom with a child of a bleeding disorder look like? I think maybe it would be something along these lines:\n <img class=\"\\"wp-image-55122\" alignright\\\"=\"\" src=\"\\"/uploads/Ana_Luis_July23.jpg\\\" alt=\"\\"\\\" width=\"\\"350\\\" height=\"\\"350\\\">
I've tried several variations of set post_content=replace(post_content,'\','') but replace seems to not match 's whether they are escaped or not. I need to replace \n with a br and then all 's with nothing. Note: mysql MariaDB on CentOS Linux
On Windows systems, paths with included spaces are allowed. For our framework built on top of Karate, I would like to robustly handle such eventualities. But if there are spaces in the feature file path given to karate.options, Karate interprets the value as multiple paths, as this is by design.
So I've already tried enclosing the path with single and double quotes, as well as all possible pairs of parentheses. Unfortunately, none of these seem to work. Is there no syntax to express this intention?
The code below, yields the output of "apple banana cantaloupe" (spaces) .
<!--#set var="x" value="apple banana cantaloupe" -->
<!--#echo var="x" -->
Here's my example: http://4mo.st/my-question.shtml
Looking for a way to get "applebanadacantaloupe" (no spaces). Is there any native functionality within Apache SSI to accomplish this? An equivalent of something like concat or trim? I cannot find anything in the documentation but perhaps someone out there has solved a similar problem?
Unfortunately, there isn't anything in the include module which will provide this functionality.
From the summary of the module's documentation:
The processing is controlled by specially formatted SGML comments,
referred to as elements. These elements allow conditional text, the
inclusion of other files or programs, as well as the setting and
printing of environment variables.
I am trying to install drupal in a subdirectory on my bluehost hosted website...
It's a HUGE pain
I'm thinking the following lines from the .htaccess is the problem. When I currently navigatoe to mysite.com/subdir/install.php I get a 403 error. However, when I take out "deny" from the lines below, I cease to get that error, so I suspect that this line is causing all the trouble.
My question is, can someone help me understand what is happening in the following code? Especially if you can break it down by component.
<FilesMatch "\.(engine|inc|info|install|make|module|profile|test|po|sh|.*sql|theme|tpl(\.php)?|xtmpl)(|~|\.sw[op]|\.bak|\.orig|\.save)?$|^(\..*|Entries.*|Repository|Root|Tag|Template)$|^#.*#$|\.php(~|\.sw[op]|\.bak|\.orig\.save)$">
Order allow,deny
</FilesMatch>
FilesMatch allows you to match files using a regular expression.
On your above FilesMatch you have 4 sets of regular expression where the 1 set have an secondary optional set.
Basically what it is doing is forbidden access (error 403) to any of the files found that are described on your sets of regex.
For example:
\.(engine|inc ...)$|
Means if the file ends with .engine or .inc or ... rest of the rule, deny access to it.
Then at the end of the first set of rules you have a | which like the above example, stands for OR so if the first set of rules were not match, it starts the second one, which is slight different.
^(\..*|Entries.*|Repository)$
Here it does the opposite, it matches if the file starts and end with a given keyword, so for example:
If file starts with . followed by anything the (.*) means anything else for example .htaccess or starts with Entries followed by anything or is exactly Repository or ... till the end.
Then the next rule ^#.*#$, this one means the file starts and ends with a # as # its treated literally
And the last set of rules does the same of the first verify if file ends with those given extensions.
If you want to know more then I suggest you to learn more about Perl Compatible Regular Expressions (PCRE)
I am using CMake to build my project and I have the following line:
include_directories(${LLVM_INCLUDE_DIRS})
which, after evaluating LLVM_INCLUDE_DIRS, evaluates to:
include_directories(C:\Program Files\LLVM\include)
The problem is that this is being considered two include directories, "C:\Program" and "Files\LLVM\include".
Any idea how can I solve this problem? I tried using quotation marks, but it didn't work.
EDIT: It turned out that the problem is in the file llvm-3.0\share\llvm\cmake\LLVMConfig.cmake. I enclosed the following paths with quotation marks and the problem was solved:
set(LLVM_INSTALL_PREFIX C:/Program Files/LLVM)
set(LLVM_INCLUDE_DIRS ${LLVM_INSTALL_PREFIX}/include)
set(LLVM_LIBRARY_DIRS ${LLVM_INSTALL_PREFIX}/lib)
In CMake,
whitespace is a list separator (like ;),
evaluating variable names basically replaces the variable name with its content and
\ is an escape character (to get the symbol, it needs to be escaped as well)
So, in your example, include_directories(C:\\Pogram Files\\LLVM\\include) is the same as
include_directories( C:\\Program;Files\\LLVM\\include)
that is, a list with two items. To avoid this, either
escape the whitespace as well:
include_directories( C:\\Program\ Files\\LLVM\\include) or
surround the path with quotation marks:
include_directories( "C:\\Program Files\\LLVM\\include")
Obviously, the second option is the better choice as it is
simpler and easier to read and
can be used with variable evaluation like in your example (since the result of the evaluation is then surrounded by quotation marks and thus, treated a single item)
include_directories("${LLVM_INCLUDE_DIRS}")
This works as well, if LLVM_INCLUDE_DIRS is a list of multiple directories because the items in this list will then be explicitly separated by ; so that there is no need for unquoted whitespace as implicit list item separator.
Side note:
When using hard-coded path-names (for whatever reason) in my CMake files, I usually uses forward slashes as directory separators as this works on Windows as well and avoids the need to escape all backslashes.
This is more likely to be an error at the point where LLVM_INCLUDE_DIRS is set rather than a problem with include_directories.
To check this, try calling include_directories("C:\\Program Files\\LLVM\\include") - it should work correctly.
The problem seems to be that LLVM_INCLUDE_DIRS was constructed without using quotation marks. Try for example running this:
set(LLVM_INCLUDE_DIRS C:\\Program Files\\LLVM\\include)
message("${LLVM_INCLUDE_DIRS}")
set(LLVM_INCLUDE_DIRS "C:\\Program Files\\LLVM\\include")
message("${LLVM_INCLUDE_DIRS}")
The output is:
C:\Program;Files\LLVM\include
C:\Program Files\LLVM\include
Note the semi-colon in the first output line. This is a list with 2 items.
So the way to fix this is to modify the way in which LLVM_INCLUDE_DIRS is created.