-1

I use this batch script while I program in Java to avoid cluttering my folders with class files. But for some reason it can't copy *.txt files.

This is a *.txt file content before copying it to another folder:

U 450
I 100
I 5000
U 500

The batch file contains:

@echo off
set TEST=%1
mkdir %TEST%Folder
xcopy *.txt %TEST%Folder
xcopy %TEST%.java %TEST%Folder
cd %TEST%Folder
javac -encoding utf8 %TEST%.java
java %TEST%
cd..
::RD /S /Q %TEST%Folder //is commented out while I'm debugging 

And this is content of copied file:

 

It is empty.

The strange thing is, if I run xcopy *.txt DestinationFolder on its own, it works just fine.


edit: The %1 variable is the name of the java that the program will compile, all my paths are set up correctly and this part of the code works just fine, the only problematic part is the xcopy

Waitwuut
  • 1
  • 3
  • What is the exact content of the received argument string `%1`? – Compo Oct 26 '17 at 04:11
  • @Compo It's the name of the java file to compile – Waitwuut Oct 26 '17 at 12:27
  • @Waitwuut, if you comment out the `javac` and `java` lines as well, and the files copy to the holding directory correctly and readable then you can identify the issue as related to the compiler. If the files do not arrive at the holding directory or are named incorrectly then the issue is probably related to your input parameter, `%1`. If the files arrive there exactly as expected and are empty, unreadable or corrupted, the issue is more than likely a system issue. – Compo Oct 26 '17 at 13:47
  • @Compo The files arrive as expected but are empty. – Waitwuut Oct 26 '17 at 14:19
  • @Waitwuut, based upon my previous comment, if the files are arriving correctly but empty, then the answer you've accepted would only be correct should the java compiler have problems with characters normally allowed by Windows/cmd.exe. _(you were asked over ten hours ago for the content of `%1` to determine that)_. In this case I do not believe that `Xcopy` empties your files, even if that was possible, changing `XCopy` to `Copy` or `RoboCopy` would be the suggested solution not surrounding the file names with doublequotes. – Compo Oct 26 '17 at 14:44
  • Remove the line starting the java program and see if the text files are unmodified – eckes Oct 29 '17 at 22:05

2 Answers2

0

The string passed as first argument to the batch file referenced with %1 is most important here on this issue. Unfortunately this string was not posted.

I suggest to use this batch file:

@echo off
if "%~1" == "" goto :EOF
%SystemRoot%\System32\xcopy.exe *.txt "%~1Folder\"   /I /C /K /Q /R /Y >nul
%SystemRoot%\System32\xcopy.exe "%~1.java" "%~1Folder\" /C /K /Q /R /Y >nul
pushd "%~1Folder"
javac.exe -encoding utf8 "%~1.java"
java.exe "%~1"
popd
rem rd /S /Q "%~1Folder" & rem Is commented out while I'm debugging.

On second line it is checked if the batch file is called at all with an argument string and batch processing is exiting if this is not the case. For details see answer on: Where does GOTO :EOF return to?

The batch file above references the first argument string with perhaps existing surrounding double quotes always removed as the argument string is concatenated with other strings to a new argument string for commands and executables. A file/folder name without or with path containing a space or one of the characters &()[]{}^=;!'+,`~ requires the usage of double quotes around the complete argument string.

It is advisable to specify in a batch file executables always with file extension and if path to executable is well known also with full path because that makes the batch file independent on current values of the environment variables PATH and PATHEXT. That is the reason for specifying xcopy twice with full path and with file extension. javac and java are specified just with file extension because their storage location on your Windows computer is not known by me. Therefore Windows command interpreter has to find those two executables with usage of environment variable PATH.

XCOPY can create the entire directory structure to specified destination folder if the destination folder does not already exist. Therefore it is not necessary to explicitly create the destination folder first.

XCOPY can be used to copy a single file, multiple files or an entire directory structure to a single file, multiple files or a directory. The challenge for XCOPY is finding out for destination if the user specified a file name or a directory name.

The destination is interpreted as file name pattern if there is a ? or * after last backslash in destination/target string, for example for using xcopy *.txt "%TEMP%\*.tmp".

The destination is interpreted as directory name if the target string ends with a backslash.

But if the target string does not contain ? or * (after last backslash) and also does not end with a backslash, it is unclear for XCOPY if the target string specifies a directory or a file.

On copying multiple files, i.e. using ? or * in source string, the option /I tells XCOPY that the target is a directory name even if target string does not end with a backslash. For that reason the first XCOPY command line would work also with no backslash at end of target string %~1Folder\.

But on second XCOPY command line on which a single file is copied, the usage of option /I would be have no help as XCOPY would nevertheless prompt the user if destination specifies a file or a directory. That's the reason for the backslash at end of destination folder path to avoid this prompt.

The command PUSHD pushes the path of current directory on stack and sets the specified directory as new current directory. This works even for a directory specified with a UNC path if command extensions are enabled as by default because in this case PUSHD dynamically assigns a drive letter to UNC folder path. The command POPD pops directory path from stack and sets this directory again as current directory. I can only suppose that this is the correct current directory management for the task.

I suggest to test this batch file with first line @echo off changed to @echo ON by running it from within a command prompt window with current directory set correct instead of double clicking on it to see what Windows command interpreter really executes after preprocessing each command line in the batch file and the perhaps output error messages depending on first argument string.

For understanding the used commands and how they work, open a command prompt window, execute there the following commands, and read entirely all help pages displayed for each command very carefully.

  • call /? ... explains %~1.
  • cmd /? ... explains when a file/directory name or any other argument string must be enclosed in double quotes.
  • echo /?
  • goto /?
  • if /?
  • popd /?
  • pushd /?
  • rd /?
  • rem /?
  • xcopy /?

Read also the Microsoft article about Using Command Redirection Operators for an explanation of >nul.

Mofi
  • 46,139
  • 17
  • 80
  • 143
  • Tried your batch file, for some reason it still empties the copied text files. – Waitwuut Oct 26 '17 at 12:39
  • @Waitwuut What is the output of the batch file on running it from within a command prompt window as I suggest in the answer? Are any error messages displayed? What are the file sizes of the copied files in target directory? Have they really 0 bytes? Do you have the files to copy opened in an editor which opened them with a read/write lock and therefore no other application can read the files on running the batch file? – Mofi Oct 26 '17 at 12:45
  • No error messages, and the files are 0 bytes. Copying the java file works just fine, it's just the txt files losing their data. – Waitwuut Oct 26 '17 at 13:04
-1

Reinstall windows, will fix all the problems

Waitwuut
  • 1
  • 3
  • In other words we can assume that you have used in your batch file twice just `xcopy` instead of `%SystemRoot%\System32\xcopy.exe` as posted be me in my answer and for that reason Windows command interpreter executed something different with file name `xcopy` in any other directory listed in `PATH` with a file extension listed in `PATHEXT`. And this alternate `xcopy` executable or script was able to copy correct just a single file like `"%~1.java"` but not a set of files matching the wildcard pattern `*.txt`. `PATH` and `PATHEXT` are now defined as they should after reinstalling Windows. – Mofi Oct 30 '17 at 06:04