{"id":96715,"date":"2017-07-31T07:00:00","date_gmt":"2017-07-31T21:00:00","guid":{"rendered":"https:\/\/blogs.msdn.microsoft.com\/oldnewthing\/?p=96715"},"modified":"2019-03-13T01:14:41","modified_gmt":"2019-03-13T08:14:41","slug":"20170731-00","status":"publish","type":"post","link":"https:\/\/devblogs.microsoft.com\/oldnewthing\/20170731-00\/?p=96715","title":{"rendered":"The redirection can come anywhere on the line, so watch out for those spaces"},"content":{"rendered":"

Wekcome to Batch File Week. Batch is probably one of the most hated programming languages that people are still writing new programs in. You hate it, but you have to deal with it. So just deal with it<\/a>. <\/p>\n

That said, here we go. <\/p>\n

A customer couldn’t understand why parenthesizing a few ECHO<\/code> statements resulted in a syntax error. <\/p>\n

\n

This version of the batch file works: <\/p>\n

\n@echo off\nset log=C:\\Space Path\n\necho Test >>%log%\\Output.txt\necho Redirection >>%log%\\Output.txt\n<\/pre>\n
On the other hand, this version, which should be equivalent, spits out a syntax error. <\/p>\n
\n@echo off\nset log=C:\\Space Path\n\n(\n  echo Test\n  echo Redirection\n) >>%log%\\Output.txt\n<\/pre>\n
The error is <\/p>\n
\nPath\\Output.txt was unexpected at this time.\n<\/pre>\n
If the syntax of the second command is illegal, then so too should the first, since they are basically the same thing. Why is one legal and the other not? <\/p>\n<\/blockquote>\n
Recall that you’re allowed to put the redirection operator anywhere on the line<\/a>, and when it is parsed, it is removed from the command line, and what remains needs to be a legal command. <\/p>\n
In the first batch file, the echo<\/code> statement expands to <\/p>\n
\necho Test >>C:\\Space<\/font> Path\\Output.txt\n<\/pre>\n
The redirection operator detector takes out the redirection operator and the file name (which due to the embedded space is parsed as merely C:\\Space<\/code>), leaving <\/p>\n
\necho Test Path\\Output.txt\n<\/pre>\n
Result: The string Test Path\\Output.txt<\/code> is placed into the file C:\\Space<\/code>. <\/p>\n
Now let’s look at the second batch file. The command being parsed is <\/p>\n
\n(\n  echo Test\n  echo Redirection\n) >>%log%\\Output.txt\n<\/pre>\n
which expands to <\/p>\n
\n(\n  echo Test\n  echo Redirection\n) >>C:\\Space<\/font> Path\\Output.txt\n<\/pre>\n
Again, the redirection operator detector takes out the redirection operator and the file name, leaving <\/p>\n
\n(\n  echo Test\n  echo Redirection\n) Path\\Output.txt\n<\/pre>\n
And that is a syntax error. <\/p>\n
In other words, the first batch file works because the extra junk you appended happened to be in a place where junk was legal. (It gets treated as more arguments to the ECHO<\/code> command.) But the second batch file puts the extra junk in a place where junk is not legal, and so it is rejected as a syntax error. <\/p>\n
If you take a step back, you’ll see that the real problem is that the batch file uses a path with spaces but fails to quote it properly. <\/p>\n
Whose idea was it to allow redirection operators to appear anywhere in the line? Answer: Ken Thompson, in version 2 of sh<\/code><\/a>. If you think this is a stupid feature, you can let him know<\/a>. <\/p>\n","protected":false},"excerpt":{"rendered":"
The operator vanishes.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-96715","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":"
The operator vanishes.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96715","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=96715"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/96715\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=96715"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=96715"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=96715"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}