x-haui

From the variety of available email clients, I found Claws Mail to be my favorite (maybe 'cause after 6 years of Linux, I still haven't found the time to configure mutt...). Anyway, in today's posting I will not praise the advantages of Claws Mail, but rant a little about one of its "security" features. Like most programs, Claws Mail stores its configuration in a separate directory in the user's home folder. This folder contains, among other things, all account information. Since Claws Mail doesn't offer any kind of password manger or "master password" one would think, that the passwords for the mail accounts are stored in plain text. However, the accountrc file contains base64-encoded strings of DES-encrypted passwords. At this point, one should wonder how the program can encrypt the passwords without asking the user for a password. The solution is simple - the password is hardcoded into the binary. With this knowledge it's obvious that this approach is a clear case of security through obscurity. Given the accountrc file and the binary everyone can easily decrypt the passwords, i.e. with this standalone C program.
If you're asking for more security than restrictive file permissions for your home folder can provide, you still got several options. Patch Claws Mail's sourcecode in order to use a real password safe for the storage of the passwords, use file encryption (either for your complete home folder, or just for ~/.claws-mail, e.g. with encfs), or switch to another email client.

To switch easily between the HTTP and HTTPS version of a website, I wrote a small plugin for Vimperator that can be found here. Save it into ~/.vimperator/plugins/ and restart Firefox. You should now be able to switch between the HTTP and HTTPS version of a website by pressing \h.

Recently I had to commit a bunch of changes via SVN. Cause it's really recommended to review all changes made in the working directory before actually committing the data, I issued a svn status | grep ^M to see all files that have been modified since the last commit. The result was a fairly long list of files and I wanted to check which changes where actually made to each individual file. Of course, every SVN user knows about svn diff or even better svn diff | less, which gives a complete diff of all modified files.
However, I don't really like this output...it just glues diff after diff together an if you scroll too fast, you will miss one or more small but important changes. That's why i wanted to have a mechanism, that shows one diffed file at a time until I explicitly proceed to the next file. My first approach was a simple one-liner:

svn status | grep ^M | awk '{print $2}' | while read l; do echo "****** $l ******"; svn diff "$l" ; read tmp; done

As you will notice, this doesn't really work - the two read commands take turns in reading the output of svn status. One elegant solution for this includes the use of the shell builtin exec:

#!/bin/bash
exec 3<&0
svn status | grep ^M | awk '{print $2}' | while read l; do echo "****** $l ******"; svn diff "$l" | less ; read tmp <&3 ;done

The line following the shebang creates a copy of the current stdin (filehandle 0) and assigns it to a new filehandle 3 i.e. 0 and 3 both will read commands from the keyboard being the default in a newly created shell. In the next line filehandle 0 is redirected several times (remember: a | b redirects the stdout of a into the stdin of b), so the first read reads its lines from the awk command. The second read, however, reads its input from filehandle 3 which still has the value that filehandle 0 had in the beginning of the script, i.e. it reads the keyboard input (I also piped svn diff through less, but that's just a small enhancement which is unrelated to the main problem).
This is just a simple example for the powers of bash's redirection, more complex ones do exist ;)

While older versions of Adobe's Flashplayer for Linux made content like Youtube videos accessible via the /tmp filesystem, the latest versions hide these files from the user by exploiting a feature of unlink:

If the name was the last link to a file but any processes
still have the file open the file will remain in existence until
the last file descriptor referring to it is closed.

In other words, the flashplayer creates a new file in /tmp, deletes the file right away with unlink but keeps the filehandle open, so the flashplayer process may still access the file.
This however, may lead to confusion - df reveals that the free space on /tmp is shrinking, while du doesn't show any growing files at all.
One way to fix this issue is simple - use library preloading to overwrite the original unlink function used by firefox: Download the tgz-archive, unpack it and make it. If the previous steps were successful, you should now have a file unlink.so available. The last step is to tell firefox (or more precisely the dynamic linker) to use the unlink function from this file rather than the one from your C Standard library:

LD_PRELOAD=/path/to/unlink.so firefox

The LD_PRELOAD environment variable tells the dynamic linker to search for libraries in non-standard locations - in this case in our library file unlink.so. You might want to add an alias like the following to your environment, but for obvious reasons you shouldn't globally export LD_PRELOAD.

alias ff="LD_PRELOAD=/path/to/unlink.so firefox"

Yet there is one drawback with this solution: even if you close firefox, the files in /tmp will persist, so you may want to delete them manually from time to time...

Though alternatives like the zsh exist, the Bourne-again shell is still the de facto standard among all Unix shells. Maybe that's why some people refer to it as the Windows of the shells - although there are now better alternatives around, most users still stick with it. I am one of these users - that's why today's blog entry is about some useful, but little-known bash features. ;-)
Note that you'll need at least Bash v4.0 for some of them.
The Bash built-in shopt allows you to (de)activate various variables in order to control optional shell behavior. shopt called without an argument gives you an overview of all available options. To activate a feature, simply issue shopt -s OPTION - if you'd like to deactivate the feature again, a shopt -u OPTION suffices. If you wonder what's so tricky about this, just read on - basic knowledge of shopt is needed to benefit from the following.
Everybody knows about the extremely useful for-loop, which allows it to perform the same command for all (or a subset of all) files in a directory. Its syntax is pretty much straightforward:

for file in *; do echo "Touching $file"; touch "$file"; done

This will touch every file in the current directory and tell you about it (not really a real world example, but you might get the point). However sometimes you'd like to also work on the files in all subdirectories - two popular solutions for this include the find command or recursion. As a rule, most users forget/don't know about the Bash's globstar option. If set (shopt -s globstar), you may use the following construct to also touch the files found in all subdirectories.

for file in **/*; do echo "Touching $file"; touch "$file"; done

Just want to touch all mp3 files? Here you go:

for file in **/*.mp3; do echo "Touching $file"; touch "$file"; done

Considering the previous example, you may notice that globbing doesn't include hidden files - which in most cases makes sense. Nevertheless, you can alter this standard behavior, by enabling the dotglob option using shopt

While the above examples mostly cover batch processing, some options only influence the interactive shell usage. If cdspell is set, the bash will generously ignore spelling mistakes in the directory component of a cd command:

user@host /var/tmp $ mkdir example_
user@host /var/tmp $ cd example
-bash: cd: example: No such file or directory
user@host /var/tmp $ shopt -s cdspell
user@host /var/tmp $ cd example
example_
user@host /var/tmp/example_ $

autocd does a very similar job - if you issue a valid directory name without the prepended cd, you will automatically change to that directory.

These are just some of the available options - man bash knows and explains them all, so start reading.... ;-)

If you're one of the few yaydl users out there, you might have noticed that I didn't put too much effort in the project recently. As I don't see any chance of maintaining yaydl in an appropriate way over the next months, I decided to discontinue the whole thing. Feel free to use the script as long as it works for you, but please don't email me any bug reports or the like.

If you're looking for an alternative, I suggest you take a closer look at clive or youtube-dl.

Almost 4PM...time for some vim tips. :-)

• autocmd
  Vim's powerful autocmd feature can be used to automatically perform certain commands when a specific event occurs. The events that can be used as triggers range from creating a new file to resizing vim's window. A complete list of available triggers can be obtained by typing :help autocmd-events in vim. So, how's this useful?
  Let's say you write most of your Perl scripts in vim, why should you insert the shebang and some other stuff manually in a new file, when the editor can do this for you? The following two steps show you how it's done:
  1. Create a new file ~/.vim/skeletons/skeleton.pl containing a shebang for Perl as well as the recommended use strict/warnings statements:

     p=$(which perl); mkdir -p ~/.vim/skeletons; cat << EOF > ~/.vim/skeletons/skeleton.pl
     #!$p
     use strict;
     use warnings;
     EOF
     

  2. Put the following in your ~/.vimrc

     autocmd BufNewFile *.pl 0r ~/.vim/skeletons/skeleton.pl | :normal G
     

  Now, when you're creating a new *.pl-file it is automatically prepended with the contents of ~/.vim/skeletons/skeleton.pl and vim starts at the end of the file. Needless to say, that you can use multiple autocmd commands to support languages other than Perl.
• 
  
• Syntax check
  Everyone knows about vim's :make command, but did you know that it's possible to set the make program for each file type separately?

  autocmd FileType perl set makeprg=perl\ -c\ %\ $*
  

  By adding this to your ~/.vimrc, :make will no longer invoke make file but perl -c file instead, when you're editing a Perl script. As usual, Perl is just an example - i.e. Ruby programmers might use ruby -c or the like.
• 
  
• Y?
  There's some inconsistency between deleting and yanking in vim:
  dd deletes the current line, D deletes from the cursor to the end of the line.
  yy yanks the current line, but Y also yanks the current line...
  To yank all characters from the cursor position to the end of the line, you either need to type y$, or add a custom mapping for Y to your ~/.vimrc:

  map Y y$
  

• 
  
• Matchit
• Typing % in normal mode finds the next item in the current line or under the cursor and jumps to its match. Items include c-style comments, parenthesis and some preprocessor statements. Unfortunately, there's no native support for HTML or Latex, but there's a handy little plugin, that adds support for these and many other languages: Matchit.

Enough for one day....

yaydl 1.5.2 fixes the support for youtube....