unrar t file.rar
if [ $? -eq 0 ]; then
  echo "Rar file is good?"
fi

However it was returning zero all the time, even when the file wasn’t a rar:

# unrar t file.rar
 
UNRAR 3.80 freeware      Copyright (c) 1993-2008 Alexander Roshal
 
file.rar is not RAR archive
# echo $?
0

So it fails the test but returns zero regardless. This makes it very unhelpful for using in scripting. Fortunately enough a mate on IRC discovered that his version did.

So I first download the existing SRPM and installed it:

# yumdownloader --source unrar
# rpm -i unrar*.srpm

Then I installed that and simply modified so I downloaded the latest, created a RPM and installed.

I have submitted the updated spec file to RPMfusion.

[root@marine]# ls
adobe-release-i386-1.0-1.noarch.rpm
[root@marine]# yum localinstall adobe-release-i386-1.0-1.noarch.rpm
Loaded plugins: fastestmirror, priorities
Setting up Local Package Process
Examining adobe-release-i386-1.0-1.noarch.rpm: adobe-release-i386-1.0-1.noarch
Marking adobe-release-i386-1.0-1.noarch.rpm to be installed
Loading mirror speeds from cached hostfile
* addons: anorien.csc.warwick.ac.uk
* base: anorien.csc.warwick.ac.uk
* centosplus: anorien.csc.warwick.ac.uk
* contrib: anorien.csc.warwick.ac.uk
* extras: anorien.csc.warwick.ac.uk
* rpmforge: fr2.rpmfind.net
* updates: anorien.csc.warwick.ac.uk
588 packages excluded due to repository priority protections
Resolving Dependencies
--> Running transaction check
---> Package adobe-release-i386.noarch 0:1.0-1 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
Package              Arch     Version Repository                          Size
================================================================================
Installing:
adobe-release-i386   noarch   1.0-1   /adobe-release-i386-1.0-1.noarch   1.9 k

Transaction Summary
================================================================================
Install      1 Package(s)
Update       0 Package(s)
Remove       0 Package(s)

Total size: 1.9 k
Is this ok [y/N]: y
Downloading Packages:
warning: rpmts_HdrFromFdno: Header V3 DSA signature: NOKEY, key ID f6777c67

Public key for adobe-release-i386-1.0-1.noarch.rpm is not installed

As you can see it attempted to install but because the key was missing it refused to install. So what do we do to find that key? First we must download the key from somewhere, there is various key servers around the world, some of the most popular are (note hkp is the HTTP keyserver protocol):

• hkp://subkeys.pgp.net
• hkp://pgp.mit.edu
• hkp://keys.gnupg.net
• hkp://wwwkeys.uk.pgp.net (where UK can be replaced by any country code)

So lets search for the missing key:

[root@marine]# gpg --keyserver hkp://wwwkeys.uk.pgp.net --recv-keys f6777c67
gpg: requesting key F6777C67 from hkp server wwwkeys.uk.pgp.net
gpg: /root/.gnupg/trustdb.gpg: trustdb created
gpg: key F6777C67: public key "Adobe Systems Incorporated (Linux RPM
  Signing Key) " imported
gpg: no ultimately trusted keys found
gpg: Total number processed: 1
gpg:               imported: 1

So now we have the key and see that it is indeed Adobe’s key. Now all we need to do is add into RPM:

[root@marine]# gpg --armor --export f6777c67 >tmp-gpg.key
[root@marine]# rpm --import tmp-gpg.key

Simple as that, the install will work now!

This post is a refreshed look at a previous post on the same matter.

(Orlando) sed regex kicks my ass.  I like to remove the second : in the
line. So that in 123:456:6789 it will only returns 123:456.  I can find the
first :, but I have not been able to use s/:{2}// to find the second
one, and remove the rest.

I enjoy regex (I know I’m weird, leave me alone), so I was able to provide an answer to this problem:

(@znx) Orlando: the trick is to use [^:] and \1 ..
(@znx) like:   s/\(:[^:]*\):.*/\1/

Now obviously at first glance this regex could be a bit intimating to someone who is still picking up the skills but as with most things if we break it down it becomes easier.

Working out to in, \( \):.*, that says match something with : at the end and all the character after it. The . is a special meaning “any character” and * to match multiple characters. The first match will be stored by sed and assigned into the \1 for the replacement (that is what the brackets do). Inside the brackets we have :[^:]*. The sequence [^ ] is a negated list, that means that we are asking it to match everything that is NOT inside the list, in this case :.

Putting it altogether we are saying: Match a leading : and a trailing : with any characters after it. Placing the contents between the two : in memory. Then finally we replace the contents.

% echo 123:456:6789 | sed 's/\(:[^:]*\):.*/\1/'
123:456

Sucess, however as with most things, there is more than one way to skin a cat and regex is rarely the prettiest method. So what other ways can we solve this problem?

With AWK:

% echo 123:456:6789 | awk -F: '{print $1":"$2}'
123:456

With cut:

% echo 123:456:6789 | cut -d: -f1,2
123:456

As always, experimentation with the mass of GNU tools you can find on your system will bring a greater deal of power to your tool chest. Mind you, then I wouldn’t get complements for helping would I?

(Orlando) Wow, When I grow up, I like to remember this thing like you do.  

Haha, till next time!

<html><head><title>Status</title></head>
<table>
<tr><td>Failed</td><td>Backup Group</td></tr>
<tr><td>Success</td><td>Another Backup Group</td></tr>
</table>
</body>
</html>

Nothing odd there, the file is normal but when I tried this command:

$ grep -i failed status.html
$

Huh? No output, suggesting that there is no lines with the words failed on them. The same occurs with awk and sed, indeed I could not find any tool to be able to grep out the status. So the next step was to check what was odd about the file:

$ file status.html
status.html: HTML document text

Still, nothing unusual. So now I am in full head scratching mode, I open up the file with vim to see if I can discover anything strange about the file but nothing. At this point I happened to switch to more rather than cat and the result was the start of how I solved it.

$ more status.html
��<

$

Ah, so now I can see why grep and the others cannot view anything in the file. So this time I switch to vim again and check what file encoding we have:

:set fileencoding
fileencoding=ucs-2le

For those that are unaware, this is UCS-2 (little endian), also know as UTF-16. So the issue was simply that we had UTF-16 characters, now for the trick to get around it:

$ iconv -f UTF-16 -t UTF-8 status.html | grep -i failed
<tr><td>Failed</td><td>Backup Group</td></tr>
$

Tada. Once more a solution!