Archive

Archive for the ‘System & Shell’ Category

Remap keys in Ubuntu

August 13, 2013 Leave a comment

A comfortable way to re-assign keyboard keys is by creating the file ~/.Xmodmap in the home directory, and putting line by line one re-assignment after the other. The typical format is ‘keycode <number> = <symbol>‘, but there are more possibilities (see ‘man xmodmap‘ or search for ‘Xmodmap’ for details). An example is:


keycode 112 = Home
keycode 110 = Prior
keycode 117 = End
keycode 115 = Next
keycode 134 = Delete

The number to the left identifies the pressed key itself. It can be determined by running ‘xev‘. The symbol to the right is the new action when the specified key is pressed without any modifier. You can define up to four space-separated symbols, where the second is applied if SHIFT is additionally pressed, the third if ALT, and the fourth if ALT+SHIFT. Use ‘NoSymbol’ if you do not want to let any action happen at all. For example:


keycode 16 = 7 slash NoSymbol backslash

This defines the mapping for key with keycode 16, which is usually the key labeled with ‘7’. The mapping defines to act like symbol ‘7’ when pressed without any modifier (note that the ‘7’ is the symbol for the number 7, but not a keycode as it would on the left). Further, SHIFT+7 gives slash, ALT+7 is ignored, and ALT+SHIFT+7 gives the backslash.

Changes are applied after logging out and in again.

Categories: Computer, System & Shell

Send Mail with Attachment from the Commandline

November 23, 2011 Leave a comment

Under Linux, you can send some file “test.pdf” attached to an email by typing:

uuencode test.pdf test.pdf | mailx -s "Title for my email" myname@mydomain.com

So what’s going on there? uuencode takes two input parameters: the file to read and the filename how it should appear at the mail. The file is converted to an ASCII-string and piped to mailx. The email is created with the given title (after the -subject flag) and then send to the given email address. The text-encoded file as piped from uuencode is attached to the body. Any modern email client is able to recognize this attachement.

The following script can be used to send a file including a subject to some fixed email. Some help is printed if it is called with the wrong number of parameters.

#!/bin/sh
if [ $# -ne 2 ]; then
        echo "sendfile <filename> \"title\""
        exit 1
fi
uuencode $1 $1 | mailx -s "$2" mymail@mydomain.com

Just save these lines in some file (e.g., sendfile) and make it executable (e.g., with chmod 755 sendfile).

Mounting an .iso file

October 30, 2011 Leave a comment

In Linux it is easy to access the content of some .iso-file directly without having to burn it to a CD/DVD. Just mount the .iso-file to some directory of your choice and you can browse it like any directory:

sudo mount <iso-file> <existing directory> -t iso9660 -o loop

The following script also prints some help if called with the wrong number of parameters and creates the directory if not yet existing:

#!/bin/sh

# print help if called with wrong parameter count
if [ $# -ne 2 ]; then
        echo "USAGE:   isomount <isofile> <location>"
        echo "INFO:    Mounts the specified .iso-file to the given"
        echo "         directory location (if it is not existing then"
        echo "         it is created with user-rights)"
        echo "EXAMPLE: isomount MyFile.iso /tmp/fooooo"
        exit 1
fi

# create directory if not existing and exit on error
if [ ! -d "$2" ]; then
        mkdir $2
        if [ $? -ne 0 ]; then
                exit 1
        fi
fi

# mount the iso-file
sudo mount $1 $2 -t iso9660 -o loop

Just save these lines in some file (e.g., isomount) and make it executable (e.g., with chmod 755 isomount).

Categories: Computer, Shell Scripts Tags: ,

How to restore crontab entries from scratch after accidentally typing ‘crontab -r’

February 9, 2011 8 comments

What happens if you type crontab -r instead of crontab -e ? Well, your crontab gets immediately deleted, without any further confirmation request. That is sub-optimal, especially because ‘r’ lays next to ‘e’, which is frequently used for editing the crontab (I really would appreciate it if crontab -r would ask the user, while crontab -R would not ask).

The first thing to try to undo the mistake, is to check whether there are some backups of the previously installed crontab (e.g. in /etc/cron* or some system-dependent backup) and then reinstall these.

If this is not the case (as usual), then there is no other way than creating a new crontab. But how do we know which entries were defined in it before deleting? Here, the system logs in /var/logs/ help us a lot, since it stores all crontab-calls of the long past and makes them easily to extract, since “/usr/sbin/cron” is part of the message (possibly in upper-case!). So, depending on your system, cat and grep all crontab lines from the messages* files into some output file, e.g.,

cat /var/logs/messages | grep -i "`which cron`" > /tmp/cron

where `which cron` is used to automatically be replaced by for example /usr/sbin/cron, depending on your system. You should also append all data from older messages, as usually stored as .gz or .bz archive. For .gz you might use:

gzip -d /var/logs/messages*.gz -c | grep -i "`which cron`" >> /tmp/cron

Now /tmp/cron is a file that contains all crontab-calls. You might use the less command to display its entries. Choose any line to handle at first, and Copy&Paste its <command> call (where <command> denotes the stuff in the bracktes after ‘CMD’) to a new textfile in which you rebuild your new crontab. To get the time interval for this command call, use the search function and have a look at the date/time when this call is repeated. Using less, just type /<command>, this will highlight all occurences. So, once you have extracted this call and recreated it using the appropriate * * * * * <command> syntax, you might delete all its occurences from /tmp/cron. You might do this by

cat /tmp/cron | grep -v "<command>" > /tmp/cron.out; mv /tmp/cron.out /tmp/cron

By repeating these steps, the file /tmp/cron gets smaller and smaller and you finally can be sure to have all crontab-calls handled that were made in the past since the first log entry.

Furthermore, since the file /tmp/cron decreases quite rapidly over time (there might be thousands of lines for just 10 crontab commands or so), you get the feeling to make progress, so its not that awful anymore that you called crontab -r before 🙂

After installing the newly created crontab, you should call the following command to manually backup your crontab:

crontab -l > ~/crontab.bak

Hopefully, this helps some of you out there that are in the same problematic situation…