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
Related
I have been running a command line program (Closure compiler) in Cygwin on Windows 7 (no comment please) that takes file arguments. It used to be that, for both the program and when I typed
echo dir/**/*
it would include all subdirectories and files, regardless of how deep. Now, it only returns the directories and files on the second level. I have not changed anything. I updated Windows at one point, but I did not think that that would affect anything. Does anyone have any suggestions on how to figure out what changed or how to fix this?
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.
...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
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).
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?