I noticed some strange behavior in redirecting stdout to files with special characters in 'the name'.
The ones I've found:
echo.>f,test produces a file called
f, containing the text
,test. Same with
<space> (obviously the comma changes to whatever character).
echo.>f.:test produces a file of zero bytes called
F~000%HK. The first character in the output file name corresponds to the redirect 'file name' between the redirect character and
.: capitalized (I believe the
. is ignored/removed for the same reason trying to create a file called
f.... just creates a file called
f). I have no idea what the rest means, as changing the text after the 'file name' changes nothing. i.e.
echo.>f.:nope still produces the empty file
Another example of the same thing;
echo.>test.:test produces a file of zero bytes called
In Batch the latter example produces the same result of empty files with the strange names, but the former example instead produces a file called
f containing an empty line.
Any explanation / 'anomalies' to add?
, ; = <space> <tab> are standard delimiters so
echo.>f,test is the same as
echo. ,test>f . You can see what really happens in this case from a batch batch file with turned on
echo on before the redirection). The redirection syntax could be tricky as it takes for a file only the first argument and is with higher prio than the commands. You can change the result with
As for the
echo.>test.:test - you are redirecting to Alternate data streams (are you with FAT32 or NTFS . FAT32 does not support ADS and results there may produce something different)? with
dir /r (r switch is available from vista and above) or streams.exe from sysinternals you can check the state of ADS.To see the ADS content you can use more command:
Here are the commands that I know that can read ADS:
FOR /F , FIND , FINDSTR ,MORE , CERTUTIL ,CLIP ,EXPAND , SORT , MOFCOMP , FTP -S , CSCRIPT , WSCRIPT
Notepad and Wordpad will delete the ADS if they open a file that have one.