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.)
Related
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.
First of all am new to MAC.
Am facing similar kind of issue on Mac where its shipped with V5.28.0 but i have to use perl V5.18.2 for my application. Have installed perl 5.18.2 using perlbrew install 5.18.2 and the installation was successful.
Have two questions here
Where are my default version and other version installed ? Is there any command to know them ? Have already tried checking echo $PATH but no use.
How to set the default version to 5.18.2 ?
Regards
AVK
The default installation location is
/usr/bin/perl
But that might not be where it's located on MacOS. You can find out for sure by running the following:
perlbrew off
which perl
(Restarting the terminal will reactivate perlbrew.)
The build you installed is in a directory under the directory returned by the following:
printf -- "%s\n" "${PERLBREW_ROOT:-$HOME/perl5/perlbrew}/perls"
You can modify the PATH so that perl runs the desired build using
perlbrew switch <name> # Changes it for this shell instance and those created later.
perlbrew use <name> # Changes it for this shell instance only.
You can get the names to use from
perlbrew list
See Switching to the system Perl using perlbrew for switching to the system Perl.
Scripts need to have the correct perl specified on their shebang (#!) line. Scripts installed by the standard Perl module installers will have this set correctly, but you'll need to edit the shebang (#!) line of scripts you've installed manually.
Another option (incompatible with perlbrew) is to use plenv. This lets you run different versions of perl for each directory. After installing with brew install plenv, you'd use it like so:
$ plenv install 5.18.2
$ cd project/needing/old/perl
$ echo "5.18.2" > .perl-version
Poof! Running perl in that directory or any of its subdirectories will use 5.18.2.
Note: if you run a perl script with ./script.pl, which has #!/usr/bin/perl, this should continue to use the perl installed at /usr/bin/perl. However, if the shebang line is /usr/bin/env perl, this should switch to the version specified by the .perl-version file.
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 rarely touch shell scripts, we have another department who write them, so I have an understanding of writing them but no experience. However they all appear rather useless with my issue.
I am trying to execute some KornShell (ksh) scripts on a windows based machine using Cygwin- we use these to launch our Oracle WebLogic servers, now it simply will not execute. I used to be able to execute these exact same scripts fine on my old machine.
Now I have narrowed this down to the fact the 'magic number' or whatever it is at the start of the script where it specifies the script interpreter path:
i.e.:
#!/bin/ksh
if I change it to execute as a simple bash it works i.e:
#!/bin/sh
I went through checking the packages installed for cygwin - now the shells I installed are:
mksh MirdBSD KornShell
bash the bourne again shell
zsh z shell
Should I expect to see a ksh.exe in my cygwin/bin directory? there is a system file 'ksh' which I was making an assume somehow associates it with one of the other shell exes, like mksh.exe
I understand my explanation may well be naff. But that being said, any help would be very much appreciated.
Thanks.
I believe the MirBSD korn shell is called mksh. You can verify this and look for the correct path by typing
% which mksh
% which ksh
or if you have no which,
% type -p mksh
% type -p ksh
or if that fails too, check /etc/shells which should list all valid shells on a system:
% grep ksh /etc/shells
You need to put the full path after the #! line. It will probably be /bin/mksh, so your line needs to look like:
#!/bin/mksh
You've probably fixed it by now, but the answer was no, your Cygwin does not (yet) know about ksh.
I solved this problem by launching the cygwin setup in command-line mode with the -P ksh attribute (as described in http://www.ehow.com/how_8611406_install-ksh-cygwin.html).
You can run a ksh using a bat file
C:\cygwin\bin\dos2unix kshfilename.ksh
C:\cygwin\bin\bash kshfilename.ksh
Running a shell script through Cygwin on Windows
Install KornShell (ksh) into Cygwin by the following process:
Download: ksh.2012-08-06.cygwin.i386.gz
Install ksh via Cygwin setup.
Execture Cygwin setup.exe
Choose: Install from Local Directory
Select the ksh.2012-08-06.cygwin.i386.gz as the Local Package Directory.
Complete Cygwin setup.
Restart Cygwin.