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.
Related
I use Windows 10. When I run Heroku Cli (64) installation I get an error "PATH not updated, original length 1585 > 1024". How to solve this problem?
I got it to work on Windows 10.
I tried two things and I'm unsure which one got Heroku to work. The first thing you can try is adding it to PATH in CMD or Git Bash in this post.
You should also try to manually add it to PATH by going to Settings->Advanced System Settings->Environment Variables and adding a system variable with name PATH and with value "C:\Program Files\Heroku\bin" or wherever you have your heroku.exe file.
This will manually update the PATH.
I may be too late to answer this question but I'll share what worked for me, in case some one else ran into the same issue.
Basically, with time my path variable had too many variables added to it, and apparently, there is a characters limit that can be added to the PATH variable.
I deleted a few variables in the PATH that I do not need anymore, and that was all!
The Installer is trying to apply an environment variable to the Path. But there are already too many variables setup. Delete the ones that you no longer require and it should work.
You could access the System Environment variables by visiting- Settings->Advanced System Settings->Environment Variables
I just came across with the same problem. The solution I used is similar to selflearningcode but instead of setting a system variable which failed, I set a user variable.
Try this after selflearningcode's answer, if you can echo %PATH% and it displays heroku you should be good to go. Else, set a user variable on the same screen by adding a new entry to the path and it should work.
Note: Start a new terminal for the effects to be visible.
You might have to set Environment variables in Advanced System Settings.
If there is already a path defined, just append your path with ;
ex:
Existing path(It can be anything, just as an example): C:\Program Files (x86)\Google\Chrome\Application
If you want to add heroku path: C:\Program Files (x86)\Google\Chrome\Application;C:\Program Files\Heroku\bin
Hope it works.
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
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.
I have a small problem with make and mingw. I usually use Linux and I am not really familiar with windows way of doing.
C:\MingGW\bin is in my path (I can launch directly g++ or sh by the windows command line) but when I try to type make I have the following error :
make: g++: command not found
I do not know which make is use (no make in C:\MinGw\bin) and I do not know the equivalent of which in windows. Do I have forgotten an essential step ?
Thanks for your help.
Try mingw32-make instead.
Use this command to find out which one you're running:
for %i in (make.exe) do #echo. %~$PATH:i
It's basically the equivalent of which for Windows, assuming you know the extension. If you want a script that will check all extensions, you can find it here.
As pointed out in a comment by Chris, latter versions of Windows (Vista, 2003 Server, and Win7, I think) actually have a real equivalent called where, which may be better. Those of us still stuck back on XP can use the command above (or the big script at the other end of that link).
Are you sure there is no make ? Once do "where make" to confirm this and check the entries you get under C:\mingW\bin. Hopefully you will get a entry mingw-32-make.exe or something like that.
All you need to do is rename (better create a copy and rename) this exe as make.exe and if you have already added the environment variable of this path then you may now be able to issue make command happily under mingw.
The same is already done for g++,gcc, etc. They might have conveniently left make the way it is. Hope this helps
I'm having a weird problem with running cl.exe that has me stumped. In a large VS2008 solution consisting of C/C++ projects, I have one project that runs some scripts to do some extra processing. The project consists of a pre-build event, which calls a Perl script (ActiveState Perl is on the machine). This Perl script then calls cl.exe with /E to generate preprocessed output which gets redirected to a file. The line in Perl looks like this:
my $foo = `"\path\to\cl.exe" #args.rsp >out.txt 2>err.txt`;
args.rsp is a plain text file that contains a bunch of command line args for cl.exe, including /E to get pre-processor output on stdout.
This exact command line works as expected when run from the VS2008 command prompt. Building the project also works fine on my Windows XP machine. However, on my new Windows 7 box, when I build the project, out.txt ends up blank. I should also add that on some of my coworker's Windows 7 boxes, it works fine, and on some others it doesn't.
Clearly there's some kind of configuration difference going on, but I'm at a loss as to what it may be. We've checked matching versions of VS2008 SP1 and ActiveState Perl. I've tried myriad workarounds within the perl script - using system() instead of backticks, using cl.exe /P to output to a file and then moving the file (the file is blank), unsetting the VS_UNICODE_OUTPUT environment variable (no effect). Nothing has changed the behavior - output is generated when the command line is run manually, but not when it's run inside the pre-build event for this project.
Any ideas on what kind of configuration problem may be causing this? I'm pretty much out of avenues to pursue.
Sounds like an ACL issue to me. You can change windows to log access issues and then check the event log to see what user is getting access denied errors.
I believe the setting is in Local Policy | Audit Policy | Audit Object Access
Wow, the solution to this ended up being a lot stranger than I expected. The machine I'm working on (and the other co-workers who are also experiencing the problem) is a Mac Pro with bootcamp and Windows 7 installed. That causes C: to have the windows drive and E: to have the mac drive. This causes a problem because the pre-build event has a couple lines that test each drive letter to see if there's a drive there, and if there is, adds X:\Perl\bin to the path. Even though E:\Perl\bin doesn't exist, it gets added to the path. Later, the perl script runs and then calls cl.exe, and for some reason, having a directory in the mac drive causes cl.exe to fail. Why? I have no idea. Anyway, removing the mac drive directory from the path fixes the problem!
Thanks for your eyes everyone.
Check out the exit code of your program. You may want to build your executable name in a portable way using something like File::Spec. Also, check that #args is not interpolating. You may want to print your command line before executing to check if that's what you want. What is left your err.txt file?