批处理文件:列出特定文件夹中的 rar 文件并将结果写入文本文件 [英] batch file: list rar file in specific folder and write result into text file

问题描述

我有一个文件夹，其中包含一些 rar 文件和子文件夹.这些子文件夹包含 rar 文件或子文件夹(递归结构).我想编写一个批处理文件，列出此文件夹树(完整路径)中的所有 rar 文件.结果写入文本文件.

I have a folder and contains some rar files and subfolders. These subfolders contain rar file or subfolder (recursive structure). I want to write a batch file that list all the rar files in this folder tree (full path). The result is written into a text file.

示例:

特定文件夹:

--Quest
--Quest--1.rar
--Quest--2.rar
--Quest--Sub--3.rar
--Quest--Con--4.rar
--Quest--Math--ams.doc

以及运行result.txt中的批处理文件后的结果:

And the result after running batch file in result.txt:

--Quest1.rar
--Quest2.rar
--QuestSub3.rar
--QuestCon4.rar

推荐答案

我无法将此添加为评论，因此无法将其作为答案发布.

I can't add this as comment and therefore post it as answer.

命令dir的第三个参数是路径+文件说明.因此，整个参数应该用双引号括起来，而不仅仅是路径.

The third argument of command dir is path+file specification. Therefore the entire argument should be surrounded by double quotes and not just the path.

环境变量的值是一个可以包含双引号的字符串是对的.在命令参数内的任何位置使用此环境变量时，不可避免地会发生双引号现在位于参数字符串内.

It is right that the value of an environment variable is a string which can contain already double quotes. When using this environment variable anywhere inside an argument of a command, it happens inevitably that the double quotes are now inside the argument string.

大多数编译器的启动代码现在通过删除参数中的双引号来处理这种情况.但正确的行为是批处理文件首先从环境变量字符串中删除双引号，然后再在参数中使用环境变量，然后将整个参数放入双引号中.

The startup code of most compilers handle this case now correct by removing the double quotes within the argument. But the correct behavior would be that the batch file removes the double quotes from the environment variable string first before using the environment variable inside an argument and instead put the entire argument into double quotes.

解析 C 命令行参数 解释了使用 Microsoft Visual C/C++ 创建的应用程序，并且没有使用自定义的启动代码.不幸的是，没有描述在参数字符串中没有转义双引号会发生什么.

Parsing C Command-Line Arguments explains the command line parser of applications created with Microsoft Visual C/C++ and no customized startup code used. Unfortunately there is no description what happens with not escaped double quotes inside an argument string.

因为我曾经想知道操作系统传递给应用程序的内容以及应用程序如何解析命令行，所以我编写了一些 C 代码，使用各种编译器对其进行编译，并在各种控制台应用程序上运行了一些测试Windows 版本.

As I once wanted to know what is passed by the operating system to an application and how the application parses the command line, I wrote a little C code, compiled it with various compilers and ran some tests with those console applications on various Windows versions.

这是这个小控制台应用程序的代码:

Here is the code of this little console application:

#include <stdio.h>  // for printf()
#include <conio.h>  // for getch()

int main (int argc, char *argv[])
{
   int  iNumber;
   char sSpace[2] = " ";

   printf("The arguments of the program are:

");
   if(argc < 10) *sSpace = '';
   for(iNumber = 0; iNumber < argc; iNumber++)
   {
      printf("Argument %s%d: %s
",iNumber < 10 ? sSpace : "",iNumber,argv[iNumber]);
   }
   printf("
Press any key to exit ...");
   getch();
   printf("

");
   return(0);
}

我对参数 0 中的测试最感兴趣 - 应用程序的名称，因为我想知道它是否可以直接用于获取 INI 文件的名称.这是不可能的！

I was most interested on my tests in argument 0 - the name of the application as I wanted to know if it can be used directly to get name of an INI file. This is not possible!

我用一个非常老的 Turbo C 编译器编译了这个小代码，生成了一个 16 位 DOS 应用程序，DJGPP 生成了一个带有 16 位头文件的 32 位控制台应用程序，而 Visual C 生成了一个真正的 32 位控制台申请.

I compiled this little code with a very old Turbo C compiler producing a 16-bit DOS application, with DJGPP resulting in a 32-bit console application with a 16-bit header and with Visual C producing a real 32-bit console application.

编译后的控制台应用程序名为 ArgCheck.exe，位于 C:Temp 中，这是在 Windows XP SP3 x86 上打开的命令提示符窗口中的当前工作目录.

The compiled console application has name ArgCheck.exe and is located in C:Temp which is the current working directory in a command prompt window opened on Windows XP SP3 x86.

使用的命令行是:ArgCheck.exe "%WINDIR%"*.exe

使用 Visual C 编译的 ArgCheck.exe 的输出:

The output of ArgCheck.exe compiled with Visual C:

Argument 0: C:TempArgCheck.exe
Argument 1: C:WINDOWS*.txt

使用DJGPP编译的ArgCheck.exe的输出:

The output of ArgCheck.exe compiled with DJGPP:

Argument 0: C:TEMPARGCHECK.EXE
Argument 1: C:WINDOWS*.txt

使用 Turbo C 编译的 ArgCheck.exe 的输出:

The output of ArgCheck.exe compiled with Turbo C:

Argument 0: C:TEMPARGCHECK.EXE
Argument 1: C:WINDOWS
Argument 2: *.txt

如你所见，Turbo C 的启动代码也省略了双引号，但是参数中的双引号被解释为参数结束，结果是 2 个参数而不是只有 1 个.

As you can see, the startup code of Turbo C omits also the double quotes, but the double quote within the argument was interpreted as end of argument and the result are 2 arguments instead of only 1.

结论:如果双引号存在于参数中的任何位置而不是仅在参数字符串的开头和结尾，则应始终测试应用程序的启动代码如何解析命令行参数.

Conclusion: It should be always tested how the startup code of an application parses the command line arguments if double quotes exist anywhere within an argument instead of only at begin and end of the argument string.

这篇关于批处理文件:列出特定文件夹中的 rar 文件并将结果写入文本文件的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！