In the documentation for log4php (at http://logging.apache.org/log4php/docs/appender/layout.html) there is the following line for the linebreak token in the layout pattern:
%n A line break. Note that
... and that's it! What should the rest of the line say?
(I think it's a reference to the linebreak character being \n or \r\n depending on the native OS.)
It is an error, "Note that" should have been removed. My guess is, it has not been corrected when the docs are ported from log4j to log4php.
log4php transforms %n with PHP_EOL. This should use lineendings in a crossplattfrom friendly way
(see also: http://svn.apache.org/viewvc/logging/log4php/trunk/src/main/php/helpers/LoggerPatternParser.php?view=markup )
Hope that helped!
Cheers
Christian
The text is actually:
Note that a line break will not be printed unless explicitely specified.
From: http://logging.apache.org/log4php/docs/layouts/pattern.html
Related
I know there are a lot of resources with regex for it. But I could not find the one I want.
My problem is:
I want to remove one line comments (//) from obj-c sources, but I don't want to break the code in it. For instance, with this regex: #"//.*" I can remove all comments, but it also corrupts string literal:
#"bsdv//sdfsdf"
I played with non-capturing parentheses (?:(\"*\")*+), but without success.
Also I found this expression for Python:
r'(\".*?\"|\'.*?\')|(/\*.*?\*/|//[^\r\n]*$)'
It should cover my case, but I've not figure out how to make it work with obj-c.
Please, help me to build proper regex.
UPDATE: Yeah, that's a tough one, I know there're a lot of caveats, other than the one I described. I would appreciate if someone post regex that only fix my issue. Anyway, I gonna post my solution, without regex soon, I hope it will be helpful for anyone who struggling with such problem too.
Try this regex:
(?:^|.*;(?!.*")|#(?:define|endif|ifn?def|import|undef|...).*)\s*(//[^\r\n]+$)
Demo
http://regex101.com/r/jT4xC8
Description
Discussion
Besides all the warnings expressed in the comments, I assume that a single line can appear in two distinct cases:
Case 1: Alone on its line preceded or not by blank chars
Case 2: Not Alone on its line preceded or not by blank chars, and other chars.
In the first case, we match the beginning of the line (^ with /m flag). Then we search zero or more blank chars (\s*) and finally the single line comment: //[$\r\n]+$.
In the second case, if there are other chars on the line, they form statements. Any statement is ended by a semicolon ;. So we search the last statement and its corresponding semicolon .*;(?!.*"). Then we search the single line comment. Those other chars can be also preprocessor statements. In this case, they are introduced by a sharp #.
One important keypoint is that I assume the code passed to the regex is a code that compiles.
There is more
Don't forget also to add some other pre-processor directives that may apply in your case. Check this SO answer: https://stackoverflow.com/a/18014883/363573
I'm using IDEA 13.0.1. A unit test is failing because of some line separator stuff. But when I try to compare the two results, IDEA says "Contents have differences only in line separators".
And I can't find a setting where I can say show me these differences. Is there one?
I ran into the same issue, I couldn't find a way to show the difference by clicking show differences, but if you put a break point and look at the strings, they have the line separator written out. For me one string had \n and one had \r\n. \r is also a possible line separator.
I ran into the same problem recently. I found a workaround for it, is not that pretty but did the job:
yourString.replaceAll("\n", "").replaceAll("\r", "");
The key is in what #user1633977 said.
To solve this problem, always use System.lineSeparator() to create your separators. That way they will always be the same and will be OS-independant.
(Remember that different OS can use different symbols as line separators).
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/" -->
I'm unable to comment-out and compile the following line of code with /* */, within the XCode editor. I distilled this example down from a more complex string used in an XPath query:
the string itself seems fine:
NSString* s = #"//*//";
won't compile for me:
/*
NSString* s = #"//*//";
*/
XCode 4.4. I'll file a radar if anyone can confirm I'm not being stupid.
EDIT: nice to see that the SO syntax highlighter also exhibits an issue with this...
EDIT: okay, I filed a bug report with Apple. Thanks.
EDIT: Per Rob's answer below, this is NOT a bug :) Thanks for explaining it, Rob; totally makes sense now.
This is not a compiler bug. The double-quote character " has no special meaning inside a comment, so the preprocessor doesn't pay any attention to it. The preprocessor just ends the comment as soon as it sees the */ characters.
The best way to comment out a section of code is to put // at the beginning of each line. A // comment ends at the next newline. Xcode has a menu command (shortcut: ⌘/) that will comment or uncomment your selected lines by inserting or removing // at the start of each line.
It detects and end comment in #"//*//"; I don't know of any editor that allows nesting of block comments (I know that's not what you're doing, but same issue). Notice how even the syntax highlighter on SO screws up.
I am using yaml-cpp in my project, and find out that an anchor name is only allowed to consist of AlphaNumeric characters. I failed to find such restriction in the spec, only found this:
Anchor names must not contain the “[”,
“]”, “{”, “}” and “,” characters
Can you please indicate if this is yaml-cpp implementation specificity or there is information in the spec, which I missed?
Thanks!
You're absolutely right - and as of revision 429, anchor parsing is more relaxed. Thanks for the note!