Category Archives: Linux

Introducing download-sweeper

One of the biggest issues on any system of mine is the cluttering of the Downloads folder. In the modern Internet age, we download a ton of files. Checking right now, the contents of my Downloads folder sum to about 15GB in filesize. Although that probably isn’t too much of an issue given the cheapness of storage today, it remains troublesome when hand-searching through the files.

When I only ran Windows, I used Cyber-D’s Autodelete to delete my old downloads. This worked perfectly for me, except for the fact that sometimes it would delete files that I forgot that I wanted. But with Windows, I could always find those files in the recycle bin.

Fast forward several years, and I now run Linux as my primary operating system. Without doing much research to see if a program already existed, I drafted a “spec” for download-sweeper, a program that would delete old files in the Downloads directory, but also allow the user a “grace period” where they could still recover old Download files if they were removed.

Sure, this could probably be created in less than 100 lines of C, but I was looking to create a robust and portable solution that would allow me to quickly make changes if I needed to. Thus, I created a clean (~350 lines) Python solution that would do just that.

Further, when integrated with systemd, everything works perfectly. I currently have the application deployed on my Laptop, my Desktop, and on the webserver that’s running this blog. Of course, there aren’t any downloads on the webserver, so I use it to act as a “virus/malware quarantining tool”.

You can view the project on its GitHub page, here: https://github.com/brandonio21/download-sweeper

Ditch SLiM, Replace it with SDDM

My laptop, which usually boasts a twelve hour battery life, was reporting that it would only last for a few hours on a fresh charge. Something was obviously wrong. Checking the output of htop, it became clear that journald was the culprit.

It seemed that journald was simply writing log messages over and over and over again, and running journalctl -xe revealed the culprit. I recently updated my system, which included new updates to Xrandr and many other packages. SLiM, my beloved simple and clean display manager, was no longer compatible.

Consulting the ArchWiki page for SLiM, it is made immediately clear that the display manager has been out of service for some time. Thus, in order to save battery life and keep my system up-to-date, I have chosen to replace it with SDDM. The transition is clean, simple, and SDDM is just as nice, so I urge anyone still using SLiM to do the same.

All that needs to be done is a SLiM disable, a SLiM uninstall, a SDDM install, a SDDM theming, and an SDDM enable, not necessarily in that order. Here is the raw list of commands:

sudo pacman -S sddm
sddm --example-config | sudo tee /etc/sddm.conf
sudo systemctl disable slim
sudo systemctl enable sddm
sudo systemctl stop slim
# You should now be logged out of your XSession. Log in to the tty and do the following:
sudo pacman -R slim
sudo systemctl start sddm

Everything should now be good! Of course, if you’d like to make your SDDM pretty, you’ll have to change the theme (There are two ArchLinux based themes in the AUR)

There are some caveats, however. For one, I was a heavy user of slimlock. Obviously, this is not available with SDDM. I remedied the situation by switching to i3lock.

Fixing ncurses5 to ncurses6 Dependency Issues on Arch Linux

This post is alternatively titled: “How to resolve error while loading shared libraries: libncursesw.so.5: cannot open shared object file: No such file or directory”.

While attempting to do a recent system update, I ran into two problems:

  1. pacman was not downloading any packages due to an out-of-date gnupg package.
  2. Trying to install the gnupg package manually resulted in the alternative title of this post.

All of this was because I decided to run sudo pacman -S libncurses in order to get my conky working properly. Turns out a lot more programs rely on libncurses than I previously realized.

The problem gave me more of a headache than thought it would, but I eventually solved the issue. Here’s how:

  1. Since I recently upgraded libncurses through pacman from version 5 to version 6, the old version was still saved in the cache in /var/cache/pacman/pkg
  2. I extracted the cached version of libncurses by using sudo mkdir tempNcurses && sudo tar -xvf ncurses-5.9-7-x86_64.pkg.tar.xz -C tempNcurses
  3. I then copied the resulting binary into the libraries folder with sudo cp tempNcurses/libncursesw.so.5.9 /usr/lib
  4. I then made a symbolic link with the file specified in the error messages with sudo ln -s /usr/lib/libncursesw.so.5.9 /usr/lib/libncursesw.so.5

After this, everything worked as expected! I was able to manually update GnuPG and then update everything else that had a dependence on ncurses

Building a Volume Popup using Dzen2

If you have been following my blog at all lately, you’ll know that I’ve been pretty obsessed with my brand new ASUS ux305. After browsing /r/unixporn for days without doing anything, I decided to take a stand against my bland i3 setup and get things rolling. One of the things that has always bothered me about my Linux machines is the fact that a lot of the hardware keys don’t work because I am too lazy to make them work.

This was changing. Now.

So far, for my volume keys, I had them hooked up to a small BASH script which called on alsamixer to raise or lower the volume by 5%. My volume level is also continuously displayed in a conky panel at the bottom of my screen; however, the conky panel only updates every second, and sometimes this second is a little too slow when the volume button is being pressed in rapid succession. Thus, I needed something to alert me in realtime when I was changing the volume.

The main thing I was interested in was making something like GNOME or OSX have – something that pops up and alerts you of the volume (Preferably without an annoying popping noise). Something like this:

volumetrickformacIn order to do so, I needed to find a tool that would display something on the screen. Some sort of notification/message platform that was extremely lightweight. I have heard of some of my friends using dzen2 to power their panels, so I decided to look into that. It was the perfect solution. Basically, now every time I call my volume changing scripts, I can display the current volume level in some sort of alert.

First, I had to create an alert script that would make my alert designs a little more portable and easily customizable. I went with something that allowed me to create alerts in both the middle and the top of the screen and with colors that matched my status bar. The result was this mess:

#!/bin/bash 
                                                                   WIDTH=300                                                                       
HEIGHT=50                                                                       
                                                                                
# This script shows an alert using dzen                                         
screenWidth=$(xdpyinfo | grep 'dimensions' | egrep -o "[0-9]+x[0-9]+ pixels" | sed "s/x.*//")
screenHeight=$(xdpyinfo | grep 'dimensions' | egrep -o "[0-9]+x[0-9]+ pixels" | egrep -o "x[0-9]*" | sed "s/x//")
let "middleY = $screenHeight / 2 - ($HEIGHT/2)"                                 
let "middleX = $screenWidth / 2 - ($WIDTH/2)"                                   
                                                                                
if [ "${2}" == "top" ]; then                                                    
        echo $1 | dzen2 -fn "DejaVu Sans Mono 8" -p $3 -h $HEIGHT               
else                                                                            
        echo $1 | dzen2 -fn "DejaVu Sans Mono 8" -p $3 -y $middleY -x $middleX -h $HEIGHT -w $WIDTH &
fi

Basically, this script takes 3 arguments – The message, the position, and the wait time. This is all of the information I am going to need to ever specify for my popups. Now all that is left is to get the volume buttons working with the script. My volume buttons are already linked to two scripts via my i3 config file, mainly the two lines:

bindsym XF86AudioRaiseVolume exec $HOME/.i3/bin/raiseVolume.sh
bindsym XF86AudioLowerVolume exec $HOME/.i3/bin/lowerVolume.sh

The final step is simply creating the lowerVolume.sh and raiseVolume.sh scripts. They are simple, now. They basically call amixer to handle the volume control, save the output, and display it in an alert. Here’s the code to lowerVolume.sh

#!/bin/bash                                                                     
                                                                                
volume=$(amixer -c 1 set Master 5%- | egrep -o "[0-9]+%")                       
`$HOME/.i3/bin/showAlert.sh "Volume: $volume" middle 1`                         

Note that this uses our alert script to display a message in the middle of the screen for 1 second. It’s perfect. The raiseVolume.sh script is exactly the same, but there is a “5%+” instead of a “5%-“.

The end result is beautiful.

rsz_2015-04-16-224403_1920x1080_scrot

This alert system will soon be implemented into the script I use to detect new emails and brightness keys, once I get them working.

Late Night Ramblings About the UX305

As I lie in bed messing around with my ux305, there are a few things that I have noticed that are driving me a little crazy. Since I am too tired to formulate my thoughts in a formal way, I shall simply use bullets to express them.

  • There seems to be a fair amount of light-bleed coming from the right side and the bottom of this laptop’s gorgeous screen. If I press on the bezel of either of these sides, I notice that the lightbleed grows towards the center of the screen. This does not happen on the left or the top and I don’t have much experience with lightbleed, so I don’t know how bad or normal this actually is.
  • Binding the brightness keys has proven to be a challenge in Arch Linux. Running `xev`, I have determined that the keys assigned XF86MonBrightnessUp and XF86MonBrightnessDown are actually the keys located to the left of the brightness keys (The keys without any indication of what they are.. the blank keys). This is truly problematic and I will look into a solution. As far as my knowledge goes, this is a Linux problem.

Anyway, I digress.