6
1
I want to create a batch script that will run axis wsdl2java.bat for multiple WSDLs. When I create a batch script with just this code:
wsdl2java.bat
wsdl2java.bat
it would run wsdl2java.bat only once. I guess there is something with wsdl2java.bat batch script itself.
Can someone help me figure out what is the root cause of the problem?
dugokontov
Posted 2011-08-02T08:30:28.527
Reputation: 163
13
For compatibility with Microsoft's COMMAND, Microsoft's CMD has the bizarre semantic that invoking a command script within another command script terminates the invoking command script at that point.
The correct workaround for this is not the START command. Nor is it invoking a subsidiary command interpreter process with CMD (especially erroneously using /K for /C as well). It is — and has been for a couple of decades — the CALL command.
call wsdl2java.bat
call wsdl2java.bat
JdeBP
Posted 2011-08-02T08:30:28.527
Reputation: 23 855
1
Use cmd.exe /k filename.bat to launch each batchfile.
surfasb
Posted 2011-08-02T08:30:28.527
Reputation: 21 453
0
If I remember correctly, Windows switches completely to the new batch file when you start it from within another batch file and does not return.
The workaround would be to execute
start wsdl2java.bat
-- again, just from the top of my head. I could not find a reliable source in my short google research.
Update: as JdeBP pointed out, mine is the old wrong way. It may have been too obvious that I have not touched the innards of MSDOS or Windows CMD-shell or whatever it's called these days for some decades.
Update2: jeez, I said "off the top of my head".
brandstaetter
Posted 2011-08-02T08:30:28.527
Reputation: 4 119
1Yeah, back in the MSDOS days, that was the case. I'm not sure if that is still the case though. . . – surfasb – 2011-08-02T08:59:40.820
I didn't say that it was old, although it is in fact almost as old as call — start dating from approximately 1987. I said that it was wrong. Think carefully about what start actually does and compare and contrast that with what the questioner wants to happen. – JdeBP – 2011-08-08T00:39:17.657
thx for the answer, as well as for explanation. Works for me. As soon as I get some rep, I will vote it up also (: – dugokontov – 2011-08-02T12:03:55.040
Thanks for the correct answer. I also bow before your SUPERIOR knowledge, yet feel strangely offended by your tone. But hey, whatever floats your boat. – brandstaetter – 2011-08-02T13:00:42.173
The /C is still a valid method, just not preferred anymore. Deprecated, but still functional... – Brian Knoblauch – 2011-08-02T13:05:54.993
No, M. Knoblauch. Using a subsidiary command interpreter will prevent any environment changes made in the script from taking effect in the originally invoking command interpreter, which is the usual effect when the script is invoked directly. Both
STARTandCMD /Cdiffer in operation fromCALLin ways that mean that they aren't what's wanted in such circumstances as these. – JdeBP – 2011-08-02T15:13:09.267@JdeBP: Was
callpart of MSDOS? Or was that part of DRDOS? – Nils – 2011-08-02T19:42:01.137You're probably thinking of
– JdeBP – 2011-08-03T13:01:26.950INSTALLinCONFIG.SYS, which was a PC-DOS version 4 innovation.CALLis a built-in command in the command interpreter, and not an operating system thing at all. It's been inCOMMANDsince the version ofCOMMANDthat came with MS-DOS 3.3. It's in Microsoft'sCMDbecauseCMDcontinues the bizarre semantic ofCOMMANDwith respect to nested scripts.@Nils: Both. The CALL command was available in MS-DOS v3.1 ( http://support.microsoft.com/kb/34768 ), and as I recall DR-DOS introduced it first (I don't remember which version though). Before the CALL command was available, we had to use "Command.com /C name_of_target_batch_file.bat" for which the main disadvantages were that this consumed valuable RAM, loading TSRs would lead to instability after processing of the target batch file had completed, any altered environment variables would be lost, etc. The CALL command resolved all these problems well.
– Randolf Richardson – 2011-08-08T07:30:19.300