In the last video I kind of punted the output from our linter, so let's take a minute to revisit that. Let me re-enable this output and we'll run our linter again. And right now we don't have any syntax errors, so let's force one. If we open our someother file again, let's take off this proper escaping, jump back out to the command line and run our linter again. Now we're getting some output, so let's take a look. I've always found this to be a little bit annoying. As developers, we already know that when we run this with the -l option, we of course are going to have a parse error.

As developers, we already know that when we run this with the -l option, we of course are going to have a parse error. We also know that means it's a syntax error. And the things that we care about, the file that it's part of and the line number that it's on, are at the very end of a rather noisy description. So I think it makes sense to take a minute and clean up this output. This also gives me the opportunity to demonstrate regular expressions, which are going to be a very powerful tool when you want to parse or extract any kind of data from a string. And at the end of the day, all code is really just a string. So if we do have an error, let's take a minute to parse the error.

And at the end of the day, all code is really just a string. So if we do have an error, let's take a minute to parse the error. And we'll pass this the output. So let's make a little function down here for parseError. And it's going to take an array of the lines. And we'll probably want to return an array. Now looking back at our lines, we can see that the one we really care about is going to be the first element in this array. Again, everything else is kind of just noise or repeats the same information that's already in this first line.

Again, everything else is kind of just noise or repeats the same information that's already in this first line. Ultimately, I just want to return the line and the error. All right, so let's see if we can extract those. Again, we'll do this with a preg_match. So the first argument is going to be the pattern for the regular expression. The next argument is going to be the subject or the line that we care about, which we said was the first one or line 0. And finally, we're going to want those matches. That's ultimately what's going to give us line and error.

And finally, we're going to want those matches. That's ultimately what's going to give us line and error. All right, now for the tricky part. Let's talk about the regular expression. First we need to delimit our pattern. The traditional way to do that is with some / (slashes). Inside here is where we're going to extract the things that we care about. So let's go back and take a look. What's really important in regular expressions is to find ways to anchor your patterns. So we know that our lines always going to start with this parse error followed by some

So we can add a plus, meaning one or more. All right, that gets us to here. Now we need another anchor point. And we know that anytime we have an error, it's always going to have more space followed by the file name. So let's set up that other anchor point. So in this case, we don't really care what's in here. We can just say .*, meaning anything. And again, one or more of those. More space, in, and then more space.

And again, one or more of those. More space, in, and then more space. All right, this should get us to the file name. Now we're going to have anything followed by .php. So that gives us another anchor. We can again say any character, one or more, followed by an explicit ., so we'll escape it, php. And now for our final anchoring, and what we care about, is the line number. Now we can say one or more spaces, on, one or more spaces, line, one or more spaces. And then, in this case, instead of using ., we know that that's an integer, and we can

So let's go back and review our expression. We've taken literal pieces from our error message to give us anchor points. We start with php parse error, followed by some kind of space, and then anything between the next set of spacing, all the way up until the file name, is something we care about. In this case, it's the error message. And we're actually going to capture that by surrounding it with parentheses. Again, this is followed by the file name, which is any set of characters ending in a literal .php, followed by some spaces, the word on, more spaces, the word line, more spaces, and then something else we want to capture, in this case, which is the line number. So let's see how we're doing by outputting these matches.

spaces, and then something else we want to capture, in this case, which is the line number. So let's see how we're doing by outputting these matches. And since these variables are still undefined, let's just comment this out. All right, going back to the command line, let's give ourselves some breathing room and we'll run the linter again. Okay, so we're actually getting some runtime errors from our type hint. That's not a big deal. We still get our output of the matches. Now notice that matches zero is always going to be the entire thing that it matches. And the rest of the items in the array are going to be each one of those capture groups.

Now notice that matches zero is always going to be the entire thing that it matches. And the rest of the items in the array are going to be each one of those capture groups. So in this case, the first one being the message that we care about, and the second one being the line number. There's two more things I'd like to do here. This syntax error, again, is just a bit of noise. It'd be really nice if we could just get to the meat of this message, which is the unexpected identifier portion. What we can do is we can actually pull in an optional group here and say literal syntax error, comma space.

So let's take a peek. Oh, look at that. Syntax error. Okay, so I have a little typo here and let's go back up and take out this printr so we can really just focus on this printr for matches. All right, let's clear this out yet again. And there we go. Okay, great. So php parse error. The first one is that syntax error.

So php parse error. The first one is that syntax error. And now we've gotten to just the meat of the actual issue. And just as before, we still have our line number. One last little tweak here. I don't actually care about this capture group. I just need to wrap it into something so I can say that this is the part that is optional. So let's actually not capture this by using this ?: syntax to say that this is a group that we actually don't care to capture. If we run this again, we'll see that we're back down to just those three elements and

So again, it's a good idea for anything open ended, we make sure to make it non-greedy. So let's go and do the same thing with this other one, even though we're not capturing it. Alright, we'll output these one last time and everything is as we expect. So now that we have this errorMessage trimmed down to the way we like, let's go ahead and return the proper items. So let's get rid of this matches, we'll reinstate this return and we'll use matches[2] for the line number and matches[1] for the error message. Go back and throw on our typeHint. And up here, we should be able to deconstruct those into line and error.

Go back and throw on our type hint. And up here, we should be able to deconstruct those into line and error. And quickly we'll just dd(line); and error. So let's make sure that we're getting what we expect, and we do. We get a 3 and the error message. Alright so the final thing we'll want to do here is just go ahead and display that in again a more user-friendly way, something that's not so noisy. And we'll need to pass this in the absolute path, the line number, and the error message. Alright, let's go back down here and make another function to display error. And this is going to take a string for the path, an int for the line, and a string for...

Alright, let's go back down here and make another function to display error. And this is going to take a string for the path, an int for the line, and a string for the error. So what I'd like to do is echo out the path, let's echo out a line break, and let's echo out just kind of a simple bullet pointed list. So we'll say two spaces, a space, and we'll say line, let's output the line number, and then we'll output a colon, another space, and the error. And let's finish that off with a couple line breaks. Alright, cool. Let's see what this looks like.

Alright, cool. Let's see what this looks like. Let's clear our screen, run the linter again, and there we go, that's actually a little bit cleaner. The only part I don't like about this is the absolute file path. So let's see if we can clean that up a little bit. So let's scroll back up here, and this is actually a good opportunity to do a little bit of refactoring. In the end we actually don't need this absolute file path, so let's just use the relative file path, we'll change the name here to path, and let's go ahead and get these other

In the end we actually don't need this absolute file path, so let's just use the relative file path, we'll change the name here to path, and let's go ahead and get these other ones and call them path as well. Alright, let's clear this out and one more time, see what this looks like, and there we go, some other file.php, a little bulleted list, line number three, unexpected identifier s. I think this looks much better, and as a developer this is, in my opinion, a lot easier to read than that really tierce line that php -l gives you. So it was a little extra work, and while this won't be necessary for our linter script in general, I think it was a good addition for a little quality of life improvement and something.