China DOS Union

Can the following work be completed?
pause 3<&0
set p=<&3
or
pause 2>file 3<&0

Can't figure it out, looking forward...

Actually I don't know either. Using a sentence from Willsort, the thing of handle is almost a bug of CMD, completely copying Linux Shell

Well, it's all right. I originally wanted to use this to get input

In fact, there are many things in CMD waiting to be discovered. Brother Everest79 can study by himself.

Call me younger brother, I'm still young. Calling me old is not okay.

My foreign language is extremely poor. Originally, there was a newbie who helped translate some foreign technical documents and so on, but now there isn't anymore.

I've been researching this problem for almost three months. I always take it out to try every few days, and there's still no result.

Sometimes I grit my teeth and want to study C again, but I remember that my concepts are still stuck at the time of using debug to modify games.

The biggest problem with handles is that there's simply no way to copy input. I saw on the Internet that there's redirecting to con to release handles. I suspect whether there are still hidden switches and so on in this regard.

Ask someone to statically reverse engineer cmd.exe and take a slow look. I heard that the source code of the leaked Win2k last time also had cmd.exe? Who has it, please share it up. Hehe

This requirement is too high, I can't handle it

Re everest79:

Actually, up to now, I'm still a bit confused about the duplication and redirection of CMD handles. Brother electronixtar mentioned the loophole, which is probably from the following topic . Because the words in it are just speculative, please be careful to distinguish and separate the true from the false.

For handle duplication, the most mentioned document I've seen is the "Using command redirection operators" section in Windows' own Help and Support, which shows that Windows users haven't paid more attention to this feature transplanted from the *inx platform by Microsoft.

In practical applications, I rarely use the feature of handle duplication because this feature always seems to be achievable through other simpler methods.

set /p var=input: 3<defined.txt 0<&3

This statement seems to achieve the first question you mentioned in the main post.

3<define.txt points the character stream of defined.txt to handle 3, and then 0<&3 copies the input reading characteristic of handle 0 to handle 3 (it can also be understood as handle 3 points to handle 0), so the input reading of set /p is indirectly through handle 3 pointing to the defined.txt file. But why don't we use the form set /p var=input: <defined.txt to directly obtain input from defined.txt through handle 0?

Discussing from another aspect: Suppose program test uses handle 3 for input reading, then we can use the form test <input.txt 3<&0 to obtain input from input.txt; at the same time, we can also use the form test 3<input.txt to obtain input from input.txt.

Of course, handle duplication still has some strange characteristics, which are worth in-depth research on its applications.

For example, execute the following command line under cmd:

cmd
echo echo %var%>test.bat
set /p var=in: 0<&3 3<test.bat

At this time, we will find that set /p still gets input from the original pointer of handle 0 - the console (CON), and doesn't get it from test.bat. But when we enter the value of val and press Enter, we find that the input of test.bat reaches the input interface of the nested command interpretation shell of the first cmd through handle 3 and then handle 0, thus executing the statement in test.bat, displaying the just-defined variable var, and then the inner layer of cmd is forced to be removed, returning to the original cmd shell, and the variable var is discarded.

What does 2>nul 1>nul in batch statements mean
http://www.cn-dos.net/forum/viewthread.php?tid=16942#pid115971

[ Last edited by willsort on 2007-1-20 at 10:43 AM ]

Thanks to willsort's answer, it was my misunderstanding.

First, I initially understood the custom handles 3-9 as seven memory spaces (abstract) that can store characters. Only after seeing your example did I realize how custom handles are.

rem Define handle 4 input 4<file.txt rem Define handle 4 output 4>file.txt
It should be that the custom handle must first specify the device before use.

Second, after seeing the above example, I realized that handle copying and redirection are two related but opposite concepts. For example, input copying and input redirection "<&", and there is only one handle with input function, which is 0.

4<file.txt 0<&4
First define handle 4. Since it is input, it must be 4<file.txt.
1. The copying concept is to copy the attributes of 0 to 4, and handle 4 has the input reading function of 0.
2. The redirection concept is that 4 points to 0, and handle 0 uses the input reading method to obtain the custom handle 4. Both of the above actually mean that the device defined by handle 4 replaces the keyboard input.

Third, then the logic leads to the concepts of output copying and output redirection (this is what we often use).

4>file.txt 1>&4 4>file.txt 2>&4
Similarly, the copying concept makes 4 have the output characteristics of 1, but 4 defines a new device as file.txt, which also replaces the normal screen output message. In fact, this is more like the clipboard function in Windows rather than copying. If it were copying, 1 should also have the screen output function. Why is there no display?
The redirection concept can well explain this logical fault. Because the device file.txt defined by 4 replaces the original device msg print of 1, so the extension of the redirection concept is probably "4>file.txt 1>&4" = "1>file.txt".

Fourth, here I have to mention the characteristics of handle 3.

:sub1 echo d 1>nul 3>nul :: Arbitrary execution of commands echo d 1>con 4>con :: Restore normal :sub2 find "." d 2>nul 3>nul :: Arbitrary execution of commands find "." d 2>con 5>con
In this way, it will be found that executing sub1 is like executing 1>nul at the end of each sentence.
And sub2 is like executing 2>nul at the end of each sentence.
The release command is X>con X+3>con.
The explanation I can find is that in the redirection, there is handle 3. Handle 3 will suspend the handle X that is redirected together and assign its attributes to 3+X, and specify the new device as nul. At the same time, the new handle generated by handle 3 is persistent, unless X and 3+X are manually released at the same time.
Application of handle 3 in batch processing.

@echo off 2>nul 3>log.txt find "." dd as echo a echo b 1<&2 pause
log.txt is read-only accessible when the current window is not closed.

Fifth, it is my assumption, which cannot hold, and it is impossible to redirect or copy the input of stdin to a certain custom handle or device.

Originally posted by rubik at 2007-1-19 11:12 PM:
There is a batch script built into Windows in the Windows directory, with only one line:

If Not Exist %1 Copy Nul: %1 > Nul: 2>&1

Is this for creating an empty file?

Transform the above concepts into C language concepts and describe them using C-like syntax

A device is a structure with a character I/O pointer, which can be regarded as a file

typedef struct { *char io_ptr; } FILE;

Standard devices are already defined files

FILE stdin, stdout, stderr;

A handle pointing to a device is a file pointer

FILE *handle;

All handles form a pointer array, and 0, 1, 2 are initialized to the addresses of stdin, stdout, stderr respectively

FILE *handle[10]={&stdin, &stdout, &stderr};

---------------------------------------------------------------------

Redirection can be regarded as reassigning the file pointer

3<defined.txt is equivalent to handle[3]=&defined.txt;

2>nul is equivalent to handles[2]=&nul;

Similarly, copying a handle can also be regarded as pointer assignment

0<&3 is equivalent to handle[0]=handle[3];

---------------------------------------------------------------------

From this, we can see why in the example upstairs, we must first 3<defined.txt and then 0<&3

Because after 3<defined.txt, handle[3] will have an address

Only then can the address of defined.txt be passed to handle[0] through 0<&3

handle[3]=&defined.txt;
handle[0]=handle[3];

This is of course equivalent to

handle[0]=&defined.txt;

That is, 3<defined.txt 0<&3 is equivalent to 0<defined.txt

---------------------------------------------------------------------

In addition, regarding the characteristics of handle 3

If you have carefully studied the link given in building 9

You will find that the statement about X+3 is not accurate

This is related to the local nature of your test

The real reason still lies in handle backup

Handles can actually be regarded as pointers to pointers that the system has standardized.
You can use the function GlobalLock() to lock an object in memory.
&0, &1, &2 can be regarded as file forms as qzwqzw said.
And custom &3 - &9 are more like an index.
The &3 - &9 handles are meaningful only when they uniquely determine an item.
After the application ends, the memory lock for that area will be released and the original state will be restored.
So handle redirection can only be applied to the current command and has a sequence.
What the 11th floor said that the new handle generated by handle 3 is persistent and needs to be released manually is not quite accurate.

3+x is a bit taken for granted. I was dizzy last night, mixing up the attributes of &3 with the attributes copied by &3. Another conceptual mistake. Am I really getting old?

Today I read and tested again and found the following characteristics
cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 2>con 4>con ;er=&2 ;co=&5 cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 4>nul 1>&4 ;er=&4 ;co=&5 d 2>con 4>con ;er=&2 ;co=&5 cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 4>nul ;er=&4 ;co=&5 d 5>nul ;er=&4 ;co=&5 d 2>con 4>con ;er=&2 ;co=&5 cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 4>nul ;er=&4 ;co=&5 d 5>nul ;er=&4 ;co=&5 d 2>nul 4>nul ;er=&5 ;co=&6 d 2>con 5>con ;er=&2 ;co=&6 cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 4>nul ;er=&4 ;co=&5 d 2>nul 4>nul ;er=&5 ;co=&6 d 2>nul 5>nul ;er=&6 ;co=&7 d 2>con 6>con ;er=&2 ;co=&7 cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 2>nul 3>nul ;er=&4 ;co=&5 d 2>nul 3>nul ;er=&4 ;co=&5 d 2>con 4>con ;er=&2 ;co=&5 cmd ;er=&2 ;co=&3 d 2>nul 3>nul ;er=&4 ;co=&5 d 2>nul 4>nul ;er=&5 ;co=&6 d 2>nul 4>nul ;er=&5 ;co=&6 d 2>nul 4>nul ;er=&5 ;co=&6 d 2>con 5>con ;er=&2 ;co=&6 cmd ;ou=&1 ;co=&3 d 1>nul 3>nul ;ou=&4 ;co=&5 d 1>nul 4>nul ;ou=&5 ;co=&6 d 1>nul 5>nul ;ou=&6 ;co=&7 d 1>nul 6>nul ;ou=&7 ;co=&8 d 1>nul 7>nul ;ou=&8 ;co=&9 d 1>nul 8>nul ;ou=&9 ;co=&? d 1>nul 9>nul ;ou=&? ;co=&? cmd ;ou=&1 ;co=&3 d 1>nul 3>nul ;ou=&4 ;co=&5 d 1>con 4>con ;ou=&1 ;co=&5 d 1>nul 5>nul ;ou=&6 ;co=&7 d 1>con 6>con ;ou=&1 ;co=&7 d 1>nul 7>nul ;ou=&8 ;co=&9
I really didn't read that post carefully yesterday

As for the point that the new handle generated by &3 is persistent, it's not necessarily the case. The premise is that the first new handle generated by &3, without using handle 4 in the middle, is persistent before release or before the window ends