I tried installing Haskell using stack as given on this page https://docs.haskellstack.org/en/stable/install_and_upgrade/#windows
I have downloaded and installed Haskell.
When I try to run stack, it just runs through and closes in less than a second. Can somebody please clarify as to what is happening?
From the webpage you linked to:
"Unpack the archive and place stack.exe somewhere on your %PATH% (see Path section below) and you can then run stack on the command line."
If you double click on "stack"(.exe), it opens a command window, executes the program and closes again.
In other words, store "stack" in a directory that is in your PATH environment variable, then open cmd.exe and run stack.exe from there.
Usually if you run such a program without any parameters, some information should appear about how to proceed from there.
Related
now I'm currently using Visual Studio Code and I wanted to make the terminal use babun instead of the default cmd.exe
In fact, I have already managed to do that in theory - the problem is that, unlike with cmd.exe, the directory that I'm in upon starting the terminal is no longer the currently open project, it's just simply /home/myusername (i.e. a path in babun's directory tree).
This kinda sucks, since I don't really want to navigate to my directory every time.
Next, I also found out how to tell babun (in my case, zsh.exe) to use a default directory such as C:/ by adding cd /cygdrive/c to the end of .zshrc - Unfortunately, that's not what I want either, since I don't want babun to always use the same directory.
Now I figured that, seeing as this would be the most comfortable option with VSC*, there might be some console argument that tells zsh.exe to use a specific directory. Sadly, I couldn't find anything, hence this question.
Weirdly enough
Anyone know how to help me out? Appreciate the help :)
*VSC allows you to specify the path to your shell, as well as an array of arguments that will be passed.
You could place your directory into a cmd file and run it as a shell:
d:
#rem note that's important to change the drive 'permanently'
cd d:\home
zsh.exe
And then specify this cmd file as shell to invoke.
Open the desired directory in a file explorer, right click, then select Open Babun here.
Babun currently does not natively support a command line parameter specifying the directory to launch in.
However, there is a pull request in the Babun GitHub which solves the issue. Unfortunately, it doesn't seem to be likely to be accepted anytime soon, though.
To gain access to the feature manually, check out the pull request.
I was just curious as to why with Windows O/S a simple Ruby file that prints one line to the command prompt can execute correctly from one path, but not the other.
Currently, I have said file in C:\Ruby193\test\lib saved inside the lib folder. When I go to the command prompt and set the path to C:\Ruby193\test\lib, I'd expect to see the code string be printed to the command prompt. However, nothing but an empty line is produced, and if I go up the path and set it to C:\Ruby193\test and execute the ruby file from there, it works just fine.
Does anyone have a sound explanation as to why it works that way? Would this also be the same case for a MAC O/S as well?
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
I have installed ActivePerl on my Windows OS. I have followed below URL
procedure to install
ActivePerl Installation
After having done that, I have tried to run "perl -v " on the command line. But it reports the following error.
The system cannot execute the
specified program
What do I need to do to solve these issues?
I was facing a similar issue... but the thing was that I could execute the file by right clicking the file and opening it with perl command line interpreter.... but still the perl-v command would give the error... all I had to do was execute this command
set PATH=C:\Perl\bin;%PATH%
This solved the issue...
You need to make sure the directory where the Perl executable lives (it might be C:\perl\bin, but basically wherever you told ActiveState Perl to be installed) is in your PATH environmental variable (you can find the variable value by typing set PATH command on command line prompt in Windows).
If you're not sure where you installed Perl to (and can't find it in the default C:\perl\bin), you can find the directory by going to Start menu, finding ActiveState Perl folder, and right-clicking on "Perl Package Manager" icon, then pick "Properties" from the right-click menu. Properties window (in the "Shortcut" tab) will have a "Target" line showing the directory.
I was getting a similar error after installing ActiveState Perl on Windows 8 x64 bit edition and trying to invoke 'perl' at the command line.
'perl' is not recognized as an internal or external command, operable
program or batch file.
I remember selecting the option during installation to add the Perl directory to the system PATH environment, and after checking the system properties, it was indeed showing in the system PATH.
I tried installing 'Microsoft Visual C++ 2008 x86 and x64 redistributable setup' files as suggested by a few places but it still did not resolve the issue, until I tried some of the suggestions in this thread.
At the command prompt I entered:
set PATH
And surprisingly it did not list the Perl directories as being included in the PATH variables.
So to remedy that I entered this into the command prompt and hit enter:
set PATH=C:\Perl64\bin;C:\Perl64\site\bin;%PATH%
(The directory paths are for the 64 bit edition of Perl, adjust according to your installation) the %PATH% portion is important and ensures your existing settings are kept and not wiped out and overwritten when you set the PATH.
That fixed it and entering 'perl -v' into command prompt successfully replies your Perl version. If you had a PowerShell window open before setting the PATH variable, you will need to close it and re-open another instance of PowerShell.
I believe the original underlying issue was something to do with different PATH variables for 32-bit and 64-bit environments and possibly some internal Windows redirection that takes place automatically.
This doesn't sound like a problem with PATH - I would expect it to give the message 'perl' is not recognized as an internal or external command, operable program or batch file.
I have not seen this error message, but http://nirlevy.blogspot.com/2008/03/system-cannot-execute-specified-program.html makes some suggestion for related programs.
Or maybe ask on an Active State forum.
I had the same error. I was able to solve it by changing the order of the Perl64 entries in the PATH variable in the Environment Variables. I moved the C:\Perl64\bin to be before C:\Perl64\site\bin and it worked.
I had a similar error which was solved by adding the .pl extension to the script name, which I had forgotten to do.
I could not get it to work otherwise even with my Perl's location (C:\Apps\Perl\bin) verified as in %PATH%.
The problem lies in the installation directory.
The Perl PATH variable will be set to C:\Program Files\perl (depends on 32 or 64 bit of course), BUT, the default installation directory is C:\perl. This is kind of sneaky actually as you would assume the installer would be more intelligent about this, but it sets the environment variable to that directory no matter WHERE you install the damned thing.