I have a Windows batch script that I use to build a module and the script in turn uses the ClearCase clearmake command to drive the actual compilations, directory creations and file manipulations, i.e. process the Makefile content. The batch script works flawlessly when invoked using a DOS window or from a "cmd /c ..." command line invocation. And it has been that way for some number of years.
I recently decided to move the script to Ant. The first step, out of simplicity, was to simply invoke the script unchanged using an Exec task (using cmd /c). Almost immediately, Ant fails while creating a directory. The error message reports something like:
mkdir: Cannot create the directory C:\\fred\\harry\\joe
I was able to verify that, using the DOS command prompt, the mkdir C:\\fred\\harry\\joe command works fine, so, as near as I can tell so far, Ant generating double backslash path separators combined with something inherent to clearmake and/or something in the Makefile is causing the failure.
The response I'm looking for is something along the lines: "Yes, clearmake is definitely the culprit because..." or "If you twiddle this thing or that thing in Ant, only a single backslash will be generated...". Should there be no simple and quick explanation, I will drill into the problem to determine what exactly is causing the failure.
Thanks,
I have seen similar error with:
dynamic views (more sensible to ownership than a snapshot view on C:\, which is your case)
resource handle conflict (the script tries to update a resource already taken by another process, which shouldn't be the case here with your script, since it was working outside of Ant Exec task)
error message (like you create a directory which already exists: the error get ignored in a classic script, while it could interrupt the ant task.
While the last cause is a good candidate, try first to simplify your script (leave only the mkdir for instance) in order to check that this line is indeed the issue (nd not "this line in conjunction with others actions taking place just before")
Related
I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?
I run a batch file as an external tool (by adding it in Tools->External tools) in VS2010 (I've checked the "Use Output Window" option). This batch file performs compilation as in VS command prompt. The project that I'm working on has makefiles for various folders, so I use the mk command to build.
In the batch file, I set up the VS environment and then run the following commands:
cd $directoryWhichContainsFileToBuild
mk
cd main //This directory contains the executable that is to be built
mk
I see the output of the first mk in the Output window but after that it just hangs. I also tried to use an echo after the first mk but even that doesn't get printed in the output window (the ones before it can be seen).
Somewhere I read that there is an issue with VS 2010 output window where it hangs after showing some output, although I couldn't really be sure that that is what's the issue here.
Do I need to enable some other VS setting? Has anybody else encountered this issue?
Thanks.
Update: I unchecked the "Use Output Window" and "Close on exit" option, and I see an extra statement: "Press any key to continue". On doing that however, their is no further processing of the batch file.
Update2: Got it to work by prefixing mk with "call".
Thanks all who tried.
It is always good in batch files to specify executables with full path and file extension instead of just the file name. This avoids often lots of problems.
Here was just mk used instead of mk.bat. Therefore on every compile the command line processor cmd.exe searches for mk.* and then checks if any of the found files have an extension listed in environment variable PATHEXT. The order of file extensions separated by a semicolon in PATHEXT defines the order of execution in case of a directory contains multiple mk.* files.
If a command being specified in a batch file not being an internal command of cmd.exe without path, command line processor searches first for a file with given name in current working directory. This is often one more cause of error. What is the current working directory on execution of the batch file?
Next if no file to execute can be found in current working directory, the command line processor searches in all folders being listed in environment variable PATH separated by semicolons.
So specifying in batch files edited only rarely an external application or another batch file with full path, file name and file extension, in double quotes if necessary because of 1 or more spaces in path or file name, helps command line processor to more quickly execute that application or batch file and avoids problems because of executable not found (unknown command).
Sure, when typing commands in a command prompt window, nobody wants to enter the executables with full path, name and extension. But for batch files it is always good to be not lazy and type files to be executed with full path and extension.
TripeHound has given already the explanation why the observed behavior occurred here.
If a batch file is executed from another batch file without using command call, the command line processor continues batch execution in the other batch file and does never come back. In a C/C++ program this is like using goto with the difference that parameters can be passed to the batch file containing the further commands to be executed next.
But running from within a batch file another batch file with call results in continuation of execution below the line calling the other batch file once the other batch file reaches end, except command exit is used in the called batch file without parameter /B.
So the solution here is using:
cd /D "Directory\Which\Contains\File\To\Build"
call "Path\Containing\Batch\File\To\Build\mk.bat"
rem With mk.bat not changing current working directory change working
rem directory to the directory containing the executable to be built.
cd main
call "Path\Containing\Batch\File\To\Build\mk.bat"
BTW: exit exits command processor, exit /B exits just current batch file. I'll give you three guesses why the parameter is B and not a different letter. Yes, B is the first letter of batch.
Writing as a separate answer instead of an update in the question itself as many readers see the header and skim to the answer: got it to work by prefixing mk with "call". (#TripleHound has also posted the conceptual reason for it in the comment above.)
I've read this discussion but despite different attempts, I get an error (it varies depending on my approach).
The compilation itself works fine. Double-clicking on the "publish.bat" files executes it just fine too. It's the combo in VS10 that breaks.
This is what I've tested.
$(OutDir)\publish.bat
"$(OutDir)\publish.bat"
$(OutDir)publish.bat
"$(OutDir)publish.bat"
call $(OutDir)\publish.bat
call "$(OutDir)\publish.bat"
call $(OutDir)publish.bat
call "$(OutDir)publish.bat"
What am I missing?
I had a similar problem that I was just able to fix. For me the simple call "$(SolutionDir)\Setup\CreateInstaller.bat" worked, but I kept getting a The command "call {solution directory}\Setup\CreateInstaller.bat" exited with code {code}. Turns out my batch file was expecting to be run from the directory in which it lived. So, check that all the commands in the batch file are not using relative directories or commands as these may break.
Also, are you sure the $(OutDir) macro is what you want? In VS2010 at least, that is just equal to bin\Debug or bin\Release depending on which version you're building in. It seems unlikely that you really want that directory. I expect what you want is $(SolutionDir) or perhaps even $(TargetDir).
When attempting runCommand("cd", "..") from inside a js.jar console an IOException is thrown.
I believe it's because in the command prompt the CD command is actually built into the console and not a separate .exe file. The runCommand("notepad") works fine, and that .exe can be found on the classpath in the usual location.
Is there a work around for this?
I was thinking that changing the directory through java instead of through the command prompt it might solve this problem, but I don't recall how to do that from java, but I plan on trying to figure that out.
To sum up: Is there a way to run "cd" from within a Rhino JS console on windows?
Thanks,
L-
Multiple issues to solve here; it depends what you are trying to do.
runCommand actually runs executable programs. cd is not an executable on Windows; it is a command in the command shell. So you would need to execute something more like this:
runCommand("cmd","/c","cd <target-directory>")
However, the underlying Java runtime does not allow you to actually change the working directory anyway. See this StackOverflow discussion. So shelling out cd just changes the directory for the subprocess (the process running cd), which is probably not what you want.
This is probably batch scripting 101, but I can't find any clear explanation/documentation on why this is happening or if my workaround is actually the solution. So basically any terminology or links to good sources is really appreciated.
So I have a program I want to execute via batch script (along with several other programs). It's the only one where the exe is not in a Program Files folder. I can get it to start like this:
C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe
But I get an error along the lines of:
Run-time Error '3024':
Could not find file
C:\Users\MyUserName\Desktop\ModuleSettings.mdb
So it seems that the program is looking for its settings files from the same location that the batch script starts up. Given that I finally got everything to work by doing the following:
cd C:\WeirdProgram\WeirdProgramModule\
weirdmodule.exe
That works fine, and it's not the end of the world to have to go this route (just one extra line), but I've convinced myself that I'm doing something wrong based on lack of basic understanding.
Anybody know or can point me to why it works this way?
Oh, and doing the following:
start "C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe"
doesn't do anything at all.
Thanks,
you are doing it perfectly :-)
the executable is probably looking for this file in the "current working directory", which is being set, when you "cd" to it before.
you can set your working directory manually by creating a shortcut to your batch file; right click; properties.
edit:
you can also set your current working directory using the start command:
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe"
edit:
If you like to pass params, just add them to the executable filename as you would in a regular shortcut:
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe" "param1 param2"
or
start "Title" /D "C:\WeirdProgram\WeirdProgramModule\" "weirdmodule.exe param1 param2"
For reference, the syntax is described here: http://www.microsoft.com/resources/documentation/windows/xp/all/proddocs/en-us/ntcmds.mspx?mfr=true.
What's happening is that weirdmodule.exe is looking in the "current directory" for the .mdb file. You might be able to tell it where to find the .mdb file through a command line parameter or some other configuration method (registry or .ini file maybe). How you'd specify the location is entirely up to the weirdmodule.exe program, though.
Other than that, your current workaround is probably what you're stuck with.
As far as your problem with using start.exe... the start.exe program has the very, very odd behavior (bizarre behavior in my opinion) of treating the first parameter as the 'title' to put in the window if (and only if) the first parameter is in quotes. So you have a couple of options:
Don't use quotes to specify the program. This works for you because you don't need quotes (there aren't any spaces or other special characters in the path that would require quoting it):
start C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe
Give an empty (or some other string) title as the first parameter. This is something you'd have to do if your path required quotes:
start "" "C:\WeirdProgram\WeirdProgramModule\weirdmodule.exe"