an other BASH function question

lleb · 05-05-2012, 04:27 PM

This function is supposed to check the contents of a tarball against the directory it was created from, but im not seeing how it is checking the data in the tarball with the data in the, lets call it /home/user, directory.

What I see is the tar command to view the contents and pushes that information into a file called /tmp/bz-check.list, but i dont see it comparing that with /home/user.

So just what is this function using to match the files in the tarball with the /home/user directory? I am missing something here, or is this function incomplete?

Thanks in advance for the help.

Code:

### Check and verify tarball
#####################################

checkTar ()

{

tar tfj /tmp/${tarfilename} &> /tmp/tar2; bzerr="$?"; echo ${bzerr} > /tmp/bz-check.list

echo "Verifying compressed data." | tee -a ${LOG}
VERSTAT=`cat /tmp/bz-check.list`

if [ ${VERSTAT} -eq 0 ]
then
	echo "Verification of compressed data was successfull." | tee -a ${LOG}
else
	echo "Compressed data appears to be corrupt.  Error ${VERSTAT}." | tee -a ${LOG}
	exit 1
fi

    echo "Encrypting ${tarfilename}" | tee -a ${LOG}
    openssl des3 -a -salt -in /tmp/${tarfilename} -out /tmp/${tarfilename}.enc -pass pass:xxxxxxxxxx
    echo "${tarfilename}.enc Encrypted" | tee -a ${LOG}
	NEWTAR=/tmp/${tarfilename}.enc

# to decrypt: openssl des3 -a -d -salt -in 2011-12-20.tar.bz2.enc -out 2011-12-20.tar.bz2 -pass pass:xxxxxxxxxx

}

pan64 · 05-05-2012, 04:54 PM

because it does not verify the data, it just verifies if the tar command was successfully executed.

lleb · 05-05-2012, 05:00 PM

thanks, didnt think it did. is there a way to verify that the data in the tarball is the (at least same number of files and same name of files) as the original location?

pan64 · 05-05-2012, 05:05 PM

yes, there is a way, just read the man page of tar (there is a t - test flag)

David the H. · 05-05-2012, 05:07 PM

Not only that, it does it in about the most complex and inefficient way possible.

It first saves the "$?" exit code to a second variable, then echo's that variable into a text file. Then it cat's the file contents back into another variable, and finally checks that for success.

I won't even mention the confusing formatting or the unquoted variables.
Oh wait, I guess I just did.

lleb · 05-06-2012, 12:35 PM

this is not my code, at least that function is not. pan64, thanks ill read up on the -t for tar and see what i can glean from there to improve that section of the overall script.

lleb · 05-06-2012, 12:54 PM

Quote:

Originally Posted by David the H.

Not only that, it does it in about the most complex and inefficient way possible.

It first saves the "$?" exit code to a second variable, then echo's that variable into a text file. Then it cat's the file contents back into another variable, and finally checks that for success.

I won't even mention the confusing formatting or the unquoted variables.
Oh wait, I guess I just did.

David, the quoted variables, should they be like the following, (im still a mega newbie at code)

Code:

i [ "${VERSTAT}" -eq 0 ]

I that what you are referring to? or did I do that wrong. I have only seen variables either in or out of {} with a leading $

ex:

Code:

JUNK=junk

$junk
${junk}

the only time i have seen a variable "" is if it was a command or a part of a test...

Code:

if [ "${junk}" != "stuff" ]

should all of the variables in the #!/bin/bash script be ""?

lleb · 05-06-2012, 01:44 PM

ran into a bit of an issue, when i use tar cvjf it creates a tar that when i untar with -xvf it keeps the directory structor of the original location, ex:

/home/user/stuff/more/stuff/foo.sh

if i then take my tar and open it, it will create that directory tree under where i am:

/home/user/stuff/more/stuff/home/user/stuff/more/stuff/foo.sh

That makes it an issue for using tar --diff -vf foo.tar.bz2

now what?

pan64 · 05-06-2012, 01:46 PM

actually for $? you do not need ", so "$?" and $? mean exactly the same. { and } needed only if otherwise the variable name cannot be identified, so $JUNK and ${JUNK} are identical (and both will mean junk, and do not forget, $junk is empty), but: $JUNK_EMTPY is empty, ${JUNK)_EMPTY will be junk_EMPTY.
if you are really interested read the man page and practice, practice and practice

lleb · 05-06-2012, 01:54 PM

I am using the following to create a tarball:

tar cvjf foo.tar.bz2 /path/to/files/

What I would like to be able to do is before i copy this tarball to some device, flash drive, external HDD, NAS device, etc... i want to run a --diff -vf on it to try to verify that the files in the original folder and that of the tarball are the same.

Yes this goes along with the bash function question i had earlier.

what I have discovered is the cvjf is not only creating the tarball, compressing in bz2 format, but it is preserving the directory structure of the folder. this is an issue when i run --diff -vf as i get the following results:

[server@user rx30]$ tar --diff -vf test.tar.bz2 /www/http/docs/rx30/*.sh
tar: /www/http/docs/rx30/autoftp.sh: Not found in archive
tar: /www/http/docs/rx30/autoftpd.sh: Not found in archive
tar: /www/http/docs/rx30/back.sh: Not found in archive
tar: /www/http/docs/rx30/connect.sh: Not found in archive
tar: /www/http/docs/rx30/freespc.sh: Not found in archive
tar: /www/http/docs/rx30/modemflash.sh: Not found in archive
tar: /www/http/docs/rx30/nasftp.sh: Not found in archive
tar: /www/http/docs/rx30/nasftpd.sh: Not found in archive
tar: /www/http/docs/rx30/nastftp.sh: Not found in archive
tar: /www/http/docs/rx30/nastftpd.sh: Not found in archive
tar: /www/http/docs/rx30/rsync.sh: Not found in archive
tar: /www/http/docs/rx30/rsyncd.sh: Not found in archive
tar: /www/http/docs/rx30/vgback.sh: Not found in archive
tar: Error exit delayed from previous errors

Those files are there when i navigate to them, and they are in the original folder were i created the tarball. this is an issue.

What can i do to prevent this, or what needs to be done to get around this issue?

i hope that is a bit more clear.

Thanks in advance.

lleb · 05-06-2012, 01:55 PM

Quote:

Originally Posted by pan64

actually for $? you do not need ", so "$?" and $? mean exactly the same. { and } needed only if otherwise the variable name cannot be identified, so $JUNK and ${JUNK} are identical (and both will mean junk, and do not forget, $junk is empty), but: $JUNK_EMTPY is empty, ${JUNK)_EMPTY will be junk_EMPTY.
if you are really interested read the man page and practice, practice and practice

thanks pan, what was david getting at then? you explained it exactly the way i thought i understood it.

David the H. · 05-06-2012, 02:15 PM

I'd gathered that it wasn't your code from the way you talked about it. You wouldn't be asking us what it does if you'd written it yourself.

As for the variables, you're exactly correct. According to the shell parsing order, after a parameter is expanded (or a command substitution made), the results are word-split into separate elements according to the characters set in the IFS variable (space,tab,newline by default). Then after that, pathname expansion (globbing) is performed, which could further alter the final results.

Placing double quotes around the parameter protects the expanded contents from shell interpretation, preventing the last two steps from happening.

Of course, if you are certain that the value contains nothing that will split or expand, you can leave them off, and sometimes you may actually want splitting to occur, but otherwise it never hurts to be safe.

There are also a few places where the shell doesn't perform the following expansions, such as inside the "[[..]]" double bracket test or when doing "var1=$var2". But it still doesn't hurt to use quotes even then (the right hand side of the double-bracket test is a partial exception, as any globbing or regex tests need to remain unquoted in order to match properly).

So in short, unless you have a good reason to do otherwise, you should always quote.

Argument parsing is a vitally important concept in scripting, so train yourself to do it correctly now.

http://mywiki.wooledge.org/Arguments
http://mywiki.wooledge.org/WordSplitting
http://mywiki.wooledge.org/Quotes

The use of the full "${var}" form of the variable in the code above was one of the things I rolled my eyes at. While not wrong in any way, it simply serves no good purpose, and just clutters up the code. The only times you need the brackets are when doing parameter substitutions, expanding positional parameters higher than nine, or when you need to clearly separate the variable name from the following text, like this:

Code:

echo "${foo}bar"

Without the brackets, the shell would attempt to expand a variable called "foobar" instead.

lleb · 05-06-2012, 02:32 PM

thanks david, and thanks for the links. i just got in the habit of ${var} and try to do that when i can. i know it is not required, but i feel better safe then sorry. as for the "${var}" the only time ive seen that is in the example i provided in the test. not sure it is needed there either except for the "stuff" portion in the test.

pan64 · 05-06-2012, 02:34 PM

Quote:

Originally Posted by David the H.

So in short, unless you have a good reason to do otherwise, you should always quote.

Superfluous quotes make the code unnecessarily noisy. I do not like them, so I use them only when they really have meaning.

lleb · 05-06-2012, 03:49 PM

good stuff on the code, what about the tar --diff -vf issues?