Why is this GREP going wrong?

[taripo]

[edit by Ed Dyreen] added code tags.
If I remove the >g then it outputs fine, but I want to redirect to a file called g.

Notice that it -works- when I remove the >g

Code: Select all

W:\>echo "f" | grep -oP "(?=\")."
"
"

W:\>echo dsftree="f"dfd | grep -oP "(?=\")."
"
"

W:\>echo a"f"a | grep -oP "(?=\")."
"
"

W:\>

See, that is the output it gives and I have no issue with that.

I just want to redirect that output into a file.

This is not a regex question.

What is going on here that the redirect fails?

Code: Select all

W:\>echo "f" | grep -oP "(?=\")." >g
grep: >g: Invalid argument
The process tried to write to a nonexistent pipe.

W:\>echo a"f"a | grep -oP "(?=\")." >g
grep: >g: Invalid argument
The process tried to write to a nonexistent pipe.

W:\>echo dsftree="f"dfd | grep -oP "(?=\")." >g
grep: >g: Invalid argument

W:\>

--

interestingly this doesn't work (putting round brackets around it)

Code: Select all

W:\>(echo dsftree="f"dfd | grep -oP "(?=\")." )
." ) was unexpected at this time.

W:\>

Here's another thing I tried, no luck

Code: Select all

W:\>(echo dsftree="f"dfd | grep -oP "(?=\").") >g
.") >g was unexpected at this time.

W:\>

What's going on and what can I do about it? To redirect the output to a file!

[foxidrive]

You have mismatched double quotes by the look of it.

Can grep use /x22 to replace a quote like SED can?

[taripo]

Yes you can do \x22 and that's nice, and kind of a solution, though not quite what I meant to ask.

It doesn't explain why the line I used is going wrong when I add >g.

I don't think the quotes look mismatched, since, if I remove the >g, then it outputs. My question is why when I add >g, does it not work?

But if it's something to do with the quotes, especially if it was quotes mismatching as you suggest, and even if it isn't, then it might be fixable somehow without specifying \x22

[foxidrive]

The question now is: does replacing the \" on the RH side with /x22 fix the redirection problem?

[taripo]

The question now is: does replacing the \" on the RH side with /x22 fix the redirection problem?

If the problem was how do I redirect that output to the file, then yes. Hence as I said, it's kind of a solution. (and you meant \x22 not forward slash). It's a nice thing.

But what I was asking, was why isn't the redirection working(with that line as I wrote it), and i'm asking how I can fix it without changing " to \x22. I want to know what's going wrong with that line I used, and why.

[foxidrive]

Double quoting is a large part of cmd parsing and usage.

The fact that mismatched double quotes stopped redirection is the symptom. The reason will only be known by someone who could be bothered delving into CMD parsing rules and loads of testing, or maybe has the source code.

I have to do it when using SED - it just is.

[taripo]

Double quoting is a large part of cmd parsing and usage.

The fact that mismatched double quotes stopped redirection is the symptom. The reason will only be known by someone who could be bothered delving into CMD parsing rules and loads of testing, or maybe has the source code.

I have to do it when using SED - it just is.

The symptom is the error message.

The problem obviously includes something to do with double quotes. Of course, I don't have the wrong number of quotes.

There are experts here that know/have worked out enough about how cmd parses things (obviously without having the source code), but there are such people that could know, hopefully they can chime in.

jeb, probably knows. or dave benham

[Ed Dyreen]

'
Seems like you are having problems with the double quotes, they switch the parsers behavior.

Code: Select all

@echo on &prompt $G

echo ^^^^ "^^^^" |>g ( grep -oP "(?=\"^^^).^" )
type g

pause
exit

Code: Select all

>echo ^^ "^^^^" | (grep -oP "(?=\"^)."  ) 1>g

>type g
-oP "(?=\")."

>pause
Druk op een toets om door te gaan. . .

Code: Select all

>( echo. -oP "(?=\"^).^" )
 -oP "(?=\")."

>

Special characters have to be escaped if they are not quoted.

[taripo]

what's your solution then ed with grep, for if I wanted it quoted?

W:\>echo dsftree="f"dfd | grep -oP "(?=\")." >g
grep: >g: No such file or directory

W:\>

I can see what is happening, the >g is going to grep as a second parameter.

But I don't know why it is doing that?

By the way,
I see that with the example I used, I can remove the quotes from around it and escape the first round bracket. (so, round brackets are escaped, made literal, by escaping the first one and leaving the second as it is). and I see echo seems to show what grep would see, so I see from your post that echo can help see what is escaped and what grep sees.

[Ed Dyreen]

But I don't know why it is doing that?

That indicates that the quoted switch is turned on which is what you don't want.

what's your solution then ed with grep, for if I wanted it quoted?

from commandline

Code: Select all

2>nul del /f /q g &echo."" |grep -oP ^"^(?=\")" >g &type g

from batch

Code: Select all

2>nul del /f /q g &echo."" |grep -oP ^^^"^^^(?=\"^)^" >g &type g

echo can help see what is escaped and what grep sees.

[taripo]

^"(?=\")." <-- works but why?

and howcome those outside quotes are escaped with a ^ and not a \ ?

And given that whether it is ^"(?=\")." or "(?=\")." , grep still gets "(?=\")." What is it that Windows cmd.exe does with "(?=\")." causing it to mess up, that it wasn't doing with ^"(?=\")." ?


Why, with
C:\>echo aaf="4"aa|grep -oP "(?=\")." >g
grep: >g: Invalid argument

C:\>


Why is >g being given to grep as an argument.
(and adding brackets doesn't help)
C:\>(echo aaf="4"aa|grep -oP "(?=\").") >g
.") >g was unexpected at this time.

C:\>

I'm glad that changing "(?=\")." to ^"(?=\")." fixes it (as does removing the quotes altogether.. but why do the quotes unescaped cause those problems?

[Ed Dyreen]

^"(?=\")." <-- works but why?

http://stackoverflow.com/questions/4094699/how-does-the-windows-command-interpreter-cmd-exe-parse-scripts

[taripo]

i'll take back where I wrote

Code: Select all

^"(?=\")." <-- works but why?

Still not sure howcome those outside quotes are escaped with a ^ and not a \ ?

To the main point i'm asking regarding, I'm aware of that post where jeb works out the rules for the cmd.exe parser, but it might be a bit beyond me to absorb it all.

As far as parsing is concerned, I know that whether it is ^"(?=\")." or "(?=\")." , grep still gets "(?=\")."

I'd like to know what it is that Windows cmd.exe does with "(?=\")." -causing it to mess up-, that it wasn't doing with ^"(?=\")." ?

and what rule of jeb's would describe why >g was being seen as an argument to grep.. And why couldn't I correct it with parentheses around the whole left hand side of >g ?

[Ed Dyreen]

'
It's not that cmd is messing up, you are having a problem with

I'd like to know what it is that Windows cmd.exe does with "(?=\")." -causing it to mess up-, that it wasn't doing with ^"(?=\")." ?

phase 2 (Special chars, "<LF>^&|<>()"): Look at each character.
This '"(?=\")."' will set, unset and finally set the quoted flag
Because cmd is now in it's quoted mode it will take everything that follows as literal until it encounters another quote.
This is why when you escape one of the double quotes '^"(?=\")."'
This will set and unset the quoted flag which is what you need in order to append another non-literal command.

and what rule of jeb's would describe why >g was being seen as an argument to grep.. And why couldn't I correct it with parentheses around the whole left hand side of >g ?

Again, phase 2 (Special chars, "<LF>^&|<>()"): Look at each character.

[foxidrive]

You have mismatched double quotes

See? I told you so.