谢谢willsort的回答，是我理解错误
第一，我将自定义句柄3-9理解为七个可以存储字符的内存空间（抽象），看到你的例子才发现自定义句柄是这样的
rem 定义句柄4输入
4<file.txt
rem 定义句柄4输出
4>file.txt
应当是自定义句柄在使用之前首先应指定设备
第二，看了以上例子才知道句柄的复制与转向是两个相附又相反的概念，例如输入复制及输入转向"<&"，拥有输入功能的句柄只有一个就是0
4<file.txt 0<&4
首先定义句柄4，因为是输入所以一定为4<file.txt
1.复制概念是将0的属性复制到4，句柄4拥有了0的输入读取功能
2.而转向概念为4指向0，句柄0以输入读取方式来获得自定义的句柄4
以上两者其实都是句柄4定义的设备代替了键盘输入
第三，那么逻辑得到输出复制及输出转向的概念（这个我们常用）
4>file.txt 1>&4
4>file.txt 2>&4
同样复制概念4拥有了1的输出特性，但4定义了新设备为file.txt，也就代替了正常屏幕输出消息，其实这个更像windows的剪贴功能而非复制，若是复制那么1也应同样有着屏幕输出的功能，为什么会不显示
而转向概念就可以很好的解释这个逻辑故障，因为4所定义的设备file.txt取代了1原有的设备msg print，所以转向概念的延伸大概就是"4>file.txt 1>&4"="1>file.txt"
第四，这里不得不提一下句柄3的特性
:sub1
echo d 1>nul 3>nul
::随意执行命令
echo d 1>con 4>con
::恢复正常
:sub2
find "." d 2>nul 3>nul
::随意执行命令
find "." d 2>con 5>con
这样会发现执行sub1如同每句后边执行了1>nul
而sub2有如每句后边都执行了2>nul
而释放命令为 X>con X+3>con
我可以找到的解释是同时转向中有句柄3，句柄3会挂起一同转向的句柄X，并将其属性赋于3+X，而且指定新设备为nul，同时句柄3生成的新句柄是持久性的，除非同时手工释放X与3+X
句柄3在批处理中的应用
@echo off 2>nul 3>log.txt
find "." dd
as
echo a
echo b 1<&2
pause
在当前窗口没有关闭的情况下，log.txt只读访问
第五，就是我的假设了，不能成立，无法将stdin的输入转向或复制到某个自定义句柄或设备中
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.
