The Road to Elysium

April 3, 2011

Wallpaper concatenation with ImageMagick

Filed under: Linux — Tags: , , , , , , — jorge @ 21:03

At both home and work, I have a dual monitor setup. Having recently discovered the windowmanager xmonad, I’ve found a setup that enables me to use Xinerama, and at the same time have the functionality that a separate X screen-setup would provide me. But with Xinerama comes the Twin View-setting that the Nvidia drivers provide, which “merges” both monitors, and gives me one large virtual desktop. Finding wallpaper for it can be a bit tricky, especially the ones that are designed for one specific resolution. But this is where ImageMagick comes into play. What I want is two images, with different resolutions, side by side. You could of course use something else, like GIMP, but you’d have to align things manually, and why risk it when a simple command can do the trick?

First install ImageMagick:

yum install ImageMagick

..then do the magic:

montage wallpaper_1920x1080.jpg wallpaper_1680x1050.jpg -tile 2x1 -geometry "1920x1080+0+0" -mode concatenate final_wallpaper.jpg

By setting geometry to “1920×1080+0+0″, we set the preferred size of one of the tiles to be that, thus resizing images that are too large.

The results? Well, for me, this was it:

Enjoy!

March 24, 2011

Making your BASH history more efficient

There are several ways to improve how you troubleshoot a system. One of the things I consider to be important is the BASH history. Here you can see what commands were executed. Though as default you can’t see when, or ignore certain things, like duplicate commands. Here’s a little guide to show you how.

Table of contents

Notice: To make these features a permanent solution, open up your /etc/profile, and add the lines to the bottom of the file. Save and close it. The next time you log in the functions should be working as you specified them!

HISTTIMEFORMAT

A simple yet effective little trick is to change the format of the output the command history spits out. In my case it comes to good use when troubleshooting a system, wanting to find out if errors in the system log match up with commands executed at that time. To enable the feature in your current terminal, run:

export HISTTIMEFORMAT="%h %d %H:%M:%S> "

So the output from history that was looking like this:

[jorge@ashitaka ~]$ history
 1  ls
 2  echo "Hello"
 3  pwd
...

Now looks like this:

[jorge@ashitaka ~]$ history
 1  Mar 24 12:53:35> ls
 2  Mar 24 12:53:36> echo "Hello"
 3  Mar 24 12:53:37> pwd
...

HISTCONTROL

The variable HISTCONTROL can do a few things, like ignoring duplicates if they are in a row and erasing duplicates. The difference here is that by ignoring duplicates, it will remove duplicates only if they are in a row, while erasing duplicates, it will remove previous commands from the history file. Let’s give an example:

ignoredups

First run:

export HISTCONTROL=ignoredups

The output that looked like this:

[jorge@ashitaka ~]$ history
 1  pwd
 2  echo "Hello"
 3  ls -l
 4  ls -h
 5  pwd
 6  pwd
...

Will now look like this:

[jorge@ashitaka ~]$ history
 1  pwd
 2  echo "Hello"
 3  ls -l
 4  ls -h
 5  pwd
...

erasedups

erasedups means that if you executed the same command previously, that entry will be erased, substituted by the newly run command. Generally not recommended though. If you still wish to do so, it can be done by running the following line:

export HISTCONTROL=erasedups

So a history that looked like this:

[jorge@ashitaka ~]$ history
 1  pwd
 2  echo "Hello"
 3  ls -l
 4  ls -h
 5  pwd
...

After the export, will now look like this when we run the command pwd again:

[jorge@ashitaka ~]$ history
 1  echo "Hello"
 2  ls -l
 3  ls -h
 4  pwd
...

ignorespace

If you want full control over which commands will be stored by history and which will not be stored, set HISTCONTROL to ignorespace:

export HISTCONTROL=ignorespace

So out of these commands:

ls -la
 du -h
ps

Only these will show:

[jorge@ashitaka ~]$ history
 1  ls -la
 2  ps
...

ignoredups and ignorespace

To use both of these features, simply use:

export HISTCONTROL=ignoreboth

HISTIGNORE

The variable HISTIGNORE will help you tell history which commands to ignore, meaning that they shouldn’t be picked up by the BASH history. For instance, let’s say that I want the commands df and free to be ignored, including optional flags:

export HISTIGNORE="df*:free*"

HISTSIZE

Setting how many lines of history to store is always a nice feature:

export HISTSIZE=10000

Thanks to pkhamre for suggesting to include HISTCONTROL and HISTIGNORE. ;)

February 9, 2011

Introduction to screen

Filed under: Linux — Tags: , , , , , , , , , , , , , — jorge @ 14:49

screen is to many people an unknown program and tool, but for those who do know it, consider it to be an essential one. This is because of the functionality of the program, that can end up saving you a lot of work and time. You can run any number of console-based applications – editors, mail clients, browsers, in just a single terminal. Sometimes it’s useful to have a terminal for each console-based application you’re running, but sometimes not, obviously.

For my part, the main reason for me using screen is the ability to decouple the terminal emulator from the running programs. In other words, I can detach and reattach things as I please. To put it in simple terms; it’s a tool for session management. Let’s go ahead with an example.

You are logged into your remote server via SSH, working on some configuration file, when suddenly you lose connection to it. Almost done, having spent hours, you grab your laptop in anger and smack the closest unfortunate person next to you. Not only have you lost valuable work, but soon enough people with shields, guns and helmets will come after you. Imagine, with screen, it could have been avoided! Had you been editing the configuration file within a screen, and should you have lost connection, the editing would still be in an active screen session, allowing you to detach and reattach the screen to your terminal once you logged back in.

Let’s have a closer look at what we can do with screen.

Table of contents

Starting screen

Fire up a terminal and just type:

screen

If installed, you probably won’t get a message about having entered a screen session, but I’m sure you have. Everything functions just like a normal shell, except for a few special characters. screen uses the command Ctrl-A as a signal to screen instead of the shell.

To see the help page for screen, press Ctrl-A, then press ?. In other words:

^A ?

As you can see here, Ctrl is represented by the ^, A is a, and well, you get the rest.

To start a program directly into screen, just type screen . Let’s use top as an example.

Using screen

Fire it up:

screen top

top is started in the usual way, just inside a screen session. To detach the session and let it run in the background, use Ctrl-a d:

Ctrl-a d (^a d)

Once your session is detached you can list the available screen sessions by using:

screen -ls

The output you’ll see will be something along the lines of:

[jorge@cat ~]$ screen -ls
There is a screen on:
    26606.pts-39.cat    (Detached)
1 Socket in /var/run/screen/S-jorge.

To reattach the screen session to your current terminal, you can use screen -dr . In this case it would be:

screen -dr 26606

This brings up an interesting question though. How can you differentiate what multiple screen sessions are holding, if you can only read the process number? Easy – you give each screen session a name. For most people, a name is easier to remember than a number. So, we start a new screen, in which we’re going to open an IRC client called irssi. Let’s use -S:

screen -S irc irssi

Entering irssi, we detach the session with Ctrl-a d, and do a screen -ls to see what we’ve got now:

[jorge@cat ~]$ screen -ls
There are screens on:
    26606.pts-39.cat    (Detached)
    26702.irc    (Detached)
2 Sockets in /var/run/screen/S-jorge.

There you clearly see the name irc that we entered earlier, and the session holding top, which we started up even before being able to specify a name. Pretty handy, huh? This is particularly hand if you’re only going to have one application in the screen session. If more, it would probably be better to have a more descriptive session name of some sort.

Sharing a screen

If someone else, or you, has created a screen, and would like to share with someone else what you’re doing, then screen -x does the trick. Simply use:

screen -x irc

..if irc is the name of the session, or the process ID. Once done, you should have enabled multi display mode. And if you find out that the screen you have taken part of doesn’t match up to the size of your own terminal, simply use:

Ctrl-a F (^a F)

..to force it to match up to the dimensions.

Multiple applications in one session

Now I’ve introduced you to the basics of using screen. Let’s proceed onto using screen with multiple applications. Detach and resume the screen session called irc with:

screen -dr irc

Once resumed, press Ctrl-a Ctrl-c (^a ^c) to create a new screen session from within your current one. This will start up a new shell. Let’s start a new application – nano. Simply type:

nano

And the application will start. Let’s give this internal screen session a name. Press Ctrl-a Shift-a (^a A). Notice that a is different from A (capital A).

You will be asked:

Set window's title to:

Type editor and press enter.

You can switch between the various applications by pressing Ctrl-a 0-9, so:

Ctrl-a 0

will go to the first application, irssi in this case. Other ways of navigating is by using

Ctrl-c Ctrl-n (next window)
Ctrl-c Ctrl-p (previous window)

To list up all of the shells available on the screen, type:

Ctrl-a " (^a ")

You’ll get a list that looks something like:

Num Name                                                                   Flags
 
  0 irssi                                                                      $
  1 nano                                                                       $

Use your Up/Down arrows and press enter to select a shell to go to.

Clearing destroyed sessions

If you have a screen session up, and the machine it is on goes down, then the screen session is probably destroyed. You can see the available screens by typing screen -ls. To get rid of destroyed screens, type:

screen -wipe

Splitting windows

Another interesting thing many people have asked about is how you can split a window in a screen session. A useful feature if you say would like to have two documents open, or you have to do some work while having a conversation on IRC. To split the window, type:

Ctrl-a Shift-s (^a S)

You will see that your screen is now split, and you have a new area on the bottom. To move to this area, type:

Ctrl-a TAB (^a TAB)

Now that you’re in the new area, there’s not much to do but to create another shell, so do it with:

Ctrl-a Ctrl-c (^a ^c)

From here you can start another application in the regular way, and give the internal shell a name of its own.

If you want to close the application in the bottom area, do it as normal, then to kill the area, press:

Ctrl-a Shift-x (^a X)

If you want to kill every area EXCEPT then one you’re currently in, you can use:

Ctrl-a Shift-q (^a Q)

And that’s pretty much it when it comes to screen. For more information, check out the command:

man screen

Good luck!

September 16, 2010

Rapidshare Linux Script Revisited

Filed under: Linux — Tags: , , , , , , , , , — jorge @ 12:53

Update: I just added a new variable in the script, DAYS, which specifies how many days the cookie you create is valid for.
Update 2011-09-13: Seems Rapidshare have been tampering with their API, which made the cookie-generating script useless. I basically changed the getaccountdetails_v1 with getaccountdetails, and the script is working fine now. I’ve fixed the script below to reflect this.

The code to get the Rapidshare-cookie in my previous post about this subject, Rapidshare Linux Script, unfortunately doesn’t work anymore. It seems that Rapidshare has moved from using https://ssl.rapidshare.com/premzone.html to https://ssl.rapidshare.com/cgi-bin/premiumzone.cgi, so things just don’t work as they used to. This is for people with a premium account.

However, there’s a solution. First off, log in to your Rapidshare-account, go to Settings and make sure to check the box named Direct downloads, requested files are saved without redirection via RapidShare.

To grab the cookie you need, place the piece of code below in a file, save it, do a chmod +x on it. Just remember to replace MyUserName and MyPassword with your username and password before you run the script:

Note: The script requires curl to be installed.

#!/bin/bash
# Script to get your Rapidshare-cookie, nom nom
# Jorge Enrique Barrera
 
# Variables you can change
USERNAME="MyUserName" # Username to your Rapidshare premium-account
PASSWORD="MyPassword" # Password
COOKIEJAR="/home/jorge/.cookies" # Where the cookies are to be placed
DAYS="30" # The number of days the cookie is valid for
 
 
## Do not change anything below here ##
 
DATA="sub=getaccountdetails&withcookie=1&type=prem&login=$USERNAME&password=$PASSWORD"
COOKIE_STRING=$(curl -s --data "$DATA" "https://api.rapidshare.com/cgi-bin/rsapi.cgi" | grep cookie | cut -c 8-)
COOKIE=".rapidshare.com TRUE / FALSE $(($(date +%s)+24*60*60*$DAYS)) enc $COOKIE_STRING"
 
if [ ! -d $COOKIEJAR ]; then
        echo "Creating the directory $COOKIEJAR."
        mkdir $COOKIEJAR
        echo "Done."
fi
 
echo "$COOKIE" | tr ' ' '\t' > $COOKIEJAR/rapidshare

Now that the cookie is present, you can proceed by downloading the files you want. Which way you do that, is up to you.

Either way I will paste two scripts, one with wget and the other one with aria2, and you can then make your pick. Just place the URL of the files you want to download in /home/jorge/Downloads/.url, one in each line:

wget

#!/bin/bash
LIST="/home/jorge/Downloads/.url"
cd ~/Downloads
for url in `cat $LIST`
do
    wget -c --load-cookies /home/jorge/.cookies/rapidshare $url
done

Save this file as wrsd.sh and make it executable by doing a:

$ chmod +x wrsd.sh

aria2

#!/bin/bash
cd ~/Downloads
aria2c -j 5 -c --load-cookies=/home/jorge/.cookies/rapidshare -i /home/jorge/Downloads/.url

Enjoy. :)

September 8, 2010

Spotify for Linux rpm

Filed under: Linux — Tags: , , , , — jorge @ 11:00

I’ve taken the liberty of converting the “Spotify for Linux”-files located at http://www.spotify.com/no/download/previews/ from .deb to .rpm. For now it can only be used if you have a Premium account.

To install it on Fedora 13, do the following:

su -
rpm --nodeps -Uvh http://jorge.fbarr.net/files/spotify-client-gnome-support.noarch.rpm http://jorge.fbarr.net/files/spotify-client-qt.i386.rpm

And that’s it. Now you can run Spotify as a Linux-application instead of through Wine. :)

Older Posts »

Powered by WordPress