4

I was having an issue with a script so I went to ss64.com like I usually do to see what gems I might find to help me.

In looking at the page for the CALL command I came across this line:

Redirection with & | <> also does not work as expected.

However, that page and just about anywhere else I've looked does not explain how it works unexpectedly. I know that the | can do some unexpected things in general but I don't know about the others.

What is this unexpected function? Does it depend on how you use the CALL command (calling a label vs script)?

Community
  • 1
  • 1
Matthew Green
  • 10,161
  • 4
  • 36
  • 54
  • may be this is what Simon have on mind (better to ask on ss64.org) :http://www.dostips.com/?t=Snippets.ConditionalExecution – npocmaka Jan 30 '14 at 15:32
  • @npocmaka That page doesn't mention CALL or redirection. Is that what you meant to link to? I wouldn't consider conditional execution to be unexpected functionality. – Matthew Green Jan 30 '14 at 15:41
  • here is some details on redirection. http://www.robvanderwoude.com/redirection.php – Knuckle-Dragger Jan 30 '14 at 15:53
  • @Knuckle-Dragger Thanks for the link. However, I know how redirection works. I'm looking for how it doesn't work in relation to `CALL` based on the above statement. – Matthew Green Jan 30 '14 at 15:58

1 Answers1

2

I suppose Rob think of things like this:

call :func | more
exit /b

:func
echo line1
echo line2
exit /b

Or something like 

setlocal EnableDelayedExpansion
set var=Line2
( echo Line1
echo !var! ) | more

For this the explanation can be found at(you mentioned this)
SO:Why does delayed expansion fail when inside a piped block of code?

But redirection in the first step works with CALL as expected (and the other characters)

call echo Hello > output.txt

But if you try to use any of the special characters in the second expansion of the CALL command, the complete command will not be executed.
About the special effects of CALL for the batch parser is described at
SO:How does the CMD.EXE parse scripts? (especially phase 6)

set "myCmd=echo 1 & echo 2"
call %%myCmd%%

The double %% have the effect that the first expansion results in %myCmd% and the real expansion of the content will be done not until the second run of the parser, so the & have to be interpreted in the call context.

And also this will result in nothing (because of the parenthesis)

set "myCmd=echo Line1"
call (%%myCmd%%)

But this will obviously call a batch file named 1.bat

echo echo Hello > 1.bat
set "myCmd=echo Line1 && echo Line2"
call (%%myCmd%%)
echo End

This was discussed at dostips:CALL me, or better avoid call
Currently I suppose, CALL works somehow with tokens, but can't handle them in the correct way.

Community
  • 1
  • 1
jeb
  • 78,592
  • 17
  • 171
  • 225
  • I came across that page too in my search and included it in my question. I still don't know why he included the other redirection characters in his statement though if there isn't anything that they do differently. I was hoping an answer to this might help highlight a different issue I'm getting but it looks like I need to figure out how to formulate my other question after all. – Matthew Green Jan 30 '14 at 19:07
  • You are right, but I hope my edited answer will bring light into the other characters – jeb Jan 30 '14 at 19:17
  • Can you explain your new examples? I don't seem to be getting the same results. Did you mean to double the %'s because I get output on some of the examples when I use a single one. – Matthew Green Jan 30 '14 at 19:51
  • Also that link has some great stuff in it. I'm going to have to re-read it a few more times to wrap my head around everything you are trying in it. Thanks for your insight so far. – Matthew Green Jan 30 '14 at 19:52
  • @MatthewGreen I add some explanations about the double percents, I hope it's understandable – jeb Jan 30 '14 at 21:48