[SOLVED] Need some script help scrubbing tarball list for directory name greater than
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Need some script help scrubbing tarball list for directory name greater than
Hello, all
Figure some here are script ninjas and will know of a way to do this!
I have to pull a tarball from a remote site on a nightly basis, unpack it and run an installer from within the created directory. I only want to extract these tarballs if the contents are newer than a previous version. Otherwise, the tarball will get removed. The tarballs are not always dished out guaranteed every day ergo the need to verify the version within before using it. The version is in the directory name(s) within the tarball.
Unfortunately, the version number is not presented on the tarball following download. There is a wildcard in the download URL to direct to whatever the latest build is, resulting in the downloaded tarball version hidden behind the parenthesis with no version number. Forcing to scrub the contents.
The bolded version number in the dir name is what I would like to read during the script run such that only if the version is greater than say *58224*, then keep going in the script.
The script so far, without checking the tar contents
Code:
#!/bin/bash
cd /usr/local/src
wget http://domain.com/software14.2-%7Bbuild.number%7D.tar.gz
RTN=$?
if [ $RTN -ne 0 ] ; then
tail -n10 /tmp/dwnld.log | mail -s "Download Error Report" -r "root@vm.local" "skagnola@domain.com"
else
find *.tar.gz -ctime -1 -exec tar zxpf {} \; \
&& find *.tar.gz -ctime -1 -exec rm -rf {} \; \
&& cd $(ls -1t | head -1) \
&& ./upgrade.sh --noPrompt
RTN=$?
if [ $RTN -ne 0 ] ; then
tail -n10 /tmp/dwnld.log | mail -s "Download Error Report" -r "root@vm.local" "skagnola@domain.com"
fi
fi
I'm not very familiar with using awk but have seen some use this to filter the output from viewing the contents of tar? Or if there is another way to accomplish this?
No need of the decimal portion of the number for the comparison ?. What if only that portion increments (insufficient data presented to say).
Yeah, I thought of that as well. Looked at the way the vendor is incrementing their version numbers and the longer portion is a more reliable number to base from.
So I am testing with this, a newer file version than the 58224; 58277 is within
Code:
old=58224
new=$(tar tvf software14.2-(version).tar.gz | grep -Po -m1 '[^-]+-\K\d+(?=\.\d+-bin)')
if (( new > old )); then
find *.tar.gz -ctime -1 -exec tar zxpf {} \; && find *.tar.gz -ctime -1 -exec rm -rf {} \; && cd $(ls -1t | head -1)
else
echo "Old file"
fi
But when running it against the archive, it is echoing back "Old file". What can be added to echo out what the regex is finding, for the sake of verifying?
btw, that regex is some really cool stuff! I need to brush up on regex skills. It does really cool things!
Bash keeps improving, but you still need to work around its shortcomings - nice keefaz.
Quote:
Originally Posted by skagnola
btw, that regex is some really cool stuff! I need to brush up on regex skills. It does really cool things!
Not a day goes by without me using regex. Couldn't live without it.
However ... the perlre that keefaz used is amongst the most difficult - to learn and get correct. It can frustrate as well as enthuse - I tend to use it only when "normal" regex fails me.
keefaz, that code is amazing. It works like a charm. I'm still in awe of that stuff. From an untrained eye it looks like jibberish, but it all has a purpose!
But now, the more I'm thinking about the way this vendor tarball pull is, the script comparing versions before doing anything, I am wondering if it would be more 'fool-proof' to determine a particular file inside has a time stamp within the last 24hrs? If it does, then proceed.
... stamped with the date it was completed. Since the vendor has had days when they did not upload a tarball - trying to figure the best way to let the script run without downloading / unpacking a version already worked with.
"Well what if they don't deploy for over 24hrs? Say over a weekend they do nothing? How would the date check work?"
I can run this only during the M-F week. From what I see in their version list history, the most they have missed are single days during the work week.
I don't know the whole tar content, but say if you have just one file with name that contains "SNAPSHOT " into it
Code:
# extract date from filename
dateTarbal=$(tar tvf software14.2-(version).tar.gz | awk '/SNAPSHOT/{print $4" "$5}')
# create today timestamp (seconds since Unix time)
today=$(date +%s)
# create snapshot timestamp
snapshot=$(date -d "$dateTarbal" +%s)
# now just substract the timestamps and convert result in hours
hours=$(( (today - snapshot) /60/60 ))
if (( hours > 24 )); then
# continue with update
fi
But I think it would be better to rely on software versioning to check for update
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.