Executing a script in MSYS2/MinGW - windows

On Windows, if I start c:\msys64\mingw64.exe, it opens a shell, where I can build my project, let's say by calling a release bash script (to simplify). Everything works fine.
Now, I would like to execute my release script on mingw64 directly, without interaction.
I tried:
c:\msys64\mingw64.exe /c/the/full/path/release
A window opens and closes, it does not work.
I attempted to use bash directly, but it seems the environment is not correctly set:
> c:\msys64\usr\bin\bash -c ls
/usr/bin/bash: ls: command not found
> c:\msys64\usr\bin\bash -c /bin/ls
... it works ...
So it is obvious that the environment is not the same as when execute c:\msys64\mingw64.exe then call ls.
How to execute my release script as if I were in the shell started by mingw64.exe?

To run a Bash shell script in MSYS2 without showing a window, you should right-click on your Desktop or somewhere else in Windows Explorer, select "New", select "Shortcut", and then enter something like this for the shortcut target:
C:\msys64\usr\bin\mintty.exe -w hide /bin/env MSYSTEM=MINGW64 /bin/bash -l /c/Users/rom1v/project/release.sh
Note that there are 4 paths in here. The path to mintty and release.sh are absolute paths that you will need to adjust. The paths to env and bash are relative to your MSYS2 installation directory. Note also that the first path must be a standard Windows path, since Windows expects that when it is running a shortcut.
Explanation
It might seem odd to use MinTTY for a non-interactive script, but we need to use some program that was compiled for the Windows subsystem (-mwindows option to GCC), or else Windows will automatically start a new console when we run the program. We pass the -w hide option to MinTTY to tell it not to actually show a window. Everything after that option is interpreted by MinTTY as a command to run.
So MinTTY will run /bin/env from the MSYS2 distribution and pass the remainder of the arguments on to it. This is a handy utility that is actually a standard part of Linux as well as MSYS2. It sets the MSYSTEM environment variable to MINGW64 (which is important later) and then it runs /bin/bash with the remainder of the command-line arguments.
We pass -l to Bash so that it acts as a login script, and runs certain startup scripts. In particular, the /etc/profile script from MSYS2 is essential because it looks at the MSYSTEM environment variable, sees that it is MINGW64, and then sets a bunch of other environment variables (e.g. PATH) to give you the MinGW 64-bit shell environment.
Finally, we pass the name of your script as the main argument to bash, so it will run that script after running the initialization scripts.
Error handling
Note that if your Bash script has an error, you won't get any notification, because the shortcut above doesn't open any console windows. I personally would find that pretty annoying. I'd probably remove the -w hide option, then make a wrapper bash script that just does something like:
run_my_main_script || sleep 10000
So if the main script is successful, exit right away, otherwise keep the window open for 10000 seconds. You don't have to even put that wrapper script in its own file, you can just put it in the shortcut as the argument to Bash's -c option (don't forget to wrap it in double quotes).

Thanks to the answers from #David Grayson, I managed to call my release script with msys2/mingw from a Windows console (cmd), with additional directories (for Java and Meson) in $PATH:
c:\msys64\usr\bin\env MSYSTEM=MINGW64 c:\msys64\usr\bin\bash -l -c "PATH=\"/c/Program Files/Java/jdk1.8.X_XXX/bin:/c/Program Files/Meson:$PATH\" /c/Users/rom1v/project/release"

add an supplement to the above: if u want to the output of shell script
reference:https://mintty.github.io/mintty.1.html
-l, --log FILE|-
Copy all output into the specified log file, or standard output if a dash is given instead of a file name. (Implies -o Logging=yes.)
If FILE contains %d it will be substituted with the process ID. See description of equivalent option "Log file" (Log=) below for further formatting options and hints.
Note that logging can be toggled from the extended context menu.
Add A complete example:
C:\msys64\usr\bin\mintty.exe -w hide -l - c:\msys64\usr\bin\env MSYSTEM=MINGW64 c:\msys64\usr\bin\bash -l -c "PATH=\"$PATH\" /C/Users/Administrator/Desktop/myProject/Demo_C_C++/shell/textProcess/bookNoteHandler.sh" | find /v "/v:Displays all lines that don't contain the specified"
=========

Related

Executing MSYS2 Emacs from Windows command line or shortcut

I recently installed MSYS2 with Emacs (64-bit) and am currently calling that Emacs from a Windows shortcut. It works fine, exactly like if I had downloaded the Emacs executable for Windows and unzipped it somewhere. Which is to say, it picks up all of my Windows environment variables and such.
For various reasons, I would prefer to run Emacs from an MSYS2 bash shell and use the environment variables in that shell. As it stands, I can open an MSYS2 MINGW64 shell, type emacs on the command line, and everything works the way I want it to.
Now I would like to package the whole thing up into either a one-liner I can stuff into to a Windows shortcut or a script I can call from a Windows shortcut. With the help of this post, I came up with the following:
C:\msys64\bin\mintty.exe /bin/env MSYSTEM=MINGW64 /bin/bash -l -c /mingw64/bin/emacs
This successfully opens Emacs, but fails to load the .bashrc file that I source in .bash_profile in the usual manner:
if [ -f "${HOME}/.bashrc" ] ; then
source "${HOME}/.bashrc"
fi
I define a function in .bashrc that I call in .bash_profile, so this is kind of important. It did not take much effort to realize that the problem is that HOME is not defined, so .bashrc is simply not found. However, if I define HOME like so:
C:\msys64\bin\mintty.exe /bin/env HOME=/home/alanhr MSYSTEM=MINGW64 /bin/bash -l -c /mingw64/bin/emacs
I get exactly the same result: .bashrc is not found and my function is not executed. Here's where it gets weird. If I simply leave off the call to emacs like so:
C:\msys64\bin\mintty.exe /bin/env HOME=/home/alanhr MSYSTEM=MINGW64 /bin/bash -l
I get a bash shell where .bashrc has been loaded correctly and my function is correctly executed. I can type emacs on the command line and have it function exactly as I want it to.
This feels like a classic case of missing something that is right under my nose, but I have read the bash man page to no avail. Does anyone have any idea how I can make this work?
It is the -i option to load .bashrc. The following works for me:
C:\msys64\usr\bin\mintty.exe -w hide /bin/env MSYSTEM=MINGW64 /bin/bash -l -i -c /mingw64/bin/emacs

When program uses Command to open Bash to run a script, Bash closes immediately without running the script

I have a simple, already-working bash script set up to launch specific files with specific programs in the gaming frontend EmulationStation on Windows.
But the frontend routes its actions through a Command Prompt. And when Command is used to run the script through Bash, the Bash shell just opens and then closes immediately.
Here's an image of what shows for the instant before Bash closes.
This is only happening when going through a separate Command Prompt first, such as Windows Command Prompt or Git Command Prompt. Running the script with an appropriate argument directly through the git-bash shell works just fine.
In case you want to see the script for any reason, here it is:
#!/bin/bash
defaultemulaunch="V:/Emulation/.emulationstation/systems/retroarch/retroarch.exe -L "V:/Emulation/.emulationstation/systems/retroarch/cores/bsnes_mercury_accuracy_libretro.dll" \"$1\""
emu1names=(\
"(1999) Fire Emblem - Thracia 776.smc")
emu1launch="V:/Emulation/.emulationstation/systems/retroarch/retroarch.exe -L "V:/Emulation/.emulationstation/systems/retroarch/cores/snes9x_libretro.dll" \"$1\""
gamename=`basename "$1"`
for index in ${!emu1names[*]}
do
game=${emu1names[index]}
if [ "$game" == "$gamename" ]; then
eval "$emu1launch"
fi
done
eval "$defaultemulaunch"
But it's worth pointing out that this is happening when trying to run any bash script when starting the process from a separate Command Prompt.
Note: Git is installed on the hard drive that houses the emulation frontend (V:)---not in the user directory or programs directory of the system's OS/boot drive (C:). I mention this because git-bash's failure at an apparent "login" step except when launched directly feels like it could be a default filepath issue.
Check if that program would still open/close a Windows when executed from the CMD with:
bash -c '/v/path/to/bash/script'
In your case:
set PATH=V:\Emulation\
set GIT_HOME=V:\Emulation\Git
set PATH=%GIT_HOME%;%GIT_HOME%\bin;%GIT_HOME%\usr\bin;%GIT_HOME%\mingw64\bin;%PATH
Then:
cd V:/Emulation/.emulationstation/roms/snes/
bash -c './gamelaunch.sh "./(1990) F-Zero.sfc"'
I usually make a run.bat script which would:
set the correct PATH
launch the correct script
That way, for any of my project, I just type run.
And it runs.

msys2 no black window

My screenshot
How can I create a launcher for a program (or a script) on MSYS2 that does not show me the black window of the terminal?
My link:
msys2_shell.cmd -mingw64 -c /c/myfolder/program.exe
To run a program in the MSYS2 environment without showing a window, you should right-click on your Desktop or somewhere else in Windows Explorer, select "New", select "Shortcut", and then enter something like this for the shortcut target:
C:\msys64\usr\bin\mintty.exe -w hide /bin/env MSYSTEM=MINGW64 /bin/bash -lc /c/path/to/your_program.exe
Note that there are 4 paths in here. The path to mintty and your_program.exe are absolute paths that you will need to adjust. The paths to env and bash are relative to your MSYS2 installation directory. Note also that the first path must be a standard Windows path, since Windows expects that when it is running a shortcut.
Explanation
It might seem odd to use MinTTY for this, but the first program we launch needs to be some program that was compiled for the Windows subsystem (-mwindows option to GCC), or else Windows will automatically start a new console when we run the program. We pass the -w hide option to MinTTY to tell it not to actually show its own window. Everything after that option is interpreted by MinTTY as a command to run.
So MinTTY will run /bin/env from the MSYS2 distribution and pass the remainder of the arguments on to it. This is a handy utility that is actually a standard part of Linux as well as MSYS2. It sets the MSYSTEM environment variable to MINGW64 (which is important later) and then it runs /bin/bash with the remainder of the command-line arguments. The MSYSTEM variable selects which of the three MSYS2 environments to use, and the value values for it are MSYS2, MINGW32, or MINGW64.
We pass -l to Bash so that it acts as a login script, and runs certain startup scripts. In particular, the /etc/profile script from MSYS2 is essential because it looks at the MSYSTEM environment variable, sees that it is MINGW64, and then sets a bunch of other environment variables (e.g. PATH) to give you the MinGW 64-bit shell environment, or some different environment if you changed MSYSTEM.
Finally, we pass the name of your program as the main argument to bash, so it will run that program after running the initialization scripts.

Can I set an environment variable on Bash's command line?

I am trying to set an environment variable for Bash. However, I need this to be set before any of the shell's startup scripts (including /etc/profile), because /etc/profile acts differently based on the value of this variable.
Specifically, I want to create a shortcut to MinTTy that works like git-bash, but I need to set the MSYSTEM environment variable before the shell starts, or at least before it starts processing any startup scripts.
A solution that has MinTTy setting the environment variable before it starts the shell will also be accepted.
Edit:
What I am really looking for is sort of a command-line option to BASH that will set an environment variable, somewhat akin to the -D option to most C (and other) compilers. This would be a "general case" solution. Alternatively, a similar option (command line or configuration) to MinTTy will also do the job.
For my specific need, I have an idea for a potential work-around: Run a BASH script - with no startup scripts - that sets my required variable and execs another shell as a login shell.
Define the target of your shortcut file as follows:
C:\cygwin64\bin\mintty.exe /bin/bash -l -c "MSYSTEM=MINGW64 exec -l bash"
This command:
invokes bash directly as a login shell (-l)
passes it a command (-c) that defines the environment variable of interest (MSYSTEM=MINGW64) and then invokes a new copy of bash (exec -l bash), which inherits the existing environment, plus the new definition, but sources the profile(s) again, due to -l
(and prepends - to the executable name reported in $0 (-bash), as would happen if you started Mintty with just -, which is what the regular Cygwin64 Terminal shortcut does).
An alternative is to set the environment variable in Windows first.
[Not an option for the OP] If the environment variable should always have the same value, set it persistently as follows: run sysdm.cpl, go to the Advanced tab, click on Environment Variables... and define variable MSYSTEM as needed.
To define the variable ad-hoc, create a batch file as follows and make the shortcut target that batch file:
#echo off
# Define the env. variable with the desired value.
set "MSYSTEM=MINGW64"
# Invoke Mintty with a login shell, which will now see the env. variable.
# Adjust the path to mintty.exe as needed.
c:\cygwin64\bin\mintty.exe -
Note: Opening the batch file from a shortcut briefly opens a regular console window before opening Mintty, which may be undesired.
A simple helper WSH script, as demonstrated in this answer of mine, can prevent this.
You should just be able to do the same as you do in command prompt. Therefore, you can do:
set VAR=VarContents
Although I already accepted an answer above, I found this link that specifically addresses the second part of my question (Mintty specific) or an alternative way of setting an environment variable before running a command.
The contents of the Windows shortcut can be:
C:\cygwin64\bin\mintty.exe -t "Title" /bin/env "MSYSTEM=MINGW64" /bin/bash -l
(Suggested by Mintty Tips:Setting environment variables.)

Windows shortcut to run a Git Bash script

Assuming I have a test.sh script that runs a server and Git Bash installed, how do I create a Windows shortcut that I can double click to run tesh.sh in Git Bash in the foreground and allows me to see the output of the server?
Git bash is already a batch file with content similar to this :
C:\WINNT\system32\cmd.exe /c ""C:\Git\bin\sh.exe" --login -i"
If you want run (and leave running) a shell script in the context of the shell, specify it at the command line. The trick is that when the script file name is interpreted, it uses the Windows path, not the equivalent path in the sh/Git environment.
In other words, to run the file D:\temp\test.sh in the Git shell and leave it running, create this batch file :
C:\WINNT\system32\cmd.exe /c ""C:\Git\bin\sh.exe" --login -i -- D:\temp\test.sh"
On the other hand, if you want to run a script and get your shell back, you should :
Open the shell as is
Edit or create ~/.profile (try vi ~/.profile)
Add this line : ~/test.sh (ajdust the path if needed)
So with a .profile that looks like this :
echo Executing .profile
/bin/sh ~/test.sh
And test.sh that looks like this :
echo Hello, World!
You will get this prompt :
Welcome to Git (version 1.7.11-preview20120710)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
Executing .profile
Hello, World!
ixe013#PARALINT01 ~
$
Other answers work, but there is a shorter solution, that fully answers the question, which was:
How to create a Windows shortcut that I can double click to run
tesh.sh in Git Bash
The answer is: add the following command to the Target: field of the shortcut:
"C:\Git\bin\sh.exe" -l "D:\test.sh"
Where, -l is the short for --login.
To better understand what this command does, consult with official GNU docs about Invoking Bash:
-l (--login): Make this shell act as if it had been directly invoked by login. When the shell is interactive, this is equivalent
to starting a login shell with exec -l bash. When the shell is
not interactive, the login shell startup files will be executed.
exec bash -l or exec bash --login will replace the current
shell with a Bash login shell.
Also note that:
You either need the full path to sh.exe or have it in your PATH environment variable (as others have already pointed out).
If you really need to force shell invocation in interactive mode, you can add the -i option
The last parameter is the path to the script that has to be executed. This path should be in Windows format.
Best solution in my opinion:
Invokes the right shell
No unnecessary windows
Invokes a bash script afterwards
Window will stay open after the script exits
Do the following:
Create a shortcut to mintty.exe on your desktop, for example. It is found under %installation dir%/Git/usr/bin/mintty.exe
Edit properties of the shortcut and change the target (keep the path):
"C:\Program Files\Git\usr\bin\mintty.exe" -h always /bin/bash -l -e 'D:\folder\script.sh'
Explanation of the parameters:
-h always keeps the window open when the script finished, so the window won’t disappear while you are still reading the output (remove if you don’t need to read the output and want the window to close automatically).
-l makes this shell act as if it had been directly invoked by login.
-e exits immediately if a pipeline returns a non-zero status (more info).
I'd recommend to use environment variable %ComSpec%, instead of absolute path to cmd:
%ComSpec% /c ""C:\Program Files (x86)\Git\bin\sh.exe" --login -i"
or even just cmd command, which is usually available from %PATH%:
cmd /c ""C:\Program Files (x86)\Git\bin\sh.exe" --login -i"
if your C:\Program Files (x86)\Git\bin added to PATH (which is also common solution and one of cases on TortoiseGit installing) you can use just:
cmd /c "sh --login -i"

Resources