I try to compile project using PowerShell command.
Problem is that there is a lot of arguments (75000 characters)
When I try to run compilation I got error:
This command cannot be run due to the error: The filename or extension is too long.
I have also changed value in registry HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\FileSystem\LongPathsEnabled but it didn’t helped.
I am using Windows 10 Pro.
Do you know where can be problem?
Just in case this grabs anyone else. I received this error but the real problem was my StartInfo.Arguments value was too big. It had nothing to do with the filename I was specifying.
Related
I'm in Windows 10 & I'm trying to open an app using start command which goes like:
start "C:\Program Files\MyElectronApp\MyElectronApp.exe" which opens the app as expected.
I also want to pass some arguments after the above-mentioned command such as:
start "C:\Program Files\MyElectronApp\MyElectronApp.exe" --UUID=762835745634 --org_token=r8347t89457
When I write this command, I get UUID as /prefetch:1 despite passing any thing, I tried adding double quotes "", but same issue. However, I manage to get org_token as expected. as shown in the screenshot.
What could be causing this issue?
What I tried to address the issue?
I tried to add double quotes for the value of UUID, then I tried to use powershell and git bash for the same thinking it could solve the issue. Then, I checked the prefetch folder only to find it's empty. Then, I changed the order of args, but nothing happened.
Here's how I solved it:
The args should NOT be in UPPERCASE, in this case it's UUID, I changed it to small case uuid. For windows uppercase args are reserved or fixed for some DOS-level stuff.
Just change:
start "C:\Program Files\MyElectronApp\MyElectronApp.exe" --UUID=762835745634 --org_token=r8347t89457
to
start "C:\Program Files\MyElectronApp\MyElectronApp.exe" --uuid=762835745634 --org_token=r8347t89457
The exact reason for this is not clear as I couldn't find one. Will certainly update this once I get to know the same.
I just spent some time messing around with my environment variables. I used to be able to type "atom [filename]" into the command prompt and it would open the file in atom (provided I was in the correct directory). Now when I try this, I get the following message:
'atom' is not recognized as an internal or external command,
operable program or batch file.
I've looked at several threads about this and I have added the path:
C:\Users\[username]\AppData\Local\atom\bin
to my Path variables (both user and system). Why is it still not working? It has worked in the past and I'm not sure what has changed.
1/3/2019 Update:
I can open it if I type atom.cmd, but when I removed the .cmd extension and it stopped working. I still am not quite sure why it can't be recognized as a command without this extension as my computer did used to be able to recognize it.
Found the issue:
In my system variable PATHEXT, I did not have the extension cmd, just CMD. These extensions are clearly case sensitive, because adding cmd fixed the problem.
I called exe file from Vb6.
Shell "D:\Sample.exe RpNo, PrtVw, glngbr".
We are getting error exe stopped working
I meant to post this as a comment but don't have enough rep to do that.
First of all Shell "D:\Sample.exe RpNo, PrtVw, glngbr" I think the only part of the name of the program you are trying to open is only "D:\Sample.exe" and the rest without the "" quotes so you can try Shell "D:\Sample.exe", RpNo, PrtVw, glngbr
Secondly try opening the program you want to open with the shell statement and see if you get the same error because getting that error should have nothing to do with the program you used to open it the error would be coming from the program "Sample.exe" also what is RpNo, PrtVw, glngbr I've never seen that before, and tried that myself and it didn't work at all, try these out and I hope this helps.
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
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?