How do I give this command?

[Charles Dye]

That helps the versions of the commands that involve redirection:
...But remove the redirection and the commands fail:

You're right. I tested with redirection, but never thought to test it without; and then compounded my error by forgetting to put the redirection in my post. Oops!

 

[Avi Shmidman]

In trying to figure out why Charles' command worked with redirection but not without, I noted that the ^ seems to have a different effect depending on whether it is in the last part of the command line or not:

(1)
[C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Apps]echo "foo" | echoargs ^"\""
Arg 0 is <^">

(2)
[C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Apps]echo "foo" | echoargs ^"\"" > a.txt
[C:\Windows\System32\WindowsPowerShell\v1.0\Modules\Apps]type a.txt
Arg 0 is <">

That is - when it is in the last part of the command line, after a pipe, it is treated as a literal! But when it is followed by redirection, it is considered an escape character.
Now, the TCC help file also notes something in this regard:
"WARNING: Escape characters are considered to be normal characters on the right side of a pipe."

I think that this is what is happening here. In example (1) above, the escape character is treated as a normal character, on the right side of the pipe, as noted in the help manual.
However, in example (2), for some reason, the help file's warning does not hold; it seems that once it has to be redirected, it is treated as an escape character, even if it is to the right of the pipe.

Earlier in this thread I noted that the command:
echo "foo" | findstr ^"\""
works even without the redirection. Now I understand why: it is because findstr takes a regular expression. Here, findstr is given the string: ^". In the regular expression, the ^ character indicates the start of the string! So that's why it just happens to work here.

Rex, I think we need some clarification as to what the help file means when it says that "Escape characters are considered to be normal characters on the right side of a pipe." As we see here, this does not seem to be entirely consistent. Furthermore, within cmd.exe, the escape character seems to always function as an escape character, even to the right side of a pipe, so why should it be different in TCC?

We can demonstrate the difference between cmd.exe and TCC on this point with a text file (a.txt) containing three lines:
this is a test
this is a test
this is a test
And let us now run:
type a.txt | findstr ^t
In cmd.exe, this returns all three lines (because the ^ is an escape character that is eliminated)
But in TCC, this returns just the first line (because the ^ is passed on to findstr as part of the regex)

UPDATE with additional info:
1] Above I noted that ^ is treated as an escape to the right of the pipe if there is redirection. This is true as well if there is an additional pipe:
[C:\]echo "foo" | echoargs ^q^q^q
Arg 0 is <^q^q^q>
[C:\]echo "foo" | echoargs ^q^q^q | findstr ">"
Arg 0 is <">

In the first example, all carrots to the right of the pipe are taken literally, as per the help file's warning. But in the second example, the carrots to the right of the first pipe are treated as escape characters, since an additional pipe follows.

I'd also note that it doesn't have to do with the physical positioning of the pipe/redirection on the line; even if the redirection is noted before the carrots, it still forces the carrots on the right of the pipe to be taken as escape characters, as in the following lines:
[C:\] echo "foo" | echoargs > a2.txt ^q^q^q
[C:\] type a2.txt
Arg 0 is <">

As of now, it seems: the escape character is treated literally to the right of the pipe unless there is additional pipe or redirection, in which case the escape character will be treated as an escape character.

 

[Stefano Piccardi]

c:\users\vefatica\desktop> type folders.reg | grep Name | egrep -v "zedN|arsing" | cut -c9- | tr -d "\"" > v:\FolderNames.txt
tr: error: Can not open file 'v:\FolderNames.txt'

It's the quoting. How do I correctly quote TR's second argument? The TR command is supposed to be:

 tr -d "\""

I tried escaping (^) the literal quote with up to 8 escape characters!

You could get the job done with an octal escape sequence:

C:\>cat | grep Name | egrep -v "zedN|arsing" | cut -c9- | tr -d "\042" >
c:\temp\FolderNames.txt
DirName=C:\
DirName="D:\"
^Z

C:\>type c:\temp\FolderNames.txt
C:\
D:\

 

[epement]

c:\users\vefatica\desktop> type folders.reg | grep Name | egrep -v "zedN|arsing" | cut -c9- | tr -d "\"" > v:\FolderNames.txt
tr: error: Can not open file 'v:\FolderNames.txt'

It's the quoting. How do I correctly quote TR's second argument? The TR command is supposed to be:

 tr -d "\""

As others have pointed out, one solution is to hide the internal double-quote by TCC's quoting:
echo "test me" | tr -d "\%="" >v:\FolderNames.txt

As Stefano pointed out, another solution is to use the octal equivalent for the double-quote:
echo "test me" | tr -d "\042" >v:\FolderNames.txt

A third solution is to use sed to massage the input and write the file:
sed -r "/Name/!d; /zedN|arsing/d; s/^.{8}//; s/\"//g; w v:\FolderNames.txt" folders.reg

GNU sed will also process escaped characters in octal (\o42), decimal (\d34), or hex (\x22), any of which will avoid inserting another double-quote character in the line. If you don't want to see the output of sed on the console, but still want the output in a file, change -r to -nr. HTH.

Eric

 

[MaartenG]

Never mind; I was wrong. Skip this, please ...

In CMD.exe the FINDSTR command would be: findstr """ (That's 3 double quotes in a row).
So all that has to be done, is to "escape" the middle double quote with ^" so that TCC won't parse it and a literal " will be sent to FINDSTR:

[C:\Temp]cd TEST_TCMD
[C:\Temp\TEST_TCMD]echo "foo" | findstr "^"" > foo.txt
[C:\Temp\TEST_TCMD]type foo.txt
"foo"
[C:\Temp\TEST_TCMD]echo "foo" | findstr "^""
"foo"
[C:\Temp\TEST_TCMD]

Tested in TCC/LE and TCC 20.0.25

EDIT: Actually not true: FINDSTR *does* receive the "^"".