How can I store Windows "tree" command output in a file and retrieve it again?
tree
supports the /a
switch which uses regular ASCII:
D:\>tree /a
Folder PATH listing for volume Win7
Volume serial number is BA60-7CCB
D:.
+---3rd
| +---Android
| | +---android-ndk-r5
| | | +---build
| | | | +---awk
| | | | +---core
| | | | +---gmsl
| | | | \---tools
It probably uses the line-drawing characters in code page 850.
Notepad doesn't support that encoding, it's default is "ANSI", by which Microsoft mean Windows-Latin1 or Code-Page-1252 if I remember correctly.
Notepad++ or gVim etc should be able to display the characters correctly.
TL;DR
I am trying to figure out what I said long ago in so many words.
Sounds like, it's hopeless, maybe try a /U
switch, even shell redirection won't save you, maybe just convert it using another program.
Original
In Notepad++, I was able to read them when selecting the "Encoding" under "Character Sets" > "Western European" > "OEM-US".
After that I could select "Encoding" > "Convert to UTF-8", so I could transfer them in a format that hopefully everyone else would be able to read.
For reference, my system is Windows 7 Professional SP1 64-bit(x64), with my current system locale set to "English (United States)".
Also, I believe this question has more information and is higher rated: Saving 'tree /f /a" results to a textfile with unicode support
I also run my Command Prompt with the "/U" option (through ConEmu if that matters), and an answer on that page had stated: Either that does not function as expected, or the tree command does not respect it for some reason.
I have now found this excerpt from the following source, that may explain why the tree
command does not write Unicode-encoded text to a file:
Output UNICODE characters (UCS-2 le)
These options will affect piping or redirecting to a file.
Most common text files are ANSI, use these switches
when you need to convert the character set.
In my environment however, I have used output redirector character >
to write to a file, so the command is not doing this itself, and the output was still not encoded in a Unicode format.