批处理文件:列出特定文件夹中的rar文件并将结果写入文本文件

时间:2014-06-01 18:39:37

标签: file batch-file

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

示例:

特定文件夹:

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

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

--\Quest\1.rar
--\Quest\2.rar
--\Quest\Sub\3.rar
--\Quest\Con\4.rar

2 个答案:

答案 0 :(得分:0)

试试这样:

@echo off
set $root=Your\root\path
dir /s /b "%$root%"\*.rar>>result.txt

答案 1 :(得分:0)

我无法将其添加为评论,因此将其发布为答案。

命令dir的第三个参数是路径+文件规范。因此,整个参数应该用双引号括起来,而不仅仅是路径。

环境变量的值是一个可以包含双引号的字符串是正确的。在命令的参数内的任何地方使用此环境变量时,不可避免地会出现双引号现在在参数字符串中。

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

Parsing C Command-Line Arguments解释了使用Microsoft Visual C / C ++创建的应用程序的命令行解析器,并且没有使用自定义的启动代码。遗憾的是,没有描述在参数字符串中没有转义双引号会发生什么。

由于我曾经想知道操作系统向应用程序传递了什么以及应用程序如何解析命令行,我编写了一些C代码,用各种编译器编译它并在各种控制器应用程序上运行一些测试Windows版本。

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

#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:\n\n");
   if(argc < 10) *sSpace = '\0';
   for(iNumber = 0; iNumber < argc; iNumber++)
   {
      printf("Argument %s%d: %s\n",iNumber < 10 ? sSpace : "",iNumber,argv[iNumber]);
   }
   printf("\nPress any key to exit ...");
   getch();
   printf("\n\n");
   return(0);
}

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

我使用一个非常老的Turbo C编译器编译这个小代码,产生一个16位DOS应用程序,DJGPP产生一个带有16位头的32位控制台应用程序和Visual C生成一个真正的32位控制台应用

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

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

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

Argument 0: C:\Temp\ArgCheck.exe
Argument 1: C:\WINDOWS\*.txt

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

Argument 0: C:\TEMP\ARGCHECK.EXE
Argument 1: C:\WINDOWS\*.txt

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

Argument 0: C:\TEMP\ARGCHECK.EXE
Argument 1: C:\WINDOWS
Argument 2: \*.txt

正如您所看到的,Turbo C的启动代码也省略了双引号,但参数中的双引号被解释为参数的结尾,结果是2个参数而不是1个。

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