China DOS Union

To All:

Recently, when discussing and improving a batch script for regular backups with Brother namejm, a problem was encountered and I am now bringing it up for everyone's advice.

After enabling the auto-completion feature with cmd /f:on, it was found that if there are directories or files with Chinese names in the test directory, using Ctrl+D or Ctrl+F can normally complete the directory or file name. However, when continuing to use Ctrl+D or Ctrl+F to complete and the next directory or file name is shorter than the completed directory or file name, after displaying the new directory or file name, the old directory and file name does not completely disappear, but leaves a certain trace.

For example, the test folder has only two files named "Long Filename" and "Short Name". Then, after enabling cmd /f:on for auto-completion, pressing Ctrl+F for the first time will display "Long Filename", and pressing Ctrl+F for the second time will display "Short Name　Name".

It needs to be noted that the residual trace of the old file will not affect the normal recognition of the new file.

It is analyzed that this should be caused by the auto-completion not correctly handling multi-byte character (including Chinese) file names. In the above test, before the second auto-completion, it only cleared the first three Chinese characters of the previous display, with a width equivalent to 6 English characters. This seems to be because cmd calculates the string length of the previous completed file name according to the Unicode rule as 4, plus the two characters 0d/0a represented by the carriage return, totaling 6. That is to say, cmd rewrites the original file name with 6 English blank characters to clear its display content, but may not have considered that the display width of multi-byte characters is several times that of English characters.

File Backup Tool
http://www.cn-dos.net/forum/viewthread.php?tid=20747&fpage=1

Hehe, in the cmd above XP, you don't need /f:on, using Tab / Shift+Tab can also achieve the corresponding function~~ Just like *nux~~

electronixtar is really a thoughtful person, finding such a hidden function, PF.

But using Tab/Shift+Tab also causes the problem of file name residue of Ctrl+F or Ctrl+D. Other problems are not found because I can't think of a way to test them.

Hehe, CMD is getting more and more interesting.

Re electronixtar:

Briefly searched on Google about information regarding autocompletion.

In non-Microsoft website information, it is clearly stated or implied that autocompletion is disabled by default, and needs cmd /f or cmd /f:on to enable.

In Microsoft website published information, most articles reposted the help information of CMD, "File and directory name completion is NOT enabled by default." or "ile and Directory name completion is NOT enabled by default."

Found some useful information in TechNet:

There are two subkeys and four entries related to autocompletion in the registry:

HKLM\Software\Microsoft\Command Processor\CompletionChar
HKLM\Software\Microsoft\Command Processor\PathCompletionChar
HKCU\Software\Microsoft\Command Processor\CompletionChar
HKCU\Software\Microsoft\Command Processor\PathCompletionChar

Under normal conditions, as long as one of these four entries has a value of a control character, autocompletion will be enabled. PathCompletionChar only completes directory names, and CompletionChar completes file names and directory names. When both are set, the settings in HKCU take precedence over HKLM. After using cmd /f, the autocompletion character will be fixed as Ctrl+D/Ctrl+F, regardless of the key values in HKCU/HKLM.

The key is the issue of default values, because if CompletionChar is 0x0, 0xD, or greater than >=0x20, autocompletion will be disabled (actually because it does not meet the activation conditions and cannot be activated). And there is a contradiction in the description of default values in TechNet articles . has a default value of 0x9, which is Tab, has a default value of 0x40, which is disabled.

In addition, the relevant TechNet articles are in the Windows Server 2003 technical library, and are not directional for XP and 2000. In my current XP system, CompletionChar is 0x9, but my system is not an original version, but an optimized version, and I have also modified CompletionChar myself. It is also impossible to rule out whether ServicePack or HotFix has ever modified it.

So, this issue still needs further verification.

CompletionChar Entry
http://technet2.microsoft.com/WindowsServer/en/Library/1ff97534-38d4-4cc1-86f1-c2fc2689367a1033.mspx?mfr=true

Command Processor\CompletionChar
http://technet2.microsoft.com/WindowsServer/en/Library/1ff97534-38d4-4cc1-86f1-c2fc2689367a1033.mspx?mfr=true

In the very early days, I found that typing ALT+9 in the command prompt would get a certain file name in the current directory. Later I found out that ALT+9 is TAB. Then I successively found that ESC can cancel the current input, and F1 to F9 have different functions, but most are related to DOSKEY.

Then one day I also discovered the problem described by willsort. At that time, I was at a loss, until one day I found out the function of chr(13) and suddenly understood:
With Wscript.StdOut .Write "Hello, this is the China DOS Union Script Edition" Wscript.Sleep 1000 .Write chr(13) & "error" end With
After saving as 测试.vbs, run cmd and type cscript //b //nologo to see the result.
If you use the writeline method instead of the write method, it will automatically go to the next line and this phenomenon will not occur.

Re 3742668:

What you mentioned about chr(13) should be the carriage return character (0x0d). In the DOS semantics, it only carries out a carriage return without a line feed, and the line feed is controlled by the line feed character (0x0a; chr(10)).

The different combinations of carriage return and line feed result in the differences in the plain text formats of the three major systems: MSOS, Unix, and Mac. MSOS uses 0d0a, Unix uses 0a, and Mac uses 0d.

But this is still different from the issue of auto-completion. According to the above view, after "longname", "sname" should be displayed as "sname e" instead of "sname". And if there are both Chinese and English characters in the file name, you can more easily see the problem.

And according to its mode of being able to clear by length rather than by block, the most likely clearing algorithm it uses is to replace all the characters in the original buffer with blank characters, or to re-generate an equal-length string composed of blank characters, and then output it again in the original position (similar to.Write). And because the compilation system uses Unicode encoding, English and Chinese characters with different display widths have the same byte length and character length, so the error can be expected.

I think it's adding spaces.