/dev/blog

Sometimes it’s very useful to know which git branch you are working on right from the command prompt. There are many solutions out there, but most of them include python and some awk or grep magic which can time a serious amount of time when you cd into a reasonably large git tree.

But you can also take advantage of the __git_ps1 function, provided by /etc/bash_completion.d/git in the git package. Add this line to ~/.bashrc:

export PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '

This setting helps you keep track of which branch you are in at a given time. If you are in a git working directory, it shows the current branch as part of the prompt:

[user@host directory-name (master)]$

If you do not have the bash-completion package installed, you must manually source the git completion script prior to using __git_ps1(). To do this, add

source /etc/bash_completion.d/git

to ~/.bashrc.

You might also want to display when there are changes in your work tree or the git index:

[user@host directory-name (master*)]$
[user@host directory-name (master+)]$
[user@host directory-name (master%)]$

• * indicates that a tracked file was modified
• + indicates that a tracked file was modified and staged (with git add)
• % indicates that you have untracked files in your tree

To do so, simply add these lines in your ~/.bashrc, right before the line modifying your prompt:

export GIT_PS1_SHOWDIRTYSTATE=true
export GIT_PS1_SHOWUNTRACKEDFILES=true

See the comments at the beginning of /etc/bash_completion.d/git for more details.

When an upgrade includes changes to a default configuration file, the package will write either a .rpmnew or a .rpmsave file instead of overwriting the configuration file on your system. Which file a package creates is up to the discretion of the package maintainer.

From “Dealing with .rpmnew and .rpmsave files” By Bruce Byfield:

An .rpmnew file contains the new default configuration file and leaves your original configuration file untouched. By contrast, and .rpmsave file is a copy of your original configuration file, which has been replaced by the new default file.

The following script can be helpful to find (and possibly merge) those files with your original configuration

for a in $(find /etc /var -name '*.rpm?*'); do diff -u $a ${a%.rpm?*}; done

You may also want to check on yum-merge-conf, a yum plugin to merge configuration files.

Sometimes, extracting a whole tar archive can be a waste of time (and temporarily disk space).

To extract just a single file, you can use

tar -x file -zf archive.tar.gz -C /tmp/

This extracts the file file to /tmp/

Of course, most of the time the relative path to the file is not as simple as in the example above:

tar -x path/to/file -zf archive.tar.gz -C /tmp/

This creates the file /tmp/path/to/file.

To avoid the creation of the file’s relative path (or parts of it) in the target directory, use the switch --strip-components

tar -x path/to/file -zf archive.tar.gz -C /tmp/ --strip-components=2

This creates the file /tmp/file

And finally, you can use stdout redirection to achieve the same result

tar -x path/to/file -zf archive.tar.gz -O >/tmp/file

or even shorter

tar xfz archive.tar.gz path/to/file -O >/tmp/file

Well, there is no native command (at least, afaik), but you can use find to easily identify empty folders (which maybe helpful for maintenance, etc.):

# find /path -type d -empty

Find empty folder and list

# find /path -type d -empty -exec ls -ld {} \;

Find empty folder and save as temporary file

# find /path -type d -empty -exec ls -ld >> /tmp/savefiles.txt {} \;

Find empty folder and delete

# find /path -type d -empty -exec rmdir {} \;

q.v. find manpage

Unfortunately, there is no way to pipe data directly to scp simply because scp can’t read from stdin. But you can abuse ssh to achieve the same result

tar cz a/dir | ssh user@remotehost.com "cat >outfile.tar.gz"

You can even do some funny things like

tar c /data/ | lzma -c -z | gpg --batch --force-mdc -ac -o - --passphrase-fd 3 -c 3< /etc/gpgpassphrase | ssh user@remotehost.com "cat >/data/backup.tar.lzma.gpg"

If you want to use GnuPG in a script and don’t want to be prompted for the passphrase, put the passphrase in a file called passphrase.txt and use this to encrypt:

gpg --passphrase-fd 3 -c 3< passphrase.txt < filename > filename.gpg

Of course, you can also use echo to specify your passphrase

gpg --passphrase-fd 3 -c 3< <(echo "secret") < filename > filename.gpg

or you can pipe a tarball into gpg

tar -cf - dir/ | gpg --passphrase-fd 3 -c 3< <(echo "pass") > backup.tar.gpg

or even send a gpg encrypted tarball via e-mail

tar c dir/ | gpg --force-mdc -ac -o - --passphrase-fd 3 -c 3< <(echo "pass") | mail user@domain.tld

Note that you have to use the --batch flag if you want to run gpg from a cron script. (Otherwise gpg tries to read from /dev/tty that doesn’t exist for cron jobs)¹.

More GnuPG hacks can be found here: http://www.linuxjournal.com/article/8732

[1] http://stackoverflow.com/questions/39867/how-to-run-gpg-from-a-script-run-by-cron

The Lempel-Ziv-Markov chain algorithm is a (at least in the Linux-world) relatively new compression method. It features a very high compression ratio that is generally much higher than bzip2¹. Unfortunately there a quite a few different implementations. So creating and extracting lzma archives on different Linux distrubutions will vary.

While the latest Fedora comes with GNU tar 1.22, which has a built-in flag for lzma compression, CentOS still uses GNU tar 1.15.1; So you will have to pipe your tarball manually to the lzma binary. Here is an example:

On Fedora 11, creating an lzma compressed tarball is rather simple:

tar cfv backup.tar.lzma a/dir --lzma

Just like decompressing it

tar xfv backup.tar.lzma --lzma

You may want to skip the verbose flag v in a script.

On CentOS 5.3 you first have to pull lzma from a 3rd party repository like RPMFusion

yum install lzma

before you can create you archive with:

tar cv a/dir | lzma -c -z > backup.tar.lzma

For decompression, just pipe the hole file into lzma -d and un-tar the output:

cat backup.tar.lzma | lzma -d | tar xv

Again: You may want to skip the verbose flag v in a script.

[1] http://www.linuxjournal.com/node/8051/print

Just as you can convert entire files from one charset to another, you can convert the filenames. For example:

convmv -f iso-8859-15 -t utf-8 -r .

would recursively convert all files in the current directory from iso-8859-1 charset into utf-8. Well, not exactly. To finally rename the files you need the --notest flag. Otherwise convmv will perform a dry run without any changes.

Howto convert iso-8859-1 charset files into utf-8? Simple:

iconv --from-code=ISO-8859-1 --to-code=UTF-8 oldfile > newfile

Of course, your values for --from-code and --to-code may vary. For a list of available encodings use iconv --list

Just because I always forget:

Step 1: Create public and private keys using ssh-keygen

[user@Host ~]$ ssh-keygen
Generating public/private rsa key pair.
Enter file in which to save the key (/home/user/.ssh/id_rsa):
Created directory '/home/user/.ssh'.
Enter passphrase (empty for no passphrase):
Enter same passphrase again:
Your identification has been saved in /home/user/.ssh/id_rsa.
Your public key has been saved in /home/user/.ssh/id_rsa.pub.
The key fingerprint is:
0d:d2:94:07:93:a9:48:b9:33:73:fb:f1:6e:33:ce:d7 user@Host
The key's randomart image is:
+--[ RSA 2048]----+
|     .  +=       |
|    o  o+..      |
|   . o..o.       |
|    * o. o       |
|     = .S .      |
|      . .        |
|       . o   .   |
|        ..= . E  |
|         +++     |
+-----------------+

Step 2: Copy the public key to remote-host using ssh-copy-id

Now here comes the awesome part: You don’t have to scp the public key to your remote host and cat it into ~/.ssh/authorized_keys. Instead, you can use ssh-copy-id

[user@Host ~]$ ssh-copy-id -i .ssh/id_rsa.pub user@remote-host
user@remote-host's password:
Now try logging into the machine, with "ssh 'user@remote-host'", and check in:

  .ssh/authorized_keys

to make sure we haven't added extra keys that you weren't expecting.