So I'm trying to make an automated bash script to help build certain versions of the Minecraft Spigot server. In order to "build" the server, you have to decompile the .jar file by running the following commands in the terminal.
export MAVEN_OPTS="-Xmx2G"
export JAVA_HOME="/usr/libexec/java_home -v 1.8" (Omit this line unless you are building a previous version then the current 1.13 build, which uses Java 11 and not Java 8)
java -jar BuildTools.jar (Optional: --rev flag can be used to dictate what version you would like to download of the server)
Now this is what I have come up with so far to make a simple "double click and done" bash script. I'm extremely new to running, compiling, writing, etc of bash scripts. The error I'm getting is something along the lines of "Can't find BuildTools.jar", however this is blocked by a pop up from my terminal that I can't get rid of and still see the message. Once I click ok, it just closes the window.
#!/bin/sh
cd "$( dirname "$0" )"
export MAVEN_OPTS="-Xmx2G"
export JAVA_HOME="/usr/libexec/java_home -v 1.8"
exec java -jar BuildTools.jar --rev 1.8.8
My main objective is to just be able to edit the script manually and dictate what version I would like to download by changing the --rev flag, and deleting the "java version" line if not using the current 1.13 build.
Ideally I would like the script once run, to ask me what version I would like to use. If i hit enter it omits the --rev flag & java version line, and downloads the current version (1.13), if I specify a version (i.e. "1.9") it runs the export JAVA_HOME="/usr/libexec/java_home -v 1.8" line and adds the --rev flag to the end of the exec line.
If this doesn't make any sense, here is the article explaining how to do what I'm doing through the terminal with no "automated script".
https://www.spigotmc.org/wiki/buildtools/
I would like to get this script to work as I would forward this script along to other server developers that would be able to use the script in their every day development and not have to run multiple commands through the terminal every time they want to build a server.
The easiest way to do something like this is to take a single optional argument:
java -jar BuildTools.jar --rev "${1-1.8.8}"
This may look a bit clunky, but it means the script can be called like my_script.sh to use the default version or my_script.sh 2.0 to use version 2.0.
Another simple improvement would be to pull out a variable for the default version:
default_version='1.8.8'
java -jar BuildTools.jar --rev "${1-$default_version}"
Your shebang line uses /bin/sh, which is not the same as Bash. This may make your script very slightly more portable than using Bash, but Bash is by now very common, and you can take advantage of Bash features in your script. For example:
You can declare the default version variable constant with readonly default_version.
You can get the script path more reliably.
Related
I am trying to run sdkman on a shell script that I call run.sh. This is what the inside of the shell script looks like:
sdk use java 8.0.302-open
When I run the command in a terminal, it works. But when I run it in a shell script, I get this error:
run.sh: 1: sdk: not found
Anyone knows how to fix this?
I fixed it for me; Although this may not work for others.
I placed #!/bin/bash at the top of the shell script, and then added this after it:
source "$HOME/.sdkman/bin/sdkman-init.sh"
Then my shell script was able to be ran using:
./run.sh
sdkman was able to work this time.
I am running an externally supplied perl script (the OpenSSL configure script if you are interested). It contains the line:
my $vew=`nasmw -v 2>NUL`;
I am running on Windows, but I am using the version of perl which ships with git version 2.19.0.windows.1, and this appears to by a Cygwin perl which uses sh to execute backticks. The problem is that this creates a file called 'NUL' rather than throwing stderr away. Amongst other things you can't delete such a file from Explorer or the command line. (You can via bash).
I have read this question but setting PERL5SHELL to C:\Windows\System32\cmd.exe /C doesn't stop the file being created.
Is there a way of controlling the shell that a Cygwin perl uses?
Perl -v reports version 5.26.2
(The obvious workround is to patch NUL to /dev/null but I'd rather not do that if I can avoid it.)
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"
=========
I'm trying to run gitk on Windows but the console gives me:
'gitk' is not recognized as an internal or external command,
operable program or batch file.
But then, I can do
> where gitk
C:\Program Files (x86)\Git\bin\gitk
How comes?
UPDATE: Stealing the OP's comment:
Thanks for a (lengthy) explanation, the easiest fix for me was to move from the old msysGit (1.9.5) version to the newer "Git for Windows" builds which has a proper Windows wrapper for gitk.
gitk, unlike most git commands, is a shell script that invokes Tcl.
If you examine the gitk executable file itself, its first few lines are:
#!/bin/sh
# Tcl ignores the next line -*- tcl -*- \
exec wish "$0" -- "$#"
(At least that's what it looks like on my Linux system; the Windows installer for gitk might change that.)
On a Unix-like system, that first line, known as a "shebang", tells the system to invoke /bin/sh to execute the file rather than executing it directly.
The third line executes the wish command, which executes the script as a Tcl script.
If you have Tcl installed on your Windows system, you should be able to run gitk as a Tcl script using something like this:
C:\> tclsh "C:\Program Files (x86)\Git\bin\gitk"
(Disclaimer: I have not tried this.)
You might also be able to change the command's name from gitk to gitk.tcl and set up a file association in Windows so it will be invoked correctly. (I'm a little surprised that the Windows git installer didn't do this for you.)
More information on running Tcl scripts on Windows can be found here.
And this question discusses invoking gitk on Windows from the context menu rather than from the command line.
I tried activating a VirtualEnv through a shell script like the one below but it doesn't seem to work,
#!/bin/sh
source ~/.virtualenvs/pinax-env/bin/activate
I get the following error
$ sh virtualenv_activate.sh
virtualenv_activate.sh: 2: source: not found
but if I enter the same command on terminal it seems to work
$ source ~/.virtualenvs/pinax-env/bin/activate
(pinax-env)gautam#Aspirebuntu:$
So I changed the shell script to
#!/bin/bash
source ~/.virtualenvs/pinax-env/bin/activate
as suggested and used
$ bash virtualenv_activate.sh
gautam#Aspirebuntu:$
to run the script .
That doesn't throw an error but neither does that activate the virtual env
So any suggestion on how to solve this problem ?
PS : I am using Ubuntu 11.04
TLDR
Must run the .sh script with source instead of the script solely
source your-script.sh
and not
your-script.sh
Details
sh is not the same as bash (although some systems simply link sh to bash, so running sh actually runs bash). You can think of sh as a watered down version of bash. One thing that bash has that sh does not is the "source" command. This is why you're getting that error... source runs fine in your bash shell. But when you start your script using sh, you run the script in an shell in a subprocess. Since that script is running in sh, "source" is not found.
The solution is to run the script in bash instead. Change the first line to...
#!/bin/bash
Then run with...
./virtualenv_activate.sh
...or...
/bin/bash virtualenv_activate.sh
Edit:
If you want the activation of the virtualenv to change the shell that you call the script from, you need to use the "source" or "dot operator". This ensures that the script is run in the current shell (and therefore changes the current environment)...
source virtualenv_activate.sh
...or...
. virtualenv_activate.sh
As a side note, this is why virtualenv always says you need to use "source" to run it's activate script.
source is an builtin shell command in bash, and is not available in sh. If i remember correctly then virtual env does a lot of path and environment variables manipulation. Even running it as bash virtualenv_blah.sh wont work since this will simply create the environment inside the sub-shell.
Try . virtualenv_activate.sh or source virtualenv_activate.sh this basically gets the script to run in your current environment and all the environment variables modified by virtualenv's activate will be available.
HTH.
Edit: Here is a link that might help - http://ss64.com/bash/period.html
On Mac OS X your proposals seems not working.
I have done it this way. I'am not very happy with solution, but share it anyway here and hope, that maybe somebody will suggest the better one:
In activate.sh I have
echo 'source /Users/andi/.virtualenvs/data_science/bin/activate'
I give execution permissions by: chmod +x activate.sh
And I execute this way:
`./activate.sh`
Notice that there are paranthesis in form of ASCII code 96 = ` ( Grave accent )
For me best way work as below.
Create start-my-py-software.sh and pest below code
#!/bin/bash
source "/home/snippetbucket.com/source/AIML-Server-CloudPlatform/bin/activate"
python --version
python /home/snippetbucket.com/source/AIML-Server-CloudPlatform/main.py
Give file permission to run like below.
chmod +x start-my-py-software.sh
Now run like below
.start-my-py-software.sh
and that's it, start my python based server or any other code.
ubuntu #18.0
In my case, Ubuntu 16.04, the methods above didn't worked well or it needs much works.
I just made a link of 'activate' script file and copy it to home folder(or $PATH accessible folder) and renamed it simple one like 'actai'.
Then in a terminal, just call 'source actai'. It worked!