I've been struggling to create a .bat script for Windows for running the JMX console. I've managed to do it with some tricks, but there must be something very wrong I'm doing and I haven't found a solution after investigating and googling quite a bit, and many trials. If this question is a duplicate, I'll be happy to remove it.
This is my original script (an attempt to translate the script that I have running for Mac and Linux)
%JAVA_HOME%\bin\jconsole.exe -J-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%MY_JCONSOLE_PATH%\opendmk_jmxremote_optional_jar-1.0-b01-ea.jar service:jmx:jmxmp://<host>:<port>
The problems that I've faced:
jconsole.exe does not seem to run properly unless I do a cd to $JAVA_HOME\bin
cannot make the script (or maybe the jconsole) understand %JAVA_HOME%\lib, and I had to add a new environment variable
This is my working version to address the problems above:
set MY_PATH=%cd%
cd %JAVA_HOME%\bin
jconsole.exe -J-Djava.class.path=%JAVA_BIN%\jconsole.jar;%JAVA_BIN%\tools.jar;%MY_PATH%\opendmk_jmxremote_optional_jar-1.0-b01-ea.jar service:jmx:jmxmp://<host>:<port>
But it is not very clean and I'd just like to know what mistake(s) I'm doing. I'd just like to know!
Many thanks!
Sometimes you leave a problem for a couple of days and with a fresh mind you solve it... in case it helps anybody, solution is as follows,
set MY_PATH=%cd%
"%JAVA_HOME%\bin\jconsole.exe" -J"-Djava.class.path=%JAVA_HOME%\lib\jconsole.jar;%JAVA_HOME%\lib\tools.jar;%MY_PATH%\opendmk_jmxremote_optional_jar-1.0-b01-ea.jar" service:jmx:jmxmp://<host>:<port>
The problem seems to be related to the fact that the directory Program Files has a space on it, however the double quotes " cannot be put just anywhere (e.g. I tried to define the environment variable JAVA_HOME as C:\"Program Files"\Java\jdk... but that did not help.
I am trying to optimize W7 UI for a laptop with a wide screen by putting the taskbar on the left and making it thin. I managed this a couple of ways the most successfully by restarting UxSms with Task Scheduler and a batch file. This source is what gave me the idea that I could run the batch with Regedit.
The actual question I would like to answer is why the .reg I made merged without error, but didn't create a key that I could find or seem to run anything when the previously mentioned "This source" seems to suggest that it should work. Obviously I made a mistake, but would really like to understand it.
Name of file: ThinTask.reg
REGEDIT4
; #ECHO OFF
; CLS
; REGEDIT.EXE /S "%~f0"
; net stop "UxSms"
; net start "UxSms"
; EXIT
[HKEY_CURRENT_USERSOFTWAREMicrosoftWindowsCurrentVersionRun] "ThinTask"="Succeeded"
The batch I want to run is really just:
net stop "UxSms"
net start "UxSms"
Any ideas on where I went wrong? Thank you for your time any comments, suggestions, or resources are most welcome.
My dumb mistake. Suppose to save it as a .bac not .reg. No wonder the registry didn't know what to do if I'm trying to run it that way and the whole thing is commented out.
...have been running Widows 7 Pro with STARTUP folder modified to run two BATs to create two CMD boxes, one left and one right. A few days ago at logoff time 13 updates to Windows7 were installed and at logon the next day the two CMD boxes had a new error message preceding the command prompt:
"Not enough storage is available to process this command."
Typing in "DIR /X" at the command prompt does return the directory list but with three error messages:
1. The system cannot find message text for message number 0x235f in the message file for Application.
2. The system cannot find message text for message number 0x235b in the message file for Application.
3. DNS bad key
...i.e. none of the usual DIR text annotations.
Now, from the command line, any BAT file with "cmd /k" in it produces the same box with the same errors.
Modifying a BAT file to call "C:Windows\System32\cmd.exe /k" instead of simply "cmd /k" solves the BAT problem on the command line...AND making this change in the two STARTUP BATs solves the problem at startup. However, this is just a temporary work-around. The bare "cmd" without the full path will fail.
CORRECTION: as suggested by Harry Johnston below, there was another cmd.exe present, this one in C: identical to the one in C:\Windows\System32 and after giving it an alias the STARTUP BATs work OK. So this post becomes a trivial anomaly which may or may not have resulted from a Windows update, and may be deleted.
Does anyone know what updates to Win7 caused this problem, and how they might be uninstalled. Good ol' WinXP would have a long list of them.
There's a lot of interesting and relevant info here:
https://superuser.com/questions/159034/spurious-out-of-memory
and here:
http://blog.airesoft.co.uk/2009/10/desktop-heap-monitor-vista-7/
but maybe someone has a quick answer.
..Thanks for any reply.
Encountered same problem, And there was a spurious copy of "cmd" sitting around. Tx
This is just bizarre. I've got a .bat file that I run using Windows 7's scheduler, and I noticed after I made an update to it, that it was still acting as though it were running the old version of the .bat program.
It's easy to tell which one ran - they output to a .txt file, and the new version dumps a lot more information. So here's what happens under three scenarios:
Open a cmd window (with right-click and "Run As Administrator"). CD to the directory and execute setvispw.bat in the usual way, by typing "setvispw.bat" and hitting Enter.
Result: current version runs as expected.
Right-click setvispw.bat and "Open"
Result: current version runs as expected. But that's not good, because I'm changing another user's password and need Admin privileges.
Right-click setvispw.bat and "Run As Administrator".
Result: something else runs! It looks like it's running the version from before I made changes to the .bat just a few days ago.
So I tried something even more strange. I replaced my functional program with a dummy program... and it was running the dummy program.
Finally, I added some "pause" statements... and that's when I got the answer. Rather than discard this bit of troubleshooting, I'll use the "Answer your own darned question" feature.
It turns out the problem was that I was depending on the output to setvispw.bat to tell me what version of the program had run. Well, both the old and new versions had this line:
echo Random string is !_RndAlphaNum! > C:\pathname\curVisitorPW.txt
But my added line was like this:
echo Sending email: >> curVisitorPW.txt
When I ran from C:\pathname, either in a CMD window or without Admin privileges, it worked just fine. But when I ran with Admin privs, like it does from the Scheduler, the working directory isn't C:\pathname - it's C:\Windows\System32. I didn't see that until I added the "pause" and saw that I wasn't running where I expeted! Sure enough, there's a curVisitorPW.txt sitting there in System32.
The solution, of course, was simple - use the fully qualified pathname.
Hopefully this will come in handy if someone like me is seeing bizarre behavior in a .bat file, and starts wondering if there's some sort of caching, or admin permissions/privileges, or something else crazy. I was ready to pin it on gremlins, myself.
Closed. This question needs debugging details. It is not currently accepting answers.
Edit the question to include desired behavior, a specific problem or error, and the shortest code necessary to reproduce the problem. This will help others answer the question.
Closed 29 days ago.
The community reviewed whether to reopen this question 29 days ago and left it closed:
Original close reason(s) were not resolved
Improve this question
I am having a problem executing a bat file. After some time running I get the "input line is too long" error.
The structure of the bat file is simple. There is a main bat file that calls 10 other bat files that are responsible for updating data of my system modules. In the updating data bat files there are lot of calls for a command(.cmd file) of my system that is responsible for updating the data through some calculations.
The point is, when the process was running in a Windows 2003 Server it was ok. No errors.
Then, when it was upgraded to Windows 2008 Server, I execute the main bat file, several hours later I got the "Input line is too long" error. I can't even execute any command included in the updated data bats manually in that cmd window. But if I close the cmd window and open a new one I can execute the commands without errors.
What's the solution to this?
I have had this same problem when executing a build script in a cmd window. After about 13 times I got that same error. The build script had to make sure that vcvarsall.bat was run so it executed vcvarsall.bat every time.
vcvarsall.bat is not smart enough to only add things to the path if they are not already there so a bunch of duplicate entries were added.
My solution was to add an if defined check on an environment variable which I know is set by vcvarsall.bat...
if not defined DevEnvDir (
call vcvarsall.bat
)
Check your path environment variable after each run and see if it is growing. If it is and there are duplicates, you will need to be smart about adding stuff to the path. There are several ways to be smart about it.
I happened upon this error just now for the first time after running the same set of commands (stop / start an application server) a number of times.
The error stopped when I opened up a new command line and tried the commands from the new command line console.
This usually happens due to long path. I have resolved this issue by replacing base path of Kafka from C:\Program Files<Kafka_path> to C:\Kafka
I realize this is pretty old, but the other issue I ran into was having a " at the end of the command I was calling. I was attempting to call:
"C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\..\IDE\CommonExtensions\Microsoft\TestWindow\vstest.console.exe""
If you notice, I have two " at the end of the line. This was causing my issues (Notepad++ included it when I typed the quotes). Removed that, all good. Again, may not be your issue, but if anyone else comes seeking info and nothing else works, check this. :)
There is a Windows knowledge base article on this subject. They don't mention Windows 2008 server, but they did mention the difference in size between other versions of the OS, so it wouldn't be surprising is there was a difference between 2003 and 2008.
As for solutions to the problem, some of their suggestions include:
Modify programs that require long command lines so that they use a file that contains the parameter information, and then include the name of the file in the command line.
Use shorter names for folders and files.
Reduce the depth of folder trees.
You can read the whole article if you want to see what else they have to say, but those were the suggestions that looked most likely to apply to you.
Rename the folder name to Kafka . It worked fine for me . Close the cmd and start it again . That will definitely work fine !!
Before :
After :
I have the same issue to start zookeeper under window. The root cause is due to file path is too long. I relocated the kafka folder to shorter file path. For example : c:/kafka_2.13-2.6.0. then cd to bin/windows and start zookeeper. It works.
when it's necessary to call vcvarscall.bat multiple times, then:
setlocal
vcvarsall.bat x64
cl xxx.cpp
endlocal
setlocal
vcvarsall.bat x86
cl xxx.cpp
endlocal
It can also happen if the spaces in your file (ansi character 0x20) are really non-breaking spaces (I had 0xA0, but yours may vary). This can happen if you copy/pasted from the internet to a UTF-8 aware editor.
The result depends on the current codepage of windows, your editor and such. To fix:
Use an hexadecimal editor
Look at how spaces are represented
Search and replace your representation
I used HxD to search and replace 0xA0 to 0x20.
using CALL several times to run another batch that sets env will increment the value of the var you are setting,hence the error at some point
call set path=some\path;%path%
running the above command in cmd for many times will produce the error
I ran into this also.
I was trying to run vcvars.bat as others here seem to be trying.
The underlying problem for me seemed to be that my PATH variable was polluted with repeats of an already pretty lengthy path. Fixing up my path seemed to fix the issue for me (in a new terminal, of course). Note that this fix isn't specific to vcvars.bat or anything Visual Studio related.
I'm curious if Cookie Butter's solution is a workaround and the underlying problem is the same.
This happens due to long path or long name of directory . I have resolved this by renaming the folder name by removing the version from it and placing the folder to c: directory.
Example -
from = C:\Users\rsola\Downloads\kafka_2.13-3.3.1
to = C:\kafka