|
I endorse that. Expresso is a very good regex utility.
If there is one thing more dangerous than getting between a bear and her cubs it's getting between my wife and her chocolate.
modified 6-Feb-14 5:18am.
|
|
|
|
|
WTF??? I hate Trend. This is what I get when trying to download Expresso.
Trend Micro OfficeScan Event
URL Blocked
The URL that you are attempting to access is a potential security risk. Trend Micro OfficeScan has blocked this URL in keeping with the network security policy.
URL: http://www.ultrapico.com/ExpressoSetup3.msi
Risk Level: Dangerous
Details: Verified fraud page or threat source
 
|
|
|
|
|
Strange...I downloaded it here and ran a scan on the MSI and it showed nothing.
So I uploaded it to Dropbox: https://www.dropbox.com/s/3fwe3wtop741hpf/ExpressoSetup3.msi[^] - does that help?
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Ah thanks. I'll grab it from home since DB is also blocked at work.
|
|
|
|
|
They are a friendly bunch, aren't they? 
Do they allow you access to anything? 
Those who fail to learn history are doomed to repeat it. --- George Santayana (December 16, 1863 – September 26, 1952)
Those who fail to clear history are doomed to explain it. --- OriginalGriff (February 24, 1959 – ∞)
|
|
|
|
|
Yip, at least I can get onto CP, LOL.
No social sites, so I hope they don't investigate the full capabilities of CP   
|
|
|
|
|
gack! 
i suppose it's a right of passage everyone has to go through. but whew 
me, i avoid regex like the plague. finite state machines are so much easier to understand and maintain.
|
|
|
|
|
I had a bit help from an experienced colleague
The challenge is that it validates a Syslog-Timestamp.
Problem? Yes. Here are some examples of valid timestamps:
2014-2-5T21:36:14.315Z-1.5
2014-2-5T21:36:14Z-1
2004-2-28T21:36:14.315Z+1.75
2004-2-29T21:36:14.315315Z+0
You see the problem 
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Marco Bertschi wrote: it validates a Syslog-Timestamp
If it was written to some sort of log file by some application, why would you doubt it?
Edit: Now that I have perused the timestamp part of the RFC, I can state, "those are not valid timestamps".
This space intentionally left blank.
modified 5-Feb-14 17:31pm.
|
|
|
|
|
I am probably misinterpreting the RFC 5424 spec that you mentioned below and/or a case of complete RegEx ignorance, but from this site[^] it states that a timestamp can be a NILVALUE (where: NILVALUE = "-"). Do you account for this in your code?
|
|
|
|
|
You are right - The timestamp can be a NILVALUE!
The RegEx is used within the class SyslogTimestamp (see the discussion [^] why I don't use System.DateTime).
There is another class, called SyslogMessageHeader, which has a field of type SyslogTimestamp.
I plan to handle a NILVALUE as null, and also treat null objects as if they represent a NILVALUE.
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Marco Bertschi wrote: 2004-2-29T21:36:14.315315Z+0
Just curious, how could Regex invalidate this timestamp:
2005-2-29T21:36:14.315315Z+0
or:
2100-2-29T21:36:14.315315Z+0
|
|
|
|
|
I have updated the RegEx meanwhile:
new Regex(@"(\d{4})-(0?[1-9]|1[0-2])-([0-2]?\d|3[0-1])T?([0-1]?\d|2[0-3]):([0-5]?\d):([0-5]?\d)\.?(\d{0,6})?Z?([+-]?\d\.?\d?|\d{2}?|[0]?1[0-2]\.?\d?|\d{2}?)?", RegexOptions.IgnoreCase);
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
I can't agree more with your last statement!
|
|
|
|
|
You gotta love the regex. It is amazing.
I may not last forever but the mess I leave behind certainly will.
|
|
|
|
|
Marco Bertschi wrote: 2014-2-5T21:36:14.315Z+1.5
Almost, but not quite, entirely unlike ISO 8601.
This space intentionally left blank.
|
|
|
|
|
It's RFC 5424.
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Reading the RFC leads me to think that it is supposed to be ISO 8601-compliant, but the values you show are not:
0) Missing leading zeroes on single-digit values
1) Time zone should be Z or offset; not both
2) The offset should not have a decimal -- it's hours and minutes
This space intentionally left blank.
|
|
|
|
|
PIEBALDconsult wrote: 0) Missing leading zeroes on single-digit values
I know - I decided to allow missing leading zeros in my parsing application. Whatsoever, the returned value from the ToString method will add these leading zeros.
PIEBALDconsult wrote: 1) Time zone should be Z or offset; not both
PIEBALDconsult wrote: 2) The offset should not have a decimal -- it's hours and minutes
And here I can't quite follow you anymore. Do you mind explaining it?
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Marco Bertschi wrote: And here I can't quite follow you anymore. Do you mind explaining it?
See Wikipedia[^].
The 'T' date time delimiter may be omitted according to the standard and is often replaced by a space for better human readability (which does not conform to the standard). So you may replace [T] by [T ]?.
|
|
|
|
|
Thank you
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Good one. Now that you are all warmed up and stretched out, go and take a swing at POSIX time zone format[^] 
Quote: The following examples represent some of the customized POSIX formats:
HAST10HADT,M4.2.0/03:0:0,M10.2.0/03:0:00
AST9ADT,M3.2.0,M11.1.0
AST9ADT,M3.2.0/03:0:0,M11.1.0/03:0:0
EST5EDT,M3.2.0/02:00:00,M11.1.0/02:00:00
GRNLNDST3GRNLNDDT,M10.3.0/00:00:00,M2.4.0/00:00:00
EST5EDT,M3.2.0/02:00:00,M11.1.0
EST5EDT,M3.2.0,M11.1.0/02:00:00
CST6CDT,M3.2.0/2:00:00,M11.1.0/2:00:00
MST7MDT,M3.2.0/2:00:00,M11.1.0/2:00:00
PST8PDT,M3.2.0/2:00:00,M11.1.0/2:00:00
Soren Madsen
"When you don't know what you're doing it's best to do it quickly" - Jase #DuckDynasty
modified 5-Feb-14 17:27pm.
|
|
|
|
|
Where is the :Exorcism: Emoticon?
Clean-up crew needed, grammar spill... - Nagy Vilmos
|
|
|
|
|
Welcome to the dark side. 
|
|
|
|
|
Congratulations, Marco; I believe learning, and mastering, something new is one of the very best things in life !
It would be interesting to debate (perhaps on the C# forum ?) the short- and long- range cost/benefits of implementing a complex mini-parser like this using RegEx vs. "brute-force" string parsing, where "cost/benefits" would be looked at from different perspectives: say, from the perspective of a manager of programmers vs. a front-line programmer's perspective.
Of course the question of "constraints" immediately arises: what makes parsing the range of inputs you show more difficult is:
1. possible ambiguity of the "-" glyph: it is a separator for the Date component, and a sign-indicator for the time-offset.
2. possible ambiguity of the "." glyph: it is a presence/absence indicator for milliseconds, and a decimal-point for the time-offset.
If, you, the creator, have control over all possible inputs, and can ensure there will always something like ".0Z" indicating no milliseconds, and there will always be some other character than "-" separating year, month, day, then, obviously parsing becomes so much more simple.
However, maybe "control" is an academic issue here because the standard you are coding to allows such latitude in input format; I don't know anything about the RFC you are using.
As an experiment, I timed how long it took me to create a non-RegEx solution to parsing your sample data: about thirty minutes (code on request).
Since this was done early AM my time (GMT +07), and I was not fully caffeinated, perhaps I could have done this in twenty minutes, or less, later in the day, or evening.
Anyone up for debate ?
“But I don't want to go among mad people,” Alice remarked.
“Oh, you can't help that,” said the Cat: “we're all mad here. I'm mad. You're mad.”
“How do you know I'm mad?” said Alice.
“You must be," said the Cat, or you wouldn't have come here.” Lewis Carroll
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
