I have got a Hudson Slave on a windows machine and need to execute some shell commands on it. I have put all the commands in the execute shell portion of the project and the first line reads as this:
#!C:\msysgit\msysgit\bin\sh.exe
However when running the project I am getting errors saying command not found. Specifically for git, cd, make, rm and I would presume more. I feel like this is a simple thing to fix but can't figure it out. The script works fine when using msysGit on the machine but I am having trouble doing it through Hudson. Any help would be appreciated. I need to be using msysGit not Cygwin.
You could start by making that script displays:
the username
the path
the $HOME (important for ssh operation, and not always set correctly on Windows)
And see what those variables reference in the context of an Hudson job.
They might not reflect/inherit the values of your current session.
And it can depend on how you did install msysgit.
The OP Zack Lalanne mentions in the comment he just need to have:
#!C:\msysgit\bin\sh.exe --login -i
which means the bash session will inherit his environment variables, making the job much likely to run than without the user's environment.
Related
I just realized that i cannot execute .sh scripts anymore on my debian.
It used to work fine. All .sh files are +x chmodded and used to work fine.
Suddenly, once i execute: ./test.sh system hangs.
I am able to stop this via ctrl+c, but script never executes.
Steps did so far was to restart my VPS.
Any ideas?
I am pretty sure shell scripts are still working on your machine, because if they weren't, you would not be able to complete any boot cycle.
If I suppose you are facing problems with your homemade scripts, then you should probably check your shebang line (#!/bin/sh for example) to see if anything unusual was used there.
New scripts are using a dispatcher to interpreters:
`#!/usr/bin/env bash` #lends you some flexibility on different systems
`#!/usr/bin/bash` #gives you explicit control on a given system of what executable is called
The difference between “#! /usr/bin/env bash” and “#! /usr/bin/bash”?
I have a Perl program on server_B which uses Perl DBI and 5.010 and runs fine from the server_B terminal. I run it from a shell script which first prepares some arguments and then passes them to the Perl program, all works fine.
I need to run a shell script on server_A that will execute that script on server_B. This is because the Perl program creates several files that I want to SFTP back over to server_A. This is the script I'm running on server_A:
ssh server_B <<- EOF
perl/update.sh
EOF
There is some strange behavior which I'm trying to understand:
The script (update.sh) on server_B runs mysql, which is not installed on server_A (which is why I have to do this whole thing.) If I try to run it on server_B as-is, I can call mysql just like that. But when I run the above script (on server_A) to ssh into server_B and run that script, it doesn't recognize mysql unless I change the file (on server_B) to call the full path /opt/mysql/client/bin/mysql (even though that file is already on server_B with mysql installed) Does this mean server_B is picking up on the PATH variable from server_A instead of using my PATH variable from server_B? Is it trying to run my programs from server_A on the files on server_B? How and why??
If I make the change above it executes the script, but when it hits Perl it says
Perl v5.10.0- required - this is only v5.8.8
Again, 5.10 works fine on server_B but the version of Perl on server_A is 5.8.8.
So I got rid of use 5.010; because it actually wasn't necessary, but then I have a similar problem with my modules (DBI and DBD::mysql). I get:
Can't locate DBI.pm in #INC (#INC contains.. [my Perl PATH from server_A])
at perlfile.pl line 4
I was expecting the ssh heredoc call to update.sh (from server_A) to run exactly as update.sh does if I call it on server_B, but instead it seems like it's trying to use my programs from server_A on server_B, which I find weird. Can anyone help me understand why it's happening? I feel like I'm misunderstanding something fundamental about how ssh works.
server_A is AIX with ksh
server_B is AIX with bash
Edit - since some of you voted to the effect that I haven't done my research, here's what else I've tried. I didn't mention because I don't understand them fully, these are just guesses based on other SO posts & hunches. It'd be disingenuous if I gave the impression I knew what I was talking about.
If this is a duplicate, which question should I be looking at? If this is a "just read the manual situation", which one? What should I look for?
Read man ssh looking for clues related to environment variables, didn't find anything I understood
Tried running with -t
Tried running with -t -t
Did log in remotely with ssh and manually running it - this DOES work
Sourced my .bash_profile in the update script
Tried to re-assign PATH as the remote server's PATH when ssh
Tried using a different delimiter for the heredoc
Tried < instead of <<
Tried without the "-"
Edit 2 with Saigo's help below I determined that when in interactive ssh, if I echo $PATH I do get the target server's $PATH, but in a shell script I don't. That led me to this:
https://serverfault.com/questions/643333/different-bash-path-variables-when-using-ssh-script-vs-interactive-ssh
where I found out that scripted ssh doesn't call .bashrc, but interactive ssh does. So it looks like I was on the right track trying to source .bash_profile inside the scripted SSH heredoc, just need .bashrc not .bash_profile - however I don't have a .bashrc on the target server. I do have .profile but when I source that, I get an error stating it's for interactive bash sessions only. So now I'm just trying to find whatever file would contain my $PATH variable because it's apparently not .bashrc as there isn't one in there.
Edit 3 - tried hard-coding the PATH variable into a file and sourcing that and even then when I echo $PATH I get the origin server's PATH variable. It is reading the file in correctly, I also assigned another test variable and echoed that as part of the script. I tried sourcing /etc/profile and no luck.
I found a solution that works perfectly. I wasn't able to get it to work with ~/.bashrc, ~/.bash_profile, or ~/.ssh/rc but still not sure why it's not picking up my environment variables even with sourcing these.
Since it works when I manually ssh in and then run the commands one-by-one, I used these arguments to run ssh in a forced interactive login.
ssh server_B bash --login -i "~/perl/update.sh"
See these for more:
https://superuser.com/questions/564926/profile-is-not-loaded-when-using-ssh-ubuntu
https://unix.stackexchange.com/questions/46143/why-bash-unable-to-find-command-even-if-path-is-specified-properly
Hope this is useful for someone in the future. Thank you for your assistance Saigo.
i've installed DAMP on Windows Vista, and have created a profile in my drupal folder with a shell script that needs to run.
profiles/donor_rally/rebuild.sh
However, I don't know how to execute this shell script.
I am not familiar with shell script command language, would you be willing to provide me with a step-by-step instructions on how to execute this shell script?
Thanks.
It looks like you're trying to run a Bourne shell script, which would usually only run on a unix machine. Guessing from the name, this is supposed to rebuild something, likely the database, but that's just a guess.
The short answer is you can't run it, at least not easily. If you were to post the (edited) contents of the script you might get some answers about how you could port it to a Windows cscript or batch file.
For others who are uninitiated to shell scripting in Windows:
I did not find a straightforward solution for running shell scripts on AMP hosted on Windows.
Instead I got an account at webenabled.com
Then used PuTTy to tunnel in.
I found this guide to using UNIX: http://freeengineer.org/learnUNIXin10minutes.html
And lynda.com
I am using a bash script to run a number of application (some repeatedly) on a Windows machine through cygwin. The script contains commands to launch those applications, line by line. Most of these applications run for many minutes and many times I have observed that the i+1 th application is not being started even after i th application is completed. In such cases, if I press enter in the cygwin console on which the bash script is running, the next application starts running. Is it because of any issue with bash on cygwin? Or is it an issue with the Windows OS itself? Have any of you observed such an issue with bash + cygwin + Windows?
Thanks.
I think I have seen this before.
Instead of
somecommand
try
somecommand </dev/null
If that doesn't work, try
cmd /c somecommand
Or experiment with other redirections, e.g.
somecommand >/dev/null
Sounds like you may have a problem with your shell script encoding; DOS (and Windows) uses CR+LF line endings, whereas Linux uses LF endings. Try saving the file as LF.
What might also be going on:
When I was running Cygwin on a school laptop, I encountered a dramatic slowing of shell scripts vs. when they were running in a native Linux environment. This was especially apparent when running a configure script from GNU Autotools.
Check your path for slow drives. (From the Cygwin FAQ):
Why is Cygwin suddenly so slow?
If suddenly every command takes a very long time, then something is probably attempting to access a network share. You may have the obsolete //c notation in your PATH or startup files. Using //c means to contact the network server c, which will slow things down tremendously if it does not exist.
You might also want to check whether you have an antivirus program running. Antivirus programs tend to scan every single executable file as it is executed; this can cause problems for even simple shell scripts that run hundreds or even thousands of individual programs before they run their course.
This mailing list post outlines what is needed to pseudo-mount the main /usr/bin directory as cygexec. I'm not sure what that does, but I found it helped.
If you're running a configure script, try the -C option.
Hope this helps!
Occasionally, I'll get this behaviour because I have accidentally deleted the 'she-bang' at the top of the script, that is, deleted the #!/bin/bash on the first line of the script.
It's even more likely for this to happen when a parent shell script calls a child script that has the she-bang missing!
Hope this helps.
A bit of a long shot, but I have seen some similar behaviour previously.
In Windows 2000, if any program running in a command prompt window had some of it's text highlighted by the cursor, it would pause the command running, and you had to press enter or clear the highlighting to get the command prompt to continue executing.
As I said, bit of a long shot, but accidental mouse clicks could be your issue...
Install cygwin with unix style line breaks and forget weird problems like that.
Try saving your script as "the-properly-line-broken-style" for your cygwin. That is, use the style you specified under installation.
Here is some relevant information:
https://stackoverflow.com/a/7048200/657703
Im trying to automatically run a script using Cygwin via CMD. I basically created a BAT file that goes to the directory and executes an .SH file. SH files are accosiated with Cygwin, and I tried something like "cygwin update.sh" in the command line. But all it really does is open Cygwin. I want Cygwin to automatically run the script file. Is there any easy way to do this, I've been trying to find but can't. Thank you!
You'll want to call the shell script with a particular shell, e.g. bash.
When having Cygwin open, call which bash to figure out where the binary is located. Cygwin also comes with tools that can convert paths between Cygwin and Win32 form, which is pretty helpful in cases like yours.
There is one other thing that may work, depending on your setup. There is an environment variable named PATHEXT which declares file extensions that are deemed "executable" by CMD. This can be used to your advantage, if Windows is configured so that the shell's "open" verb executes the correct shell for the file extension .sh (in your case).
Good luck.
From Cygwin Terminal, read man mintty. Try something like the following from a Windows Command Prompt:
c:\cygwin\bin\mintty --hold always --exec /cygdrive/c/path/to/bash/script.sh
I also found this!
http://rothmanshore.com/2011/01/26/kick-off-a-cygwin-script-from-a-windows-bat-file-with-a-different-working-directory/
I didn't quite understand it at first, but then it worked as I wanted it. Just if anyone knows, is there a way to make the script run without the CMD window open?? Thanks