scp return codes different?

June 11, 2015 10:03 AM

I'm working on testing a modification to a bash script for work. I'm trying to scp a file to the same source directory. For testing purposes, I've altered the permissions on the target directory so that the scp'ing user doesn't have permissions to write to it. The first try I get a return code of 1. The second try I get a return code of 0, even though the permissions haven't changed and the file actually fails to transfer.

The basic flow is this:

* Try to scp the file.
* Immediately save off $? to a separate variable.
* If the scp attempt failed, move the source file off to a separate buffer area on the disk and continue.
* If the scp attempt succeeded, delete the source file and continue.

When the script has spare processing time:

* Look through the buffer area for files.
* Try to scp the file.
* Immediately save off $? to a separate variable.
* If the scp attempt failed, leave the source file there and come back later to try again.
* If the scp attempt succeeded, delete the source file.

So, to test the script, I've changed the permissions on the target directory such that the transfer will always fail due to invalid permissions.

The first time, $? is 1, causing my script to (correctly) move the source file off to the buffer area.
The second time, $? is 0, causing my script to (incorrectly) delete the source file even though the scp failed.

I'm using identical parameters to scp, other than the source file location. Permissions on the target directory did not change out from me in the mean time. Saving off the value of $? occurs on the very next line of the script from the scp attempt in both cases. The only thing I can possibly think of is that I need some sort of mutex lock around the scp and $? saving commands. Is there anything else that could be wrong?

posted by tckma to Computers & Internet (8 answers total)

Is it possible to post the whole script?
posted by jquinby at 10:20 AM on June 11, 2015

I tried what I think you're trying to do and got a 1 both times. Can you reduce the failing code to the smallest size required to demonstrate the problem and post it?

I looked on the bash section of Stack Overflow and didn't see your question. You might try posting it there, a lot more bash experts will see it.
posted by ubiquity at 10:22 AM on June 11, 2015

So I tried to duplicate your problem. On a host called compute I created a directory called SCPTEST and made it owned by root rather than normiep. From another machine, I created a test file, blahblah, and then ran this script. Both times it came up as it failed.

#!/bin/bash
scp blahblah normiep@compute:SCPTEST
RESULT=$?
if [ $RESULT -eq 1 ]; then
	echo 'It failed!'
fi
if [ $RESULT -eq 0 ]; then
	echo 'It worked!'
fi

scp blahblah normiep@compute:SCPTEST
RESULT=$?
if [ $RESULT -eq 1 ]; then
	echo 'It failed!'
fi
if [ $RESULT -eq 0 ]; then
	echo 'It worked!'
fi

Are you doing something substantially different than this? Can you post the relevant part of the script? I suspect it may have to do with how you're capturing the variable or something like that. If you modify the following script to your test machines, do you got different results than I do?
posted by NormieP at 10:23 AM on June 11, 2015

Yeah, we'd need to know the script and all the details of your setup. Pare down your script to the minimum required to reproduce the problem, and post it, together with a ls -ld of the target directory to verify the permissions, the output you see, etc.
posted by bfields at 10:34 AM on June 11, 2015

(BTW, you're probably building the scp commandline out of a bunch of shell variables for the filename, directory, server, etc. One wild guess would be that one of those variables is messed up (forgot to export one to a sub-shell, maybe?) so the scp target isn't actually what you think it is in the second case. Maybe insert a line echoing the commandline just before you run it, or use "set -x" or "-x" added to the #!bash line, to help debug.)
posted by bfields at 10:39 AM on June 11, 2015

Response by poster: In the process of copy/pasting the code I found a not-so-obvious typo in a variable name relating to the directory. I think that will fix it. It's always something stupid.
posted by tckma at 11:11 AM on June 11, 2015 [1 favorite]

Response by poster: Yes, that did the trick. On the second copy, I used ${dDestDir} for my destination directory when I should have used ${destDir}. A remnant of something else I had tried. Oy.
posted by tckma at 11:18 AM on June 11, 2015

I always put set -o nounset -o pipefail -o errexit at the top of my scripts. This probably would have given an error when you used the wrong variable name and saved you a lot of time.
posted by grouse at 11:26 AM on June 11, 2015 [4 favorites]