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.