When you add the additional spaces, you are effectively telling set to do show the value of a variable called "UNDEFINED " or %UNDEFINED % which is in fact undefined. You can see that the spaces will no longer be a concern if you do set "UNDEFINED" with the spaces after the double quotes. It is the same as doing set UNDEFINED =foo which will not return a variable for %UNDEFINED% bu instead for %UNDEFINED %
Here are examples of this:
set UNDEFINED=foo
set UNDEFINED =foo
when then run, without any additional spaces:
set UNDEFINED
The result is as expected.
UNDEFINED=foo
UNDEFINED =foo
but when you run it with the additional spaces
set UNDEFINED
the result no longer matches %UNDEFINED% due to the additional spaces you have given.
UNDEFINED =foo
Here we can show more how the matching works
set UNDEF=foo
set UNDEFI=foo
set UNDEFIN=foo
set UNDEFINE=foo
set UNDEFINED=foo
set UNDEFINED =foo
set UNDEFINED =foo
set UNDEFINED =foo
now see the results of all of these
set UN
set UNDEF
set UNDEFINE
set UNDEFINED
and obviously by adding the spaces:
set UNDEFINED
but if we add 4 spaces, representing a variable we've never set, then we will get un undefined variable result.
set UNDEFINED
Finally, to overcome this is to ensure we set variables correctly and double quote them to get the desired results.
set "UNDEFINED=foo"
set "UNDEFINED"
The latter set command will not care how many spaces you give after the double quotes ended, it will return any variable that has the the word UNDEFINED in it. i.e set "UNDEFINED"
The same goes for results using redirects > or pipe |. Specifically using redirect. everything before the > is seen as the string you want to redirect. Example:
echo foo >out.txt
Will result in out.txt containing foo including the space.
Therefore excluding the space is required, but that becomes an issue, should your string end with a number. i.e
echo foo2>out.txt
Which will redirect stderr to file.
So we overcome that again, by parenthesizing the code:
(echo foo)>out.txt
Therefore, given your examples, though piping to nul will return no result, unless you specify the type (stdout/stderr)
(SET UNDEFINED)2>nul|more
(SET UNDEFINED)1>nul|more
(SET UNDEFINED)>nul|more
EDIT
Again. Additional spaces, preceding the strings with spaces, will add spaces to the output. Again using echo
(echo foo | more)>out.txt
There is a space between foo and | if you look at the results in out.txt you will notice the space. The same applies for redirect > Hence the parenthesized blocks used in these instances to eliminate whitespace.
EDIT2
As per the screenshots you have provided. cmd uses the redirect in a way that it does not really care where you place it.
>out.txt echo foo
will result in:
foo
in the file. where adding spaces, will be appended to the file
>out.txt echo foo
will result in foo
Similarly to your example, which will echo anything you give in the line to the redirect.
echo foo>out.txt
or
echo foo>out.txt . will append to the file as redirect is really the key function here where it will append what you give it.
You will however notice that the redirect on its own, then giving the additional spaces before the command will not do this. This is simply because you ask the system to redirect a string to file where the spaces then become the command separators. So this:
>out.txt echo foo
will simply result in only foo in your output file.
So.. The best method to ensure we do not add these unwanted whitespace is to do:
>out.txt(echo foo)
