China DOS Union

@echo off set keyname=微软真垃圾 set /p=%keyname%<nul>name.txt wmic /? pause
BUG symptom: cursor flashes and batch is interrupted. Environment: WinXP SP2. My original batch code was very long, and it took me days to dig out this bug. I thought some part of the code was unstable, but it turned out to be this low-level bug. Really depressed~
Everyone, please pay attention to using set /p= <nul>name.txt and wmic in the same batch in the future

There should be a newly generated batch file in your working directory, right?

set /p=%keyname%<nul>name.txt
The same situation applies to following copy con file and more, but wmic will treat the input as a script

The batch file was not generated in the current directory.
I originally just wanted to use set/p to generate a text without a newline character, but I didn't expect that then no parameters of wmic would work.

Solution
```batch
@echo off
set keyname=微软真垃圾
set /p=%keyname%<nul>name.txt
set /p=<nul>nul
wmic /?
pause
```

It seems the problem is still with the set/p parameter.

@echo off set keyname=Microsoft is really rubbish >name.txt set/p=%keyname%<nul wmic /? pause

Originally posted by fastslz at 2008-1-21 12:47 PM:
No batch file was generated in the current directory.
I originally just wanted to use set/p to generate a text without line breaks, but unexpectedly, wmic didn't work with any parameters after that.

It's not that it didn't work, but after several redirections, for some reason, it activated the console input acquisition of wmic.
You can enter at the command line and terminate with ctrl+z to generate a temporary script file for wmic.

Any command that has the function of receiving data in the console will have such an error in such a batch file.
According to your batch file, I think any command with this function has a potential handle, which is customized by the command and mainly used to complete pipeline transmission.

This is also okay
@echo off set keyname=微软真垃圾 >name.txt set /p=%keyname%<nul wmic /? pause

So when I write >file, I put > at the front

The spirit of the original poster is worthy of encouragement

I used the following code in a batch file to get disk space:
wmic logicaldisk get DeviceID,FreeSpace,Size | findstr "%_Drives%"

But I found that the program would become unresponsive at some moments.
At this time, directly running the following code in the current command line would also become unresponsive:
wmic logicaldisk get DeviceID,FreeSpace,Size

After entering a Ctrl+Z and a carriage return, the execution result would continue to be output.
At this time, a zero-byte file named TempWmicBatchFile.bat would be generated in the current path.

Open another command line environment, with the same current path, and executing this code would be fine.

A related problem also occurs when using scripts to operate diskpart to list disk partitions. At this time, only Ctrl+Break can be used to terminate the code execution.

Suspect that these commands may lock some volumes when executing.
And if pipes are used on these commands, and the pipe of the command needs to generate a temporary file in %TMP%, and if the volume where %TMP% is located is locked, the temporary file cannot be created on this volume, and the pipe operation cannot be completed. The input after the pipe is redirected to the console, and entering Ctrl+Z plus carriage return is exactly to end the console input.

Of course, this is just a guess so far...

This is my post in another thread before I saw this topic.

Now, after integrating the discussions of the two topics, I think it is very likely related to the problem of custom handles. That is to say, wmic may be using one of the custom handles from 3 to 9. And at this time, if set /p, copy con or pipe operations are used, there is a high probability that this custom handle will be "polluted", causing the input of wmic to be redirected to the console. And such "pollution" is globally effective in one command line session.

The related discussion is as follows:
http://www.cn-dos.net/forum/viewthread.php?tid=16942

[ Last edited by qzwqzw on 2008-1-24 at 08:36 PM ]

everest79 also said that a temporary file would be generated, but I didn't find the temporary file here. It seems to be another kind of "handle pollution". Wmic is particularly sensitive to pipe characters

This can continue
@echo off
set keyname=Microsoft is really rubbish
set /p=%keyname%<nul>name.txt
START wmic /?

```
@echo off
s<nul>nul
echo test
wmic /?
pause
```

Such code shows that the problem is not related to set /p, but related to the two redirection symbols < and > that appear in the code. This corresponds to the discussion in http://www.cn-dos.net/forum/viewthread.php?tid=16942. The start in floor 12 is a new command line session, and the problem can naturally be solved. But usually it is of little significance because it is difficult for us to transfer the output of wmic back to the original command line session.

[ Last edited by qzwqzw on 2008-1-24 at 09:16 PM ]

It can be seen from floor 6
@echo off
>nul s<nul
echo test
wmic /?
pause
In this way, redirection will not have such a situation

The specific reason must be related to the internal processing mechanism of WMIC. We can see some clues from that TempWmicBatchFile.bat. However, no matter what, we can't stop using the <nul>nul sentence pattern because of WMIC. So the following methods should be effective in batch processing: wmic /?<nul or cd.|wmic /? In this way, no matter what custom handles were used in front of the script, it ensures that what WMIC uses is consistent. But when running cd.|wmic /? in the command line, it prompts: Win32 error: The file is being used by another process, and the process cannot access it. What an interesting prompt!