0

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.

Example:

Specific folder:

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

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

--\Quest\1.rar
--\Quest\2.rar
--\Quest\Sub\3.rar
--\Quest\Con\4.rar
Sully
  • 14,672
  • 5
  • 54
  • 79
user3697373
  • 83
  • 2
  • 10

2 Answers2

0

Try like this :

@echo off
set $root=Your\root\path
dir /s /b "%$root%"\*.rar>>result.txt
SachaDee
  • 9,245
  • 3
  • 23
  • 33
  • The single command `dir /s /b "Your\root\path\*.rar" >result.txt` works also. Double quotes around a parameter containing 1 or more spaces should be at begin and end and not at begin and somewhere in the middle although this is possible because cmd.exe corrects it. And a single `>` for creating result.txt with overwriting existing result.txt might be better here than `>>` for creating result.txt if not exist, but appending the lines to result.txt if the result file already exists. – Mofi Jun 02 '14 at 06:09
  • @Mofi where will you put the Double quotes if you use a variable like %CD% ??? The Double quote are not somewhere in the middle, but at the right place. Now it depend in how you define the `Path` variable, With or without the `backslash`. That's the difference. But both works. – SachaDee Jun 02 '14 at 16:04
  • see my additional answer for full explanation why double quotes should be always only at begin and end of an argument string. – Mofi Jun 03 '14 at 06:15
0

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

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.

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

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:\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);
}

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!

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

The compiled console application has the 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.

The command line used was: ArgCheck.exe "%WINDIR%"\*.exe

The output of ArgCheck.exe compiled with Visual C:

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

The output of ArgCheck.exe compiled with old version of DJGPP:

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

The output of ArgCheck.exe compiled with very old Turbo C:

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

As it can be seen, the startup code of Turbo C omits also the double quotes, but the double quote within the argument was interpreted as end of an argument resulting in two additional arguments instead of just one after argument 0 which always exists. The string of argument 0 depends on how the executable was started by another process. In worst case it is just the file name without path and without file extension with wrong case of the letters.

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 beginning and at end of an argument string.

Mofi
  • 46,139
  • 17
  • 80
  • 143