In Running JMeter jmeter.bat is defined for windows
To run JMeter, run the jmeter.bat (for Windows) or jmeter (for Unix) file. These files are found in the bin directory.
I'm able to run also jmeter.sh in windows using Git Bash and it's working fine.
Are there any benefits or issues in executing jmeter.sh on windows ?
The benefits is that Git Bash is not provided OOTB on Windows while regular bat is.
Except for this, since git bash is a shell emulator which looks rather serious, I guess it should work fine.
Did you try it at high load to see if you face any limits ?
Also you can see some comparison of Windows shells:
https://macyves.wordpress.com/2014/09/18/hipsterising-windows-cygwin-vs-babun-vs-git-bash-vs-powershell-the-onion-scale/
Related
I'm using cypress for test automation and when running a test spec from the Git for Windows bash terminal I get weird characters in the results output:
cypress spec run in Git for Windows bash -
If I run cypress from a Windows command prompt the output characters are correct:
cypress spec run in Windows Command Prompt -
I'm using Windows 7, cypress 5.1.0, and Git for Windows 2.28.0 with mintty 3.2.0
Any thoughts on how to correct this?
The issue is described in this GitHub issue.
The problem is that Cypress is sending UTF-8 encoded text through its stdout which is mangled by Windows before being received by Mintty (which is what hosts bash and runs git on Windows).
I understand that Mintty doesn't yet instruct Windows to not mangle the stdout it processes - (cmd.exe does, however, which is why it works there) - but we can do that ourselves by changing our Windows OEM Code Page setting using the chcp program (located at C:\Windows\System32\chcp.com and yes, that's a .com, not .exe). You can add a command to your .bashrc file so it will always run when you fire up Mintty:
Open mintty on Windows - presumably this starts a bash shell.
Go to your home directory (i.e. cd ~)
Open or create a .bashrc file.
Put this in the file (update the path to your chp.com program as appropriate):
/c/Windows/System32/chcp.com 65001
Then restart the terminal window and it should work.
As both #digijay and #Dai replied above the cause of the issue is described here https://github.com/git-for-windows/git/issues/2806
The issue was resolved with the next release of git-for-windows. Prior to the fix being released, I solved the issue for myself by simply running this at the bash command line before running my cypress run command:
> cmd //c chcp 65001
I am following this tutorial where i have to run this command in order to start the zookeeper server.
./bin/zookeeper-server-start.sh config/zookeeper.properties
But the problem is this command is not working properly. I found that .sh file is bash file that required cygwin. I have installed it and then run command like this
C:\cygwin64\bin\bash.exe ./bin/zookeeper-server-start.sh config/zookeeper.properties
But it is showing:
I can confirm that in bin directory the file is exsits. what i am doing wrong?
Here is my directory snapshot from where i running the command:
Note: I have successfully tested bin/windows zookeeper bat file but i want to run it through .sh file as the kafka security tutorial which i am following using this.
From your screenshot, I conclude that you are using Cygwin. So, please add the cygwin tag to your question.
As you can see from the error message, the command dirname is not found by bash, so assuming that your Cygwin installation is not broken, I assume that the PATH is not set correctly; in your setup, dirname.exe should be in C:/cygwin64/bin (please verify this).
Your usage of bash.exe is a bit unusual in that you run it directly from a Windows cmd prompt. The more common way would be to use it from the 'Cygwin Terminal', which you get created a Windows-link to, when installing Cygwin, or to use another suitable Terminal program; I'm using for instance mintty for this task (also available via the Cygwin installer).
Having said this, it is possible to run bash.exe in the way you are doing it, but you then have to ensure, that at least the PATH is set up correctly. One possibility to do this, is to add C:\cygwin64\bin to your Windows PATH, but this has the drawback, that some commands have the same name in the Windows world and in Cygwin, though they serve a completely different purpose, and this will bite you sooner or later. Another problem is that at some point, you will rely on other bash specific setups besides the PATH.
A better way to accomplish your goal is IMO to ensure, that the system wide bash-initialization files are sourced by bash. If I have to run the script from a Windows cmd prompt, I would run it by
C:\cygwin64\bin\bash.exe --login YOURSCRIPT
This will read the file (in your setup) C:\cygwin64\etc\profile before running YOURSCRIPT, so you can check, that the PATH is correctly set there, by looking at this file. In a default installation, this should be the case.
After having read this file, it will try to read the file .bash_profile in your Cygwin HOME directory, so if you need additional settings for your (non-interactive) bash-scripts, create this file and put your settings there.
I want to run a bash script on a mac remotely from a batch script on a windows machine. On Windows I have this:
#echo off
echo bash /applications/snowflake/table-updater/test2.sh; exit>tmp_file
putty -ssh User#remote_machine -pw password -m tmp_file
And here is test2.sh on the remote machine
#!/bin/bash
# test2.sh
#
#
7za x table-apps.zip -y -o/Applications/snowflake/applications
When the batch file runs it logs in successfully, but for some reason fails to run the bash file. However the bash file runs fine from mac terminal, where it unzips the files perfectly. What could be happening here?
Please note test2.sh is actually in Applications/snowflake/table-updater as specified in the batch file. And the tmp file does write fine as well. My aim is to have a script to access a further 10 remote machines with the same directory structure.
Thanks in advance
The standard program which resembles the scriptable Unix command ssh in the PuTTy suite is called plink, and would probably be the recommended tool here. The putty program adds a substantial terminal emulation layer which is unnecessary for noninteractive scripting (drawing of terminal windows, managing their layout, cursor addressing, fonts, etc) and it lacks the simple feature to specify a command directly as an argument.
plink user#remote_machine -pw password /Applications/snowflake/table-updater/test2.sh
From your comments, it appears that the problem is actually in your script, not in how you are connecting. If you get 7za: command not found your script is being executed successfully, but fails because of a PATH problem.
At the prompt, any command you execute will receive a copy of your interactive environment. A self-sufficient script should take care to set up the environment for itself if it needs resources from non-standard locations. In your case, I would add the following before the 7za invocation:
PATH=$PATH:/Applications/snowflake/table-updater
which augments the standard PATH with the location where you apparently have 7za installed. (Any standard installation will take precedence, because we are adding the nonstandard directory at the end of the PATH -- add in front if you want the opposite behavior.)
In the general case, if there are other settings in your interactive .bashrc (or similar shell startup file) which needs to be set up in order for the script to work, the script needs to set this up one way or another. For troubleshooting, a quick and dirty fix is to add . /Users/you/.bashrc at the top of the script (where /Users/you should obviously be replaced with the real path to your home directory); but for proper operation, the script itself should contain the code it needs, and mustn't depend on an individual user's personal settings file (which could change without notice anyway).
Our Apache web server works in a Linux environment.
The cgi executables are called via a sh file (for example /cgi-bin/iwsblogin.sh).
The call "/cgi-bin/iwsblogin.sh" is in an html file.
Now I want to make a development and testing environment for this web server on windows.
I do not want to change the calls in the html files from "iwsblogin.sh" to "iwsblogin.bat" just for testing purposes.
Is there a way to configure windows in such a way, that files with the extension ".sh" are treated as executables the same way as ".bat" and ".exe" files?
The contents of this .sh file is for example:
- ms dos commands for setting some environment variables.
- Path of an exe file which should be called.
I know that there exist similar questions on stackoverflow where user suggest using cygwin, but this is NOT an option for me!
Thanks alot in advance
There are some ways to do this.
If the .sh file works when you rename it to .bat, you can use "run as" and select C:\Windows\System32\cmd.exe as default program
Use a sh emulator. For example, msysgit includes one or you can use cygwin (possibly the same source?).
I know you don't want to use cygwin, but why not? Please explain why this isn't an option. It is hard to look for an answer if we don't know why regular answers won't work.
I have created a batch file to run an application automatically but it seems my CMD does not run it. I typed this (using notepad as an example):
CMD /C "C:\notepad2\notepad2.exe"
If I run this from Windows Vista it worked. But running this from Windows Server 2008 (64-bit) it just doesn't work. I even try using that line from the Run menu but no go.
What do I do? My aim is to run a scheduled task that runs the batch file every now and then.
Stupid question, but does the program you're trying to run actually exist on the Server 2k8 machine?
There are no differences in cmd between Vista and Server 2k8 whatsoever.
Besides, why do you need to execute it via cmd? Can't you just run the application directly? Using cmd /c is only necessary for shell built-ins, such as dir or start.
Also remember that there is no NTVDM on 64-bit Windows—you can't run 16-bit programs. I doubt one would still use them nowadays but it may be the only thing I can think of why it doesn't work in 64-bit.