I created Shell Script on Linux and it runs fine.
Now I want to run the same script on Windows using gitbash. (Only filepath changed for windows)
I am confused:
do I need to write a new shell script again according to Windows syntax shell script?
or
can a Linux syntax shell script run on Windows without changes?
According TO differences-between-windows-batch-and-linux-bash-shell-script-syntax
Of course you can. There is a tool called cygwin that allows you to do so.
Note that you have to check what the paths are. If so, go to the path you are willing to work on and do pwd. This way, you will get the Windows\kind\of\path.
I use it all the time and it works pretty fine.
You can use Git Bash
It depends on how advanced the scripts are, but simple scripts can be executed in Git Bash.
test.sh contains:
#!/bin/bash
echo Hello World!
Execute script:
./test.sh
Output:
Hello World!
Git Bash vs Cygwin
To answer your question:
#fedorqui in my learning 'cygwin' And 'gitbash' do same stuff for
windows
Git Bash
Git Bash is lightweight and only aims to handle:
version control
a shell that runs commands
Read more: http://openhatch.org/missions/windows-setup/install-git-bash
Cygwin
a large collection of GNU and Open Source tools which provide
functionality similar to a Linux distribution on Windows.
a DLL (cygwin1.dll) which provides substantial POSIX API
functionality.
Read more: https://www.cygwin.com/
Related
I have been working on a node script that does the installation of external dependencies and was wondering if its possible to set the PATH variable using Node.
For example, If I want to install Go using script, I can execute command brew install Go and this works but when I do export GOPATH=$PATH, this is never set.
I also tried using process.env but this also does not work. Also my assumption with process is that it must run in a sandbox. So it will not update/ set anything outside.
So the question is, can I do this? If yes, how?
It is not possible in any programming language. At least on Unix (BSD, MacOS, Illumos etc.) and Linux, I'm not sure about Windows.
As a security feature, Unix processes are designed such that they cannot touch the environment of their parent's process. Only the parent process can influence the environment of their children.
When you are on a command line you are running a shell program (either Bash or Korn Shell or TCSH or Fish etc.). When you execute something on the command line such as a node.js script or Google Chrome or Minecraft these programs will be the children to your shell program. On Unix and Linux these child programs inherit their parent's environment.
That is why you can export environment (global) variables and your programs can access them. However, this relationship is one-way and it was designed that way on purpose.
You may notice that in shell scripts you can "save" commands to set environment variables in a file. For example in Bash you sometimes see people do this:
# variables.sh
export HELLO "World"
However, this will not work if you execute the script as a script:
$ bash variables.sh
$ echo $HELLO
<--------------------- nothing is displayed here
the variable is not exported
You sometimes see people do this instead:
$ . variables.sh
$ echo $HELLO
World
And you may wonder how that works. Well.. in some shell languages the dot command imports the script instead of executing the script as a separate process. Think of it like import or require() in javascript.
Of course, Bash does not understand javascript syntax. It also does not understand C++ or Java or Ruby or PHP. It only understands Bash syntax.
So the longer answer is it is not possible in any programming language except for the language of the shell you are using (eg. if you are using Fish you need to write a script in Fish syntax or if you are using Ksh you need to write a script in Korn syntax).
Yesterday I ran into the git execute bit bash script quirk - the one that requires:
git update-index --add --chmod=+x scriptname.sh
and it seemed strange to me that it was even possible to get stuck in this situation. (Ie having created a script file that you don't have permission to run).
If I have created a shell script - surely I can run it under the permissions of the shell execute permissions. Why would it need it's own execute permission bit?
My question is: Why does a bash script require an execute bit if a windows batch script can just be executed?
To run a script you have two options in unix like systems. First Option is to use a direct interpreter call with the script as parameter.
# run a bash script
bash test.sh
# run a python scripts
python test.py
The second option is mark your file as executable, with the execute bit and after a call like this ...
# sample bash
./test.sh
# sample python
./test.py
... your system tries to find the right interpreter for you. For this the first line 'shebang' of the script is used.
Bash example:
#!/bin/bash
# points to the installed bash interpreter - bash example
Python example:
#!/usr/bin/python
# points to the installed python interpreter
To your question windows only use the file extension to detect a executable file.
Well, Linux is not Windows. Linux/Unix file systems support the executable bit to distinguish executable from pure data files, and to control exec permissions for user|group|others. You can still run the script if you prefix it with the name of the shell/binary you want to start it with, but if you want to do ./scriptname.sh or execute it from the path it needs to be flagged as executable for you as the onwer|a group member|some other user, and for scripts usually the shebang in the first line that defines the interpreter to start the script with: #!/bin/bash.
When I try to run a Perl script which is called via Linux script manually it works fine but not executable via CRON.
Linux_scrip.sh conatains Perl_script and the command is,
perl_path/perl Perl_script.pl
I got perl_path using which perl command.
Can anyone suggest why is it not executable via CRON entry.
Most likely suspects:
Current work directory isn't as expected.
Permission issues[1].
Environment variables aren't setup as expected.
Requirement of a terminal can't be met.
See the crontab tag wiki for more pitfalls and some debugging tips.
The first thing you should do is to read the error message.
This isn't likely to be an issue for you own cron job, but I've included it since it's quite a common problem for scripts run from other services.
Most probable cause is current working directory.
Before perl command execution, write a command to change directory.
Something like :
cd perl_path;
perl Perl_script.pl
I have a shell script make with Linux with this code:
#!/bin/sh
awk '{ print $3,$2,$4,$1}' df_real_credit_network_B0.00_BC0.00_l33.33_day1 > credit_adj
awk '{ print $3,$2,$5,$1}' df_real_interbank_network_B0.00_BC0.00_l33.33_day1 > interbank_adj
The script creates two objects: "credit_adj" and "interbank_adj", necessary for others scripts for the software R. Obliviously Windows don't recognize the script, so I try to modify the extension ".sh" with ".bat" and I deleted the string "#!/bin/sh" from the script.
In this way the two objects are created but are empty, because windows don't recognize the instruction awk.
How can I create the two objects correctly?
Thanks
You cannot directly run a Unix shell script in windows, One way to run unix/Linux shell script in windows is , install cygwin in windows and run script inside cygwin
Sorry, the headline might be a bit irritating, but I didn't know anything better. Anyway, I want a bash script to work on FreeBSD, OpenBSD and Linux without modifying it, but bash isn't located at the same place in Linux and BSD.
So, if I write #!/bin/bash then it won't work on BSD, because the bash shell is located in /usr/local/bin/bash there. Is there any solution to get this script working on both?
Or do I really need to ship two scripts with different paths...?
Using env in the shebang (#!/usr/bin/env bash) should make the script OS agnostic.
I like the answer about using #!/usr/bin/env bash
It is an interesting and excellent answer, but that would only work if bash is in the path.
Another option might be to use #!/bin/sh which is the most universally compatible shell location.
Then, have the script do something in sh, such as check where bash is installed (if bash is even installed). Another option might be to have bash exist to both locations. Making another installation may sound like overkill, but this goal could be accomplished as simply as creating a hard link so that bash actually exists in both locations.