相关疑难解决方法(0)

假设我们想要使用以下命令在Windows中创建一个空文件:

type nul > C:\does\not\exist\file.txt

目录不存在,所以我们得到错误:

The system cannot find the path specified

如果你打印%errorlevel%输出是:

echo %errorlevel%
0

但命令没有成功!

我注意到,%errorlevel%如果你使用重定向,窗口不会设置最后一个命令.

有没有解决的办法？

在Windows批处理脚本中处理错误的常用方法是使用
if errorlevel 1 ...或等if %errorlevel% neq 0 ....通常,人们希望错误处理代码保留ERRORLEVEL.

我相信所有外部命令总是会导致ERRORLEVEL被设置为某个值,因此错误处理代码必须在执行外部命令之前在环境变量中保留ERRORLEVEL.

但内部命令怎么样？问题是,一些内部命令在成功时将ERRORLEVEL清除为0,而有些则没有.而且我找不到任何指定哪些命令做什么的文档.

所以问题是,哪些内部命令成功后将ERRORLEVEL清除为0？这不是关于返回的ERRORLEVEL代码的一般问题,而是严格关于成功结果的问题.

有些帖子如何将ERRORLEVEL重置为零的最简单方法是什么？和Windows批处理文件:.bat vs .cmd？给出部分答案.但我从未见过全面的清单.

注意: 多年来我一直很好奇.所以我最终决定进行一系列实验并得出一个明确的答案.我发布此问答来分享我发现的内容.

ERRORLEVEL是大多数cmd.exe命令在根据一系列条件结束更改时返回的值,因此知道命令返回的值是有助于编写更好的批处理文件的有用信息.所有外部.exe程序在结束时都会更改ERRORLEVEL(这是ExitProcess和TerminateProcess Win-32 API函数的固有机制),并且通常记录这些值,但内部 cmd.exe命令返回的值在其他地方没有完整记录.

此问题中出现具有部分ERRORLEVEL值的表,但仅适用于成功时设置ERRORLEVEL = 0的内部命令.我建议OP这样的问题修改它,以便也包括"不成功的命令"返回的值,但他拒绝并邀请我发布我自己的问题/答案,所以在这里!必须注意的是大于零的不同ERRORLEVEL并没有必然意味着该命令失败!有些命令以无错误结束并返回大于零的值以指示不同的"退出状态",包括内部命令(如SET /P).

为了更好地使用Batch .bat文件中的内置cmd.exe命令,我们需要知道它们返回的ERRORLEVEL值以及此管理中涉及的机制.所以问题是,哪个内部cmd.exe命令将ERRORLEVEL设置为任何值(包括零)？

我正在编写批处理(.bat)脚本,我需要处理删除文件夹失败的情况.我正在使用%errorlevel%捕获退出代码,但在rd命令的情况下它似乎不起作用:

C:\Users\edo\Desktop>rd testdir
Directory is not empty

C:\Users\edo\Desktop>echo %errorlevel%
0

为什么？你有什么建议？

考虑以下bat,test.bat(PC01关闭):

mkdir \\PC01\\c$\Test || goto :eof

如果我从命令shell运行该bat:

> test.bat || echo 99
> if ERRORLEVEL 1 echo 55

输出只有55.没有99.有一个错误级别,但||操作员没有看到它.

如果我用那个蝙蝠跑 cmd /c -

> cmd /c test.bat || echo 99
> if ERRORLEVEL 1 echo 55

输出为空白.Errorlevel为0.

如果我删除了|| goto :eof,一切都按照人们的预测 - 即输出即可

99 55

有谁知道为什么这种半生半熟的ERRORLEVEL行为正在发生？

我认为我对ERRORLEVEL与％ERRORLEVEL％有基本的了解，但是！ERRORLEVEL！使我困惑。

我正在制作一个脚本，该脚本调用可执行文件，然后任务列表以查看其是否正在运行，然后通过taskkill将其杀死，然后尝试输出错误级别并针对其他exe重复此操作，而我意识到我真的不明白批处理中的错误级别。

我将变量设置为！errorlevel！然后在回显中使用不带引号的变量，并且在设置后出现错误时，变量从一个uint16更改为另一个uint16，例如它引用了真实的变量而不是副本。我要复制。有人可以解释这些家伙之间的区别吗？

更新：这是我正在处理的代码段。

for %%P in (%executableList%) do (
   echo ----------------------------------------------------------------------------------       
    set exeErrorlevel=0
    set running=false

    start %%~fP  
    set exeErrorlevel=!ERRORLEVEL!

    rem for debugging purposes
    echo %%~nP%%~xP older errorlevel %ERRORLEVEL%       
    echo %%~nP%%~xP newer errorlevel !ERRORLEVEL!        
    echo before tasklist running var is : !running!

    tasklist /FI "IMAGENAME eq %%~fP" | find /I /N /C  "%%~fP" >nul && set running=true

    echo after tasklist is running var is: !running!

    if !running! equ true ( 
       echo %%~nP%%~xP Program is running
       taskkill /F /IM %%~nP%%~xP /T …

这个引人入胜的帖子:

这个命令如何合法？"> file1 <file2 cat"

在一个看似格式错误的cat"shell"(一个Linux shell,大概是BASH)的调用中突出了令人惊讶的行为.基本上,shell似乎能够从一系列字符串中的模糊位置获取可执行文件,然后使用I/O重定向到流/文件描述符.

根据我的理解,基本过程是:

1. 查找重定向模式并将其读入或读出适当的流/文件描述符(例如:1>(stdout))(这发生在命令中启动可执行进程之前!(例如cat调用))
2. 在字符串列表中查找可执行进程.
3. 启动该可执行过程
4. 暂停进程完成或继续(根据需要)在步骤1中检测到的各种输出.

这导致了一些令人惊讶的逻辑.例如,在执行后的新目录中echo "dog" > cat:

• <cat cat >dog:从文件中写入"狗" cat来dog使用shell工具cat

• <cat cat> cat cat:覆盖第一个命令,留下一个空白cat文件(不确定在第二个命令的中间发生了什么).

• <cat cat> cat cat >dog 2>more:创建空文件,dog并用空文件more覆盖cat文件.

• <cat >dog cat cat <dog >cat(创建空文件dog,覆盖catw /空文件)

• <cat cat >dog 2>much 1>more:用cat空文件覆盖; 创建文件dog/ …