How to check if scp command is available? - scp

I am looking for a multiplatform solution that would allow me to check if scp command is available.
The problem is that scp does not have a --version command line and when called without parameters it will return with exit code 1 (error).
Update: in case it wasn't clear, by multiplatform I mean a solution that will work on Windows, OS X and Linux without requiring me to install anything.

Use the command which scp. It lets you know whether the command is available and it's path as well. If scp is not available, nothing is returned.

#!/bin/sh
scp_path=`which scp || echo NOT_FOUND`
if test $scp_path != "NOT_FOUND"; then
if test -x ${scp_path}; then
echo "$scp_path is usable"
exit 0
fi
fi
echo "No usable scp found"
sh does not have a built-in which, thus we rely on a system provided which command. I'm not entirely sure if the -x check is needed - on my system which actually verifies if the found file is executable by the user, but this may not be portable. On the rare case where the system has no which command, one can write a which function here.

Related

Intellij Idea - ignoring non-zero exit code of external tool

I'm using external tool to run fuser -k 1099 command before actually launching my run configuration
But if external tool returns non-zero status, build configuration stops. That is perfectly correct, but I can not find any way to ignore failure. If it was a plain bash, I'd do something like fuser -k 1099 || true. But at Idea, that seems to be not possible
Any ideas?
You can use /bin/bash as the program and the following as the arguments:
-c 'fuser -k 1099'; true
This way the exit code of the tool will be always zero.
Correct answer was not working for me (see my comment under it) I then found a solution that is to create a script that exits with 0, here under windows (let us call it KillMyExeNoError.bat):
taskkill /IM my.exe /F
exit /B 0
Then put C:\Path\To\KillMyExeNoError.bat in Program and leave Arguments empty.
Maybe under Linux you need to put bash in Program and /path/to/script.sh in Arguments.
Not the best solution since it would be good not to have to create a separate script but at least it works.

scp command - transfer folder over ssh

I have a Arduino Yun and want setup the server for Yun.
So what I want is to copy a folder that contain a py file and a index.html to my Yun
I used mac terminal to do this operation
the command looks like this
scp -r /Users/gudi/Desktop/LobsterHeartRate root#192.168.240.1:/mnt/sda1
and then terminal asked for the password
after I typed, it shows
scp: /mnt/sda1/LobsterHeartRate: Not a directory
I didn't type /mnt/sda1/LobsterHeartRate why it shows this error
Your code
scp -r /Users/gudi/Desktop/LobsterHeartRate root#192.168.240.1:/mnt/sda1
requires that the remote directory /mnt/sda1 exists. This looks like it is not true in your case. Check it using ssh root#192.168.240.1 ls /mnt/sda1.
scp is simple tool and it does not allow you to rename directories on the fly and the target directory must exists. You might try
scp -r /Users/gudi/Desktop/LobsterHeartRate root#192.168.240.1:/mnt/
ssh root#192.168.240.1 mv /mnt/LobsterHeartRate /mnt/sda1
or so, if it will suit your needs. But copying more files, rsync is usually more suitable. Check its manual page and give it a try next time.
As #Jens Höpken notes, your post is a bit sparse. But trying to read between the lines of your post I suspect that LobsterHeartRate is a DIRECTORY on your local system but a FILE named LobsterHeartRate in your target system. This might be happening right at the top of the directory tree, or perhaps you have directories/files of the same name further down the tree. scp -rv might help resolve any confusions here.
Beware: scp -r resolves symbolic links. If you want to preserve symlinks you need to do something else. For historic reasons I use the following, though cpio with a find front-end opens up interesting possibilities for fine-grained file selections.
( cd /Users/gudi/Desktop && tar -cf - LobsterHeartRate ) |
ssh root#192.168.240.1 'cd /mnt/sda1 && tar -xf -'
For a safe "dry run" you could change the -xf to a -tf. The && chains are required to prevent bad things from happening if any prior command fails.
Disclaimer: any debugging is left as an exercise for the student.

how to set up the psql command in cygwin?

I have a local dev site on my machine with Apache server and PostgreSQL 9.1 database. As I'm using Windows, I also installed Cygwin. I want to access to database and make some queries via Cygwin insead of pgAdmin III, but it tells me that psql command not found. How should I set up the psql command in cygwin?
As of today, you just have to install postgresql-client package in cygwin:
Run your cygwin setup.exe file (this can be run multiple times to
add more packages).
Type postgresql into the search box, select postgresql-client and
press "next" to install.
Now you can open Cygwin terminal and type psql to run!
The best combo for Cygwin on Windows, I've found, is the normal Windows Postgres installation combined with Cygwin psql.
Cygwin psql (and other command-line tools) can be compiled from source fairly easily. Here's the steps for 9.2.4:
$ wget http://ftp.postgresql.org/pub/source/v9.2.4/postgresql-9.2.4.tar.bz2
$ tar xjf postgresql-9.2.4.tar.bz2
$ cd postgresql-9.2.4/
$ ./configure
$ cd src/bin/psql
$ make
This creates a psql.exe binary that works well with Cygwin. However, by default, it tries to connect to the local instance using a Unix socket instead of TCP. So use -h to specify the hostname and force TCP, for example:
$ ./psql -h localhost -U postgres
Move this psql.exe to someplace on your path (e.g. ~/bin) and possibly wrap in a script to add '-h localhost' for convenience when no other arguments supplied.
The source could be modified to change the default, but that takes actual work ;)
If I understand your question correctly you are running cygwin because you want to run queries against PostgreSQL via bash and psql on Windows, right?
Cygwin can run Windows binaries from bash, so install the native Windows builds and make sure psql.exe is in the PATH You should be able to copy the executable if necessary.
There is no need to install a native Cygwin build of PostgreSQL. Just use the existing psql tool, and make sure you can access the Windows-native psql.exe.

I am getting error ssh exit staus 1

In jenkins post build action I configured Execute shell script on remote host using ssh
ssh site 10.32.25.66, command:
cd $HOME/appsadm/bin; ./ims-carte-stop
and i again modified
cd /HOME/appsadm/bin; ./ims-carte-stop.*
I tried both these commands and Build is successful, but I see in console output in Jenkins after, that it is not executing my script. I am getting ssh exit status 1 error.
In my winscp my script (ims-carte-stop) in this location home/appsadm/bin.
Please tell me if I am doing aything wrong.
My intention is to stop my server from jenkins automatically whenever the build success.
This may be a typo in your question, but:
You said your ims-carte-stop script is in:
/home/appsadm/bin
whereas your script is doing:
cd $HOME/appsadm/bin
or
cd /HOME/appsadm/bin
Looking at the paths, I am going to assume you are using a UNIX-flavoured OS (Linux, BSD, OSX).
UNIX paths are case sensitive. Your script should be calling:
cd /home/appsadm/bin
Note that the word "home" is all small letter not capitals. Also, using $ makes it a variable, which I don't think you want.

rsync exits with the message "stdin is not a tty"

I want to use rsync to my remote server for which I have SSH access. I use the following command:
rsync -e 'ssh -p 22222' -rtz --delete content_dir/ user#example.com:/home/user/public_html
After entering the command, it asks for the password for the remote location. When I type it, it exits with the message,
stdin: is not a tty
How do I supply the password to rsync? The method suggested should also work when I use it in a shell script.
You need to add:
[ -z "$PS1" ] && return
to the beginig of .bashrc that is located in your home dir.
The password is being accepted here, as you've stated yourself the operation does happen.
The error message "stdin: is not a tty" is due to something in the startup script on your server attempting to process an action that should only happen for interactive logins (when you connect with ssh direct to the server, etc).
[ -z "$PS1" ] && return solves the problem but it checks whether the prompt string length equals to zero and if it does then exits. Although $PS1 will not be set in a non-interactive shell, $PS1 being of zero length doesn't ultimately mean that the shell is not interactive.
Better approach is to check the shell's current options using $-. For example [[ $- != *i* ]] && return.
In case a simple return doesn't do the job, here's another approach taken from this blog article:
if `tty -s`; then
mesg n
fi
tty -s checks if there's a TTY attached (the -s tells it to do so silently and just exit with the appropriate return code). tty returns the tty attached (e.g. "/dev/pts/1"). This should be safer than checking some shell variable ;)
mesg controls the write access to your terminal (msg n disallows writing to the (in our case non-existing) terminal), and thus requires one to be present.
On some systems (in my case Debian Jessie, but there are also reports on Ubuntu) mesg n1 is set unconditionally in either ~/.bashrc or ~/.profile. So if it exists that way, this might be the culprit.
As with the other examples, you can of course make that a one-liner: [[ $(tty -s ) ]] && mesg n. And nobody keeps you from combining the two:
if [[ $(tty -s ) ]]; then
mesg n
else
return
fi
Btw: According to the linked article, this fragment should go to the .bashrc of the machine you connect to (the "remote") – so if that's johndoe#somehost, this should be applied at the start of /home/johndoe/.bashrc on somehost. In my case I only got rid of the message after having applied this change on the "calling host" as well.
PS: Also check the .profile if it has a stand-alone msg n command (it did in my case). If it does, wrap it there.
1: mesg n is used to prevent other users on the machine writing to your current terminal device, which per se is a good thing – but not helpful for some rsync job ;)