I have a bat file (foo.bat) that has placeholders for parameters, like this:
@…\java\jre\bin\java -classpath …;…\classes;etc classToRun %1 %2
There’s a customer who opens a DOS window, navigates to the directory that contains foo.bat, and enters at the prompt:
foo -fXYZ
The classToRun is supposed to interpret the -fXYZ and use the value XYZ as a value for something.
When the customer runs this, the -fXYZ is not passed into the java class. I know this because I have added println statements in the class, and it acts as though it never gets the parameter passed in.
But if they modify the bat file as shown below,
@…\java\jre\bin\java -classpath …;…\classes;etc classToRun -fXYZ
and type at the DOS prompt:
foo
then everything works fine.
Why is this? They say it’s a Windows server. Is there some weird setting I don’t know about that would prevent someone from supplying a value via %1 in the DOS window??
My Windows batch file programming days are long behind me, so forgive me if this is a stupid idea, but is it possible that the problem is that you have “%1 %2” in your batch file, but you’re only passing in one parameter ("-fXYZ")?
Or, is %1 the command (“foo”), and %2 the parameter ("-fXYZ")? I think that’s how command-line arguments work in some programming languages.
Just a couple of WAGs for you. If they’re totally stupid, just consider this a bump.
Have you tried playing with quotation marks around your passed-in values and command lines? I seem to recall a similar problem where I needed to use quotes and wasn’t or vice-versa.
Does this work for other people and just not this one client, or does it not work correctly at all?
I think you are passing yout options to java instead of classToRun. Try changing your command to:
@…\java\jre\bin\java -classpath …;…\classes;etc “classToRun %1 %2”
My .bat knowledge is pretty weak (with good reason: extensive windows batch file knowledge is a sign of brain damage, IMHO), but here’s a really wild stab: Is the default CMD extensions mode different on Server? More background: The CMD processor has different modes it operates in which govern certain fundamental behaviors and extensions, and the default mode may be different between different OSes (e.g. CMD extensions may be on by default on XP because end-user functionality is important, but off on a Server OS because backward compatibility is paramount [note that I do not know this; it’s a guess]). You could try experimenting with the different enable/disable flags like /E /F and /V and see if a subtlety of one of those is coming into play. Also, changing the extension from .bat to .cmd will change the default behavior with respect to some of these, so you might try that and see what effect it has on this behavior.
Slightly offtopic, but BTW: there’s some CMD-fu that will get you the path and/or directory of the executing script so you can reference things like “…\java\etc” without needing to have the cwd be the script’s directory. I have no idea where to look this up (it’s not in the “cmd” or “set” help), but some scrounging in scripts other people wrote indicates that “%~d0%~p0” might be the magic you’re looking for that indicates the script’s drive and path.
Thanks for all the replies thus far. All the developers use the same bat file and command-line syntax, and it works fine for all of us. Also, this particular customer is the first and only one who has had a problem with this. So I don’t think it’s any basic problem with the syntax, quotes, etc.
I saw the problem today with the customer via WebEx, and they seemed to be doing exactly the same thing as all of us have been doing. I even made sure they had the right versions of the bat files, etc. But I didn’t ask them specifically what version of what OS they were using. I did ask “Is this regular Windows?” and they said “It’s a Window server.” (My own machine is XP Pro.)
Some suggestions, in addition to what Quartz said…
There is zero difference between Cmd.exe on XP and on WinServer 2003.
There is a feature called command extensions which can be enabled or disabled per machine. A typical modern installation has it enabled, which exposes a bunch of new (e.g. from 2000) functionality. I vaguely recall that it also slightly alters parameter parsing in some complex scenarios. If they have it off and your normal environment has it on, that’d be a possible source of the different behavior. Try cmd /? for more details.
If the parameter the customer is trying to pass contains embedded white space, then they need to enclose it in quotes:
C:…>foo.bat “-my filename contains spaces.txt” -param2
and even that won’t work right because that will become
… classtorun -my file name has spaces.txt -param2 which is unlikely to be what classtorun in expecting.
Typically you construct batch files with the assumption that any parameter might have mebedded whitespace. So foo.bat should read:
… classtorun “%1” “%2”
And then when the caller calls with
foo “-my filename has spaces.txt” -param2, the cmd parser properly tokenizes the twoparamnters & strips the quotes, so the value of %1 is just -my filename has spaces.txt. Then that is placed into the resulting command, so it reads
… classtorun “-my filename has spaces.txt” “-param2”
and then the cmd interpreter again properly tokenizes & trims the quotes when it builds the argv array, so argv[0] will end up with the value -my filename has spaces.txt, and argv[1] will be -param2.
4. Note also that the - symbol is NOT a parser special character in Cmd.exe. So if they’re just typing foo abc that will just replace %1 with abc in the results, and the resulting classtorun command may be lacking the “-” characters which it requires.
That’s one of those very obvious problems looking over somebody’s shoulder that can be all but impossible to diagnose over the phone. You know every paramster always starts with “-”, and they know paramters never use a leading dash. So you never communicate the difference correctly.
They were definitely typing exactly the same thing as we do, with the hyphen, and there are no embedded spaces in the parameter. I am thinking that ntucker and LSLGuy are on the right track, but I know nothing about command extensions but have googled it and haven’t found anything that seems particularly enlightening for this scenario.
Since they have a workaround it’s not a pressing problem anymore, but I am very curious about what may be happening. But not so curious that I want to get drawn into another WebEx session.
I didn’t actually watch them open the DOS window, they already had it open.