Archive for the ‘get productive’ Category

Productivity: Setting Up at in Crunchbang

July 27, 2009

I needed to set up something to start at a time certain last night in what used to be crunchbang (considering I replaced over half the stuff in the default base, it’s not so much crunchbang anymore). That means using the at command; cron is a great tool for things that need to repeat on a schedule, but at is the tool to use for “one shot” events.

I entered “at 22:00” and wasn’t too surprised it threw out an error when I hit return. I looked in /etc and saw there was only the at.deny file but no at.allow. So I quickly added my username to at.allow. Then running at again showed that a certain file didn’t exist. Again, no big surprise — I openly admit a bias against Ubuntu because it uses shitty graphical utilities rather than setting up standard tools. So my next step was to setting up (touch) the file .SEQ in /var/spool/cron/atjobs.

% sudo su
root@pluto:/etc# cd /var/spool/cron/atjobs/
root@pluto:/var/spool/cron/atjobs/# touch .SEQ
root@pluto:/var/spool/cron/atjobs# ls -al
total 8
drwxrwx--T 2 daemon daemon 4096 2009-07-26 21:27 .
drwxr-xr-x 5 root   root   4096 2009-06-30 05:53 ..
-rw-r--r-- 1 root   root      0 2009-07-26 21:27 .SEQ

Uh oh, that won’t friggin’ work — it’ll result in denial of permission (unless you run as root, which isn’t necessary):

% at 21:30
warning: commands will be executed using /bin/sh
Cannot open lockfile /var/spool/cron/atjobs/.SEQ: Permission denied

The file needs daemon-daemon ownership. This is very easy to fix. See how easy it is, boys and girls?

root@pluto:/var/spool/cron/atjobs# chown daemon.daemon .SEQ
root@pluto:/var/spool/cron/atjobs# ls -al
total 8
drwxrwx--T 2 daemon daemon 4096 2009-07-26 21:27 .
drwxr-xr-x 5 root   root   4096 2009-06-30 05:53 ..
-rw-r--r-- 1 daemon daemon    0 2009-07-26 21:27 .SEQ
root@pluto:/var/spool/cron/atjobs# exit

Once I had that set up, I could test it to play a file (I wrote this Sunday night).

% at 21:30
warning: commands will be executed using /bin/sh
at> ogg123 ~/audio/fuckinaye.ogg<EOT>
job 2 at Sun Jul 26 21:30:00 2009

The EOT at the end of fuckinaye.ogg is just ctrl-d (remember that from when mail was a true commandline program?). At 9:30pm, I heard the test ogg file.

Now with it properly set up, I can use it to launch individual tasks when I need them and I don’t have to run X to do it from some stupid box with dials and buttons.

Setting Up emacs And Other Open Source Applications in Windows

June 20, 2009

One of my grievances against the mouth-foaming Linux advocates who get crazy doe-eyed about how much free software is available via repository packages is that nearly all that same software is also available for use in Windows. That means one really needn’t change operating systems to take advantage of open source software. I think people who are already comfortable using Windows and have valid licenses shouldn’t change — certainly not so they can use software already available to them.

I run a lot of the same software across platforms because I find it convenient to be able to share data regardless of which operating system I may be using at any given moment (which is important because I use XP primarily on my Aspire One and have no plans to stop using it until I can get Linux working at the same level and with the same stability). I have GIMP,, Sylpheed, Firefox, PuTTY, Filezilla, Audacity, emacs, and a lot more free and open source software running under XP on my Aspire One. And it’s not just these kinds of desktop applications that are available. Windows users can take advantage of server software like Apache and all the usual languages — PHP, Ruby, Lua, python, Perl, etc. — to use on their servers. There are only a handful of open source desktop and server applications that won’t run on Windows or that don’t offer a Windows binary of some sort.

As easy as it is to install these things in Windows, sometimes things are a little easier to find and/or use in one operating system compared to others. For example, Windows’ filesystems and applications don’t like starting file names with a period; Unix-like operating systems, though, use period-starting names to hide files and directories. That’s not to say you can’t have a dot-file on a Windows system. By convention, applications with a Unix-like focus can use a file or directory started with an underscore rather than a dot (e. g., _emacs in Windows is like .emacs in Linux). These differences can make things a little more complicated depending where you’re most comfortable.

Another thing that needs to be addressed is where various directories and files are located. The standard file hierarchies of Windows and Unix-like systems are similar in layout but different with respect to naming conventions. Where Linux and BSD have /home/$USER for each USER’s own files, Windows uses “My Documents” for each user.

Many open source applications put their configuration files in the directory preceding “My Documents.” This directory is usually found at “C://Documents and Settings/user name” which can be accessed by hitting the  up-directory arrow from “My Documents” or sequentially in the path above starting at “My Computer.” Some applications put configuration data in a hidden directory at this level called “Application Data.”

Windows uses a different convention to hide directories and files (accessible via Properties). You can choose Tools-Options-View in the file browser to toggle whether or not to show hidden files and directories. Or you can navigate to whatever file (e. g., .emacs) by opening a file (C-x C-f) and editing the path (tab completion works) to the file; emacs can reach “hidden” files and directories under Windows without altering settings mentioned above in the file browser. You can also name or rename your files with a dot from within emacs despite Windows’ preferences.

(The Windows naming convention is tied to legacy 8.3 naming conventions in which the dot is a demarcation between file name and file type.)

All of this is important because applications like emacs can be personalized very heavily via their configuration files. Sometimes these files need to be interacted with via interface menus available in the applications themselves. Sometimes they need to be edited manually. The latter is true of the .emacs file, which is a LISP file. (Another myth to shoot down: not all open source applications are configured via text file so YMMV. They can be anything from XML to interpreted languages to binary.)

The location of the .emacs/_emacs file can vary depending how emacs was installed.  The easiest way to find it is to use emacs itself to show the path it’s using for environmental variables. To do this, you can use the emacs LISP interpreter within the scratch buffer.


The next step is to execute the command using C-x C-e. You’ll get the path where your .emacs.d directory is stored along with where your .emacs should be.


Once you know where your .emacs is, you can set it up as you need. While emacs already has some built-in associations, you can either add new ones or alter existing ones. One of my favorite tools in emacs, org-mode, requires some set up in .emacs (see the org-mode documentation). It’s kind of awkward that something is bundled in emacs but you have to tell emacs that your .org files need to be opened in org-mode when other filetypes (html) are opened with an appropriate mode.


Things work better when you set up your .emacs to handle file types the way you want. Rather than opening a .org file as a standard text file, for example, it can be opened so that it’s in org-mode. Your .emacs also controls other modes and tools within emacs, including e-mail and news as well as just about anything you want to do with it (emacs is a kitchen sink).


There are many guides to setting up .emacs and other open source application configuration files online. The more you know, the better you can make software work for you.

More GNU screen Tweaks

October 7, 2008

I had a little time yesterday afternoon at lunch and last night while watching MNF to work on a few things I’ve had on the back burner. In a nutshell, I’ve wanted to further tie things together in screen with some kind of menuing. GNU screen allows users to set up keybindings to launch new apps in addition to using an escape sequence (ctrl-a : [command]) to launch things.

I wanted to go a step further because I wanted “dynamic” menus that can be easily edited and customized as well as menus that are more oriented towards data than applications. The former is easy enough: just implement a script and modify it as needed. The latter can be as simple or complex as desired. I’m practical, so I went the simple route.

Let me qualify this by saying I know it’s not fancy, it lacks eye candy, and that there are plenty of ways to skin this cat. I’ll also admit my primary impetus for this was a desire to get my streaming audio (pls files) in a list from which I could choose for streaming (and streamripping) without typing “mplayer -playlist path/to/streams/type[tab]” etc. — not the highest priority in my life, but something I’ve wanted for a while. I didn’t want to bother with setting up databases, I didn’t want some WHILE bullshit polling the system to scan for any new files to add to the database, and I wanted to stick with shell scripts without getting into window dressing like dialog. Just get a quick list of what’s available when I select a menu entry and play it in a new screen pseudo-terminal. Easy, no nonsense, little drain on system resources, fast, efficient. In other words, screw amarok and whatever is gnome’s bloat-du-jour.

I wrote a main menu for screen that solves the first issue. I can fill it to my heart’s content with custom commands (it’s sparse now) and use it to call other menus (as I’ve done temporarily until I finish my multimedia script which is now in separate pieces). Note that this was written ksh-specific and may need adjustments in bash or other shells.


# - Mon Oct  6 21:36:57 CDT 2008

# menu for running apps in screen
# also calls other scripts from $HOME/bin

print 'select application to open '
PS3='app: '

select application in \
	'snownews' \
	'gmail' \
	'mc' \
	'aim' \
	'pork' \
	'epic4' \
	'calcurse' \
	'podcasts' \
	'streams' \


case $REPLY in
 	 1 ) RUN_THIS="snownews -u" ;;
 	 2 ) RUN_THIS="elinks" ;;
 	 3 ) RUN_THIS="mc" ;;
 	 4 ) RUN_THIS="naim" ;;
 	 5 ) RUN_THIS="pork" ;;
 	 6 ) RUN_THIS="epic" ;;
 	 7 ) RUN_THIS="calcurse" ;;
 	 8 ) RUN_THIS="$HOME/bin/" ;;
 	 9 ) RUN_THIS="$HOME/bin/" ;;
	10 ) RUN_THIS="$HOME/bin/" ;;

if [[ -n $application ]]; then
	screen -t $application $RUN_THIS
else print "invalid response... try again"


This gives me my basic menu and frees keybindings in my .screenrc (which has gotten a little meiotic lately and difficult to remember sometimes without hitting “ctrl-a ?” for help; or typing “alias” periodically to remember all my little shortcuts). The menu is bound to one of the keybindings freed up (ctrl-a e) so it can be launched at will, and it terminates when the new terminal opens with the selection (which means I don’t have a ton of stuff to close and check and everything). The launched instances also tidy themselves up when finished, making “window” management in screen more automatic. In short, it acts a little bit more like a window manager than a terminal multiplexer. Kind of.

My original goal of being able to reduce work/typing to play audio was benefited by my organization of directories, but it’s flexible enough that it can be adapted to less organized files. I try to keep files of the same type in one nested directory. So, as you can see in the next script, my audio is all in one directory and broken down according to podcasts, streams, and songs by genre and artist. Well, you can’t see all that in this particular script. What you can see is that I just had to define one directory and search it for the relevant files. That allows SELECT to format the results in columns of the individual stream files rather than in one column with full paths, allowing more to show up on one page. If you only have a few files, no problem. I have over 40 (and I haven’t copied over the other ones from my other hard drive or backups yet).


# - Mon Oct  6 13:30:46 CDT 2008  

# this script is ksh-oriented but may work for other shells
# and can be linked to a keybinding in screen to open a menu.


print 'Select stream to play: '
PS3='stream? '
select STREAMFILE in $(ls $STREAMDIR | grep -i pls | sort); do
	if [[ -n $STREAMFILE  ]]; then
		mplayer -playlist $STREAMDIR$STREAMFILE
		print '*** invalid, try again...'


Note that I don’t open this one in yet another screen pseudo-terminal but leave it in the one in which it opens. I initially did but some things open too fast or too slow and the screen numbering order would get wonky.

As I wrote above, I’m probably going to aggregate my multimedia scripts into one script at some point. I wanted to see how many keybindings I would need to do each thing separately. Answer: way too many.

NOTE: This post may be edited for formatting later. I’ll also try to add some screenshots to it later today.

EDITED – Thu Oct 16 2008: corrected part of the if loop in the script for the screenmenu above. I now have more entries in mine and have added additional menus for various things to further customize my system. Additionally, I’ve rebound the w key in screen (ctrl-a w) to open the navigable list of terminals in screen (which is bound by default to ctrl-a “). This still allows for use of ctrl-a-ctrl-w for the same thing the default binding of ctrl-a-w does while making it a little easier to navigate through terminals.


made with: VIM - Vi IMproved 7.2 (2008 Aug 9, compiled Oct  5 2008 12:03:46)
and the vimpress plugin

OpenBSD 4.3 GENERIC#0 i386

Productivity Tip: Increase Integration in the Software You Use

August 8, 2008

One of the ways to make console apps more GNU screen-friendly is to set them up so they spawn other things within the same instance of screen.

I use snownews to read through rss feeds, and use elinks as my default browser (with snownews, in screen, and outside of screen). Where I’ve been slowed down a bit is while downloading podcasts I keep track of in snownews. Since I was launching elinks in the same terminal or terminal instance, I could either wait for a download to finish or open another instance of snownews.

I finally got around to setting up my browser in snownews so that instead of:

elinks %s

it’s now:

screen -t elinks elinks %s

The -t option is for the title (the first elinks) which will either appear on ctrl-a w or on your status bar if you run one permanently. The second will open elinks in that terminal instance (you can use any browser you want for this; graphical browsers will still open a screen window and open the graphical instance as well). And the %s is the signal for whichever file or page to open in the browser.

Now when I open a link in snownews, it opens in a distinct elinks instance so I can toggle back (ctrl-a a) to snownews while a podcast or another file downloads or whatever. I set up my screenrc to give me an alarm when there’s activity in any terminal instance in screen, so I can close a window when a file has finished downloading. My one instance and session of snownews isn’t interrupted by waiting for anything to download, and closing the window for an article takes me right back where I left off.

Other programs can be set up similarly if you primarily run them in screen. For example, you could edit your mc MIME/file associations so the same thing occurs when opening music files with a non-graphical program (which I do because the music pretty much sounds the same regardless of XMMS or mplayer or mpg321 without clogging as much RAM with some wild-skinned front end). Just follow the conventions for whichever program you’re using.

I’ve also mentioned vifm in this blog and noted it’s seamless integration into screen. While not as feature-packed as mc, it’s still very useful if you know vi commands and can make the associations between “vi-thinking” and file management. It makes working in screen even easier because the user can set it to open separate instances in screen with “:screen”. I mention vifm again because I don’t think I’ve written that it’s been updated since I wrote about using it in screen.

I know there are others who’ll recommend using desktop environments that share resources even better than the kinds of arrangements I use. As much as I like KDE, it’s not nimble enough for my tastes — at least not on my hardware. It’s made for those of you with faster hardware (and masochists who insist on eyecandy and integrated environments more like Windows whether their hardware is capable of it or not), not those of us bent on actually using computers to simplify our lives and get more stuff done.

Productivity Tips : cron, at, scripting

June 23, 2008

I originally was going to do this in separate posts, but with my schedule getting crazier, I decided to combine a couple things into one post.

Every user should learn how to use cron and at. These are daemons that automate tasks; the main difference between them being that cron is used for repeating events while at is better suited for executing individual tasks (and in situations where timing of execution isn’t of importance). These are not just tools found in Linux and the BSDs, though some Linux advocates pretend that it’s a selling point for Linux. Windows, too, has schedulers to automate the running of tasks; if you’re running anti-virus software, it should probably be set up to run automatically instead of when you feel like it.

What can be automated via cron and at? Everything you do. I use cron as my alarm clock, to clean up old files, to make back ups, to download news and aggregate it for me so I have one file to look at in the morning (with links I can check later), to download podcasts, to rename files, to update software (I keep vim patched weekly via cron), etc. Whatever you do with any repetition can be automated. This can be directly or via scripts. Most of my crontab consists of execution of scripts, some of which execute other scripts (“nested”). Some things, like my alarm, are specific individual commands.

The second part of this post is about how learning to write scripts helps make life easier. This goes hand in hand with using cron, but scripts can also be used any time to make complex (or even a series of easy) tasks easier to manage. Scripts can be written in any language: BASH is probably the most utilitarian because it’s the prevalent default shell in Linux. Other languages are also suitable. These include python, lua, ruby, Perl, guile (and other scheme/LISP-oriented languages), tcl, and so on. Each language has its own syntax and nuances so it pays to find something that appeals to your tastes and your way of thinking. My own tastes fall somewhere between scheme (notice I use a lot of parentheses? it’s so natural for me) and ruby. You may find Perl or BASH more to your liking and more convenient since they both are found on Linux systems. The important thing is learning to use a language, not advocating the superiority of one or another. Each language has its place, its adherents, and its own set of pluses and minuses.

Below is an example of a script I use to download content via cron. It’s a very short, simple ruby script. This is a very easy one because the content on this site doesn’t change names — it uses a suffix of _current.mp3 for all the latest versions. I use a simple array of the names of the podcasts I want and then run them through a loop so wget executes for each one. Total of seven lines, two of which are empty. This runs in middle of the night once a week. I use similar scripts to download other content on more and less frequent bases.

I use another cron job to clean these up so I don’t overwrite them in the event I don’t get a chance to listen to them. After a few days, it will execute and change their names from _current.mp3 to -YYWW.mp3 (two digit year and week number of the year). Then I can choose what to keep without worrying about things getting overwritten.

The result is no-hassle downloading and management of things I want; this means I don’t have to fire up a browser and sit there and click on links to get anything. The same goes for updating software by setting up cron jobs to check for updates (via CVS or SVN or GIT) and take care of things for you. It can be as elaborate as simple as your needs are, not to mention that it’s not really above your skill level because you don’t have to get too carried away to benefit. Fortunately, many projects exist to make it even easier for you by providing scripts that can be run from cron (such as bashpodder). There are many of these across the Internet so you can get ideas how to do what you need to do if any of them doesn’t already suit your needs.

So with two relatively simple things — tools like cron and at, a little exposure to scripting — you can automate tasks to make your life easier. And with your computer doing all the work, you’re more productive.

Productivity Tip 2: Calendar Apps

June 4, 2008

I don’t use calendar apps because I’m punctual and attentive about things like scheduling. I use them because no matter how punctual and attentive I try to be about schedules, I’m really not. Without them, I’d do a worse job prioritizing events and let things conflict more often than not. At least that’s what I think.

I used to be a fan of Sunbird and Lightning from Mozilla. Sunbird is their standalone version and Lightning integrates into Thunderbird. These are fine if you have a fast processor and lots of RAM. They’re dreadfully slow if you don’t.

Instead, I’ve become a very big fan of calcurse. This is a three-pane console app that handles just about everything you need from a scheduling application. In the default main panel is the daily calendar. On the right side are two more panes. On top is a navigable monthly calendar which is used for navigating to the day that shows up in the main panel. Beneath the monthly calendar is a to do list.

By default, the navigable monthly window is active. It can be toggled with a tab or you can use a keybinding to set tasks in the other two panes — ctrl-a to add an event to a daily calender or ctrl-t to add to the to do list. Users of screen will see an immediate problem with using the default binding: ctrl-a is the preceding escape used in screen. So I use tab.

Setting events is very straightforward. The entry area is hinted so users can enter start and end times, events, priority (on to do entries), etc. Commands are also hinted in a fashion of pine/pico across the bottom part of the terminal.

Its power doesn’t end with keeping events straight. You can use multiple calendars with the -c filename flag (it will use its default if you don’t use -c). You can export your calendar to an ICS calendar file that anyone with just about any other mail application or web-based calendar can import (I have a cron job that does this every week and I use an alias to pipe it to a file as needed) by using the -x option and piping it to filename.ics — e.g.,
% calcurse -x > lucky13.ics

It can also be used to print out notes, the to do list, or any particular day’s events. See the documentation page on the calcurse link above for examples.

Okay, you say, but what about other programs like remind and wyrd?

Those are also certainly very nice. The reason I prefer calcurse is because it doesn’t have any unusual requirements (like ocaml), because it’s very easy to use (the hints are right there in front of you if you forget what you’re doing), and I think it’s every bit as flexible as anything else out there. If not more so.

And why is it better than Sunbird? It loads immediately. I can export a calendar in a fraction of a second even on an older computer. I can generate my to do list and either print it out in a terminal, pipe it to a file, or “:r! calcurse -t” (or -d) inside vim and include it in a note or report without having to do or open anything else.

Anything that helps you schedule your life shouldn’t take up an extraordinary amount of time. Not to compile, not to start, not to use, and not to quickly get information out of it. Of all the calendaring applications I’ve tried, calcurse lets me get things done most quickly.

Productivity Tip 1: Uh, This Isn’t Productive

May 4, 2008

Following my discussion with Nathan of the Productive Linux Podcast, I’ve decided to start a category for productivity shortcuts and tips.

Today’s tip: how to change a GTK theme quickly without a switcher.

Now, this isn’t exactly my idea of productivity because this is about how things look, not how things get done. This is just about how to change it quickly without compiling or installing anything so you can get it over with and do something more useful and productive with your computer. Because this isn’t something that requires some fancy interface to accomplish.

Your gtk theme information is read from a configuration file located in your home directory — usually separate ones for gtk1 (such as .gtkrc) and gtk2 (such as.gtkrc-2.0). These files are often pointers to a system or local gtkrc via an include statement with a path to a gtk theme directory and its gtkrc, i.e.,

include “/home/username/themes/NameOfLocalTheme/gtkrc”

Suppose you just cannot survive using a gaudy default gtk theme and you download one that you find more, ummm, productive. You should install it in a directory called “themes” in your home directory. Then you can manually edit the .gtkrc(-2.0) path so it reads from the directory where your new theme is. So if you download a theme tarball called clearlooks-productive.tar.gz and decompress it in ~/themes, your gtkrc would only need to be edited like this:

include “/home/username/themes/clearlooks-productive/gtkrc”

Of course, that’s not going to allow you to waste hours switching between different themes and show you how your apps look in them — as if the screenshots at whatever site you download your themes from don’t lend you guidance about how they look. That’s not my problem, I’m just trying to help people be more productive. Besides, how many themes do you need to be productive? And if it’s a fairly small number and you have only one file to edit to point to the one you want to use, why do you need “switchers” anyway?

Coming soon: more tips about applications, utilities, and other things that will actually help you get more stuff done with less effort.