I cannot find an explanation for this phenomenon (same command gives an error and succeeds as well):
The only difference between the two lines is that
the first was pasted from a website but then edited manually to fit my custom path (the part between the "")
the second was typed manually entirely
I reproduced this each time: when running the pasted command I get an error, when I run the manually typed one, it succeeds.
I checked and triple checked for extra characters (empty trailing spaces). I also copied them in notepad++ and checked "show all characters" but nothing appeard. When I copy-pasted them back from notepad++, they both worked.
This thing also happens when trying to run a shortcut (which runs the command) created on the desktop (this is where it all started - the pasted command failed inexplicably).
Any idea?
Note: running on Windows7 x64 and the task scheduled is (as the name suggests) a disable of UAC for Visual Studio 2013 created as described here.
got it!! it's the " " - the pasted ones are not recognized (although in cmd they look the same as the typed ones). Apparently they are a different character (?)
I tryied copying from the website directly into notepad++ and they don't look the same:
Related
In my directory I have a file called "t1.ps1" and a second file called "t1 - something.ps1".
Both of them run fine when run fine, when executed via right click run with PowerShell or when executed directly in PowerShell, but when executed via double click or cmd it seems to always execute the first script.
For me it seems like the dash is the problem, but I was kinda surprised that windows did not just throw an error or just did nothing, but instead executed a different script.
Maybe this is a well known phenomena or i just have some jank settings, that made this happen, but I was kinda surprised about it.
By default, .ps1 files are NOT executed when you double-click them in File Explorer / on the Desktop - instead, they're opened for editing.
The fact that they are executed for you implies that you modified the default configuration:
However, the fact that double-clicking t1 - something.ps1 executes t1.ps1 instead implies that your configuration is flawed:
Specifically, it suggests that the file-name argument in the underlying powershell.exe command used for invocation lacks (effective) enclosing "..." quoting - as would happen if you had used File Explorer to interactively associate .ps1 files with powershell.exe.
See this answer for more information and a fix.
I have read somewhere, that the commands entered in the run dialog box are executed as if they are executed using the start command in CMD. Which I believed was the case (as i could executed applications registered at app paths key just by their name using run).
But i noticed a little bit of deviation from this behavior when I tried to run a command on run without extensions. To illustrate this behavior:-
I added .msc and .MSC (i am unaware of extension case sensitivity/insensitivity on windows) to the PATHEXT environment variable, such that it became like this:-
PATHEXT=.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.MSC;.msc
After this I executed the following command in CMD, to start the Device Manager:-
start devmgmt
Which lead to execution of Device Manager.
But when i typed in the following command in run dialog box:-
devmgmt
it prompted me with an error stating:-
Well, If my statement in the first paragraph is correct, then why did I ended up with an error in the second case?
P.S.:- Upon googling about this issue before, i read several article which stated run prompt inherits PATHEXT values of CMD, for extension resolution. And if it doesn't, then there exists an policy (in gpedit or something) which makes the run prompt only possess the default PATHEXT values!! (correct me if i was wrong here)
No matter what my code is, even if my batch file is syntactically incorrect, even if it is absolutely correct and even if there is nothing to display on the screen the batch file when executed just displays the code as it is.
I read a similar question MSDOS prints the whole batch file on screen instead of executing but since that was on MS-DOS I hoped my issue could have a solution different than that.
Eg,
#echo off
set abcd=4
Even its batch file would just display the same lines as it is.
Please help.
Try "resetting" cmd if possible. U can try copying someone else's "cmd.exe" and replace it with yours using another bootable OS as windows wont allow that.
Here use my cmd.exe. https://drive.google.com/open?id=0B6ghonMKBfUSLVpRV0U5bG5pQTQ
Just in case u need to know I am using Windows 10 64 bit.
Check the file with an editor that allows you to see the encoding.
For example Notepad++ , you will see is very different the end of line via CF (\r) and LF (\n)
Your CMD can be recognizing EOL via \n only.
To determine whether your issue is really with line breaks being converted by your text editor (as the post you mention suggests), perform the following test:
Open a Command Line Window
Type the following command: copy con test.bat
The cursor will reposition itself under the command prompt, this is normal
Type the following 3 commands, each followed by the [Enter] key:
.
Echo Off
Set abcd=4
Echo abcd
Press CTRL-Z simultaneously (it will show up on screen as ^Z)
A confimation message should state: 1 file(s) copied.
Now type Test to run the batch file. If it runs properly, it means you are indeed dealing with line termination issues. Use a different text editor (don't use Notepad!!!), ideally one where you have an option to display the line termination characters (I personnally use NotePad++, it works great for these kinds of things but there are many others out there).
Perhaps there is a problem with your environment variables. Check the following:
Press WIN + R and run "%SYSTEMROOT%\System32\SystemPropertiesAdvanced.exe"
Click on "Environment Variables"
The system variables are listed at the bottom. Select the variable "Path" and click "Edit..."
Check whether the list contains "C:\Windows\System32" or "%SYSTEMROOT%\System32". If not, add one of those. You may have to restart your computer afterwards.
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?