sudo apt-get install units

or equiviliant for other distributions. Then type in the word “units” and play around. Here are a few sample outputs:

The program is a little clunky. You have to know the specific codes for each type of measurement, though ‘units’ will figure out what you mean sometimes. To exit, type ctrl-D. There is a way to use this utility in a script. That and other details are found in the manual.

But I find that to be a bit of a pain, typing in the dates to start and end the list, when I generally want a quick and dirty “next several days.” That, I suppose, is why there is a default of five days. But five days is not a good default. If it is Wednesday, I want to see what I’ve got on my calendar for the rest of the current week, as well as what is on my calendar for ALL of next week. For me, a better default would be 14 days. With 14 days, you always get a full look at the present week and the next week, plus, sometimes, a bit after that.

One can imagine writing a bash script that figures out what day it is, and then adds enough days that you get an agenda for the remainder of the present week plus all of the next week, but no more days than that. Such a script could make use of bash’s ability to manage and manipulate dates as they occur in our periodic system, with 24 hours in a day, 7 days in a week, work days being a subset of five of those days, etc. etc.

One could also imagine writing a bash script to poke one’s eyes out with hot soldering irons.

A simpler solution is this:

Pick a number of days that you like, and add that to the current day, and use those two parameters to invoke the agenda command, and put all that in a script. The problem with this is still figuring out the second day. How do you add, say, 14 days to the present day? If the date utility in bash gives us something like 10/19/10, how do you add 14 to that? 19 plus 14 is 33. There is no day 33. So you’d have to increment the month. So the month would become 11. One could use a modulo function if available, but some months are 30 days long, some 31 days long, and one is sometimes 28 days long but sometimes 29 days long. And then, what if you wanted fourteen days starting on December 20th? Then, the month goes back to 1, and the year is incremented. Holy crap!

Software like spreadsheets and other financial applications do date math. It is interesting to note that such applications didn’t originally do date math, and when they first did it, they did it poorly, and for years (and as far as I know this is ongoing) major screw ups in spreadsheet code often have to do with date math. Date math, as a matter of fact, is the bane of computers and those who work with them. (Remember the year 2000 fiasco?)

But there is a way to do this easily, and this is in fact the way that most date math is probably done at some level in spreadsheets and other apps. Convert everything into the number of seconds since some arbitrary historical moment in time. This is a bit like how radiocarbon dating works. When you see a date like “1,000 years before present” that year is 950 AD, because “Present” = 1950.

For this purpose, Linux uses Unix Time, also known as Posix time. In this system, time started at midnight ZULU time in the morning of January 1st, 1970. Everything before that is prehistory. Approximately one and a quarter billion seconds have passed since then.

So the solution is easy: Convert the present time to Unix time. Then, add the number of seconds that is 14 days into the future (1209600 seconds) to that number to obtain the second time. Then, since gcalcli does not read Linux time (shame on the coders! shame on the coders!) convert the Unix time back to esoteric time (with the slashes) and feed that to the gcalcli command. I originally did this as a one liner but I’ve since parsed it out into individual lines and put it in a bash script I call “agenda.” Here it is:


#/bin/bash

Let’s break it down.

First, the shebang line, and this may vary across systems:

Then we make some numbers. nownum is the current date in Unix format, using the “date” command and specifying a “format” code of %s, which is seconds since the start of the Unixverse. Then, 14 days of seconds are added to this to make a second Unix time number:

Then, these two values, “nownum” and “thennum” are converted, using the esoteric –date switch of the date command, into strings “now” and “then” which are in standard date format:

These two numbers are then printed out as part of a sentence reminding the user what today’s date is and what the end of the 14 day period is:

And finally, gcalcli is invoked using $now and $then as parameters to the agenda subcommand. I also threw in –nc which suppresses color coding.

The reason I suppress color coding is so I can do this at the command line

agenda > ~/agenda.txt
alpine-> (c)ompose -> amanda -> ctrl-r -> ~/Desktop/agenda.txt -> ctrl-X -> Y

that slams the current agenda into a text file, opens a mail program, composes a message to Amanda, slams the contents of the agenda file into the email and sends it off.

Hey, wait, what am I doing? I should add a line that creates agenda.txt every time I request the agenda from Google.

tapity-tap-tap tappity-tap

Done.

nownum=date +%s
thennum=$((nownum+1209600))
now=date --date=@$nownum +%D
then=date --date=@$thennum +%D
echo Agenda for $now through $then
gcalcli --nc agenda $now $then > ~/Desktop/agenda.txt
cat ~/Desktop/agenda.txt


This post is part of the cli series. The full list is here.

If you found this post useful, please consider using the social networking tools below to spread it around! Thank you

Not very useful.

It is a little easier if you use Google Calendar’s “agenda view” which simply lists, in chronological order, the upcoming appointments, so days on which you have nothing scheduled do not take up space. Like this:

But that still kind of sucks, since the vast majority of information on that screen has little to do with the information you are looking for. As long as a command line interface is available, which it is, wouldn’t it be nice to have a quick and dirty command that you could type in to retrieve your calendar, perhaps manipulate it, and even get a simple text-based agenda view that one can actually see?

There is, and it’s called gcalcli. When I type “gcalcli” into a command line with the argument “agenda”, I get this:

With relatively little configuration, gcalcli knows where to go and get my calendar information. The program has lots of options, most of which are used to select among the various calendars you have access to or to configure the output. When I typed in:

gcalcli list

the program outputs a list of four calendars that I have access to. I knew about the first two of them already. The third is a calendar called “US Holidays” which I imagine comes along with Google Calendar. The fourth is that of an organization I belong to, though I had forgotten about the calendar.

One option tells the “agenda” command to include all the details within the calendar and not just the date/time and name of event. The calendars can be searched (but for whole words only). Another command outputs a week’s calendar in a nice formatted arrangement:

And, yet another outputs an entire month. Unfortunately, when I tried that I got an error and some gobbly-code.

It is possible to add single appointments using the command “quick”:

There is also a way to execute a command if an event is to occur within a certain amount of time. This might be run on start up of a particular terminal or integrated with a chron job, to develop your own personal way of annoying yourself into getting your stuff done.

There are lots of other options. You can read more about it here, and if you are using Debian/Ubuntu, you can install the software in synaptic (search for gcalcli) or by simply typing the magic words:

sudo apt-get install gcalcli

This application firmly sits in the Class II cli App category, which I’ve discussed before. This is where you want a GUI version and a cli version of the same app, in this case, accessing the same database. Different circumstances demand different approaches. Learning two or three commands with gcalcli will augment your Google Calendar experience and make you look really cool at the coffee shop. But there will still be times when the web-based GUI interface makes the most sense.

Furthermore, and I’m sure you already know this, you can easily define and save an alias for “gcalcli agenda” (or any other combination of frequently used commands and options) so you would type only, say “agenda” or “appointments” or whatever to get the output you need on a regular basis.

Here’s another little trick in case you want to totally geek out. If you are using alpine for your email (I’ll discuss this great app later) you can type in ctrl-_ and call emacs as your secondary editor. From within emacs, select some irrelevant text (that step may not be necessary) and type ctrl-u to cause the output of the next command to replace that text. Then type shift-alt-| (the vertical bar thingie), which allows you to enter a shell command. Then, type in

gcalcli --nc agenda

The –nc strips the output of its color coding control codes, which are messy when they are not spewed onto a terminal. The selected text will be replaced with your agenda in nice, text form. Save, exit, and you’re back in alpine with your email to your significant other who just asked you “Are you available Wednesday night to go pick up the new car seat?” or whatever.

Obviously once you’ve done that a few times and perhaps refined the exact procedure, you’d make these commands into a macro so little more than a stern look and the flip of a single finger will insert your current agenda into whatever email you are currently writing. How cool is that?

That is a very amusing way to tell the weather, but it is not convenient because your computer is now tied up and you can’t use it for anything else.

Another way is to attach a dohickie to a toolbar or a part of your desktop that is constantly contacting some weather service. The dohickie will change its physical appearance with the weather, it may have the temperature written on it, and perhaps if you click it a web site from a weather service opens in some nearby browser window. This is not convenient if you happen to not be connected to the Internet and the dohickie either makes an embarrassing public fuss about it, or worse, does so much dicking around in the background trying to get connected that your computer’s performance is affected.

A modification of this method is to have a Google applet on your Google home page, or some other applet or similar mini-program on some other portal. This has the same problem as the dohickie but more dramatically so, as every time the page loads or refreshes there is negotiation and messing around just to keep the weather widget up to date, and there is a good chance you will not look at it (or even care about it) most of the time. Thus, your computer is doing resource hogging stuff and ignoring you needlessly while you are busy ignoring it, which is not ideal.

Most people, on considering the above methods, will simply tell you this: “Just bring up The Weather Channel” or “The Weather Underground” or even just Google and see the weather there. Its simple. But actually, they’d be mostly wrong.

Yes, it is simple to open up the web page of a weather service, and if you want to see radar and other stuff, this is a great way to go. But if you just want current conditions and a quick forecast, it may not be.

When I open up a weather web site on my laptop, I get this:

Notice that the weather is not visible on this page, even though I’ve got my laptop maximally configured to provide real estate to any app that opens on it. To see the weather I have to scroll down. Way down. Here is a view of the entire page except the very bottom, showing you where the actual current conditions and quick and dirty forecast is located:

I’ve circled the tiny little part of the massive webpage loaded to get the weather that shows the actual weather conditions and immediate forecast. Even this area, though, is kind of spread out and unnecessarily iconographic when you look at it up close:

That’s pretty useful, but getting here required opening a browser, clicking a bookmark or typing in a search term or URL, and scrolling around a bit. Not a lot of work, but not zero work either. In other words, when in a moment I show you a command line version of how to get the current conditions and immediate forecast, whatever effort it took to get there is not to be compared to zero effort, but rather, to the actual effort a web browsing client and web page requires. (Many people forget that because they are so used to it.)

Speaking of which, what happens if we do use a command line method for getting at the weather? Suppose I am already at the command line and I want to know the weather. What do I do? I type “weather” at the command prompt. I’ve previously configured the software to assume that if I don’t say otherwise, it should give me the weather locally with a forecast. I get this:

I can also have the weather up north at the cabin by typing in “weather cabin” … this gives me the temperature and other current conditions at the small air strip a few miles from the cabin, and the forecast for a large town an hour away or so, which is the closest NOAA forecast location.

I can have this information with less detail (like, no headers or indentation) or more detail, for anywhere in the US. If I was searching around for weather info for places I normally don’t go, it would probably be easier to mess around with the web site of some weather service, such as The Weather Channel. But for finding out the current conditions and immediate forecast for basic day to day use, the command line is faster, easier, has fewer problems, and is more convenient.

This (the app, ‘weather’) is a great example of what I call a Class II command line application. In my system, a Class I application is one that is simply done better, almost all the time, on the command line. A Class III command line application is one that is usually not done as conveniently on the command line as with a GUI, but is sometimes necessary and thus worth knowing about even if you don’t internalize the methods. This probably includes a lot of network configuration work, for example. The network GUI apps in Linux are OK but not powerful, but the command line roolz. A Class IV command line application is one that is hardly ever needed and is almost always inconvenient. Browsing the web from the command line is possible but is almost never recommended (thought here are a lot of cool webby things you can do with command line, just not reading blogs and stuff).

But the weather application, as a Class II app, is one that is really useful and really cool, but that has a GUI version (the various web sites on the Internet) that is potentially really useful and cool as well. Which approach … cli vs. GUI … one would ideally use would depend on the immediate needs of the user and other factors that are hard to predict in advance. For Class II apps, it is probably a good idea to learn both the cli and GUI version. Other examples include text editing and RSS feed reading, but (to me) most importantly, email. Try using a console-based app like alpine for reading your email for a few weeks and you will become very annoyed at web-based and GUI client-based methods, even if they do have the occasional advantages. Yes, when it comes to searching through emails you may find the GUI apps better because their paradigm is more similar to what you are accustom to.

More details on the app “weather’ can be found here. The way it works is to tap into a NOAA maintained directory structure of weather information organized in state/city folders and by the four digit location code used by aviators (related to but not exactly the same as “airport codes”).

Install it using your package manager or, if you are Debian-cli savvy, sudo apt-get install weather. Then, use man weather and man weatherrc to read about the program and its configuration files.

Next in the series: Using Google Calendar from the Linux Command Line

If you find this useful, please consider posting it on facebook, stumbling it, redditing it, etc., using the handy dandy buttons below! Thanks.

The following definitions link the above concepts to actual applications, utilities, and stuff.

This is the type of application that may or may not make full use of the GUI but that uses primarily keyboard commands to operate. Even though emacs now has a menu that can be operated by a mouse and toolbars with buttons on them, no one ever uses them, and most emacs activity is done by using the keyboard. Think of it this way: A person who has only ever used emacs on a “virtual console” or within an xterm can switch to the GUI version of the program and never change a thing, other than being annoyed at the screen real estate being taken up by the button bar. There are not many apps like this, and there should be more. Nonetheless having the definition handy is important because one of the most important apps a GAKy cli-ist is likely to use is the GUI cli-terminal-like GAKy text editor.

Now that we have some basic terms defined, let’s look at software that might be usefully run on the command line.

I. X marks the spot.

The first rule in using console based software on a modern Linux computer is this: Run the console in X (the windows server, along with a desktop such as Gnome or KDE or whatever), with the consoles running as an emulated terminal as opposed to a real terminal. Real terminals are available to you from within gnome or KDE by typing Alt-Ctrl F1 through F7 or so. Chances are your “x” (gnome, KDE) is on the console that exists at Alt-Cgrol F7. But that is not how you should run your console programs because you lose nothing by running emulated terminals under X, and you get the following advantages:

1) You can adjust how it all looks a lot better than you can with actual consoles;
2) You can integrate activities between programs more easily;
3) There are some things you can’t do in a console, despite what certain fanatics may claim. Try browsing the web with lynx or wget for a while. You’ll be back.

II. Make use of desktops and other hierarchical constructs.

Instead of having different virtual consoles with different things going on, you can get the same effect … which, on your laptop means having a full screen console … by using multiple desktops. Most users are pretty happy with the usual default of four desktops. If you want to do a lot of cool console stuff, consider making yourself eight desktops. This does not mean you won’t be running windows (and tabs within windows) but it will give you the opportunity to make full use of the mindblowing potential complexity available on your linux box. Think about it. You have:

1) Desktops (aka “workspaces”)
1.1) Consoles or browser windows
1.1.1) Tabs in browser windows, and if you have the right emulator, in consoles
1.1.1.1) Screen or other methods of spawning processses within consoles.

Deep. Hierarchically speaking, anyway.

III. Use certain console apps as X apps anyway

Even though you will be using console applications for many purposes, consider using emacs in X as your processor. If you use gnome, use the provided file manager simply because its integration to the system is so powerful that you will lose functionality if you don’t. The same is probably true for KDE

IV. Focus on using these apps

1) Despite what I say above, have at least one quick and dirty console based text editor and use it for one or two limited purposes, mainly for browsing and doing limited editing on specific, selected files. There is no real reason to do this other than that it will look cool.

2) Alpine or another text based email app. Console based email apps can be annoying now and then. GUI email apps are annoying at all times. Be annoyed less.

3) Calendar and scheduling apps, including one that gives you access to Google Calendar.

4) A console based calculator.

5) The package manager for your distribution in cli form.

6) Image processing software such as Imagemagick.

Some functionality is better addressed by cli apps. Some functionality is better addressed by GUI apps. Other functionality is best addressed either way, depending, in which case you may find knowing both is a good idea.

When I look at the GUI version of Google Calendar, I become disoriented and confused by the way it is displayed, and the way it scrolls or fails to scroll. There is an “agenda” view, but that requires messing around with views. If I want to know what is going on over the next couple of days, I use a cli that spits out an agenda. I can spit that out and send it to my wife in an email very easily. Yet, when I want to make, and otherwise muck around with, appointments, the web based GUI is better.

I could say similar things about email and other applications as well.

Over the next few days I’ll be discussing various specific cli/console or GAK applications.

Next: Whither the weather? Linux CLI solutions

I’ve provided a few technical tips and tricks for alpine, and here’s another one. In Linux, if you startup alpine like this:

alpine -k

you get the function key version. This replaces the control keys with function keys, and the help system reflects this change very nicely. I’m going to consider using it on my desktop in the Blog Cave, because that has an Avant Stellar keyboard with a set of function keys on the left side. I’m currently using these keys for something else (well, some of them) but I can play around with the old wordperfect model of having a truly extended almost-touch typing keyboard and see how that goes.

If the file exists, and alpine is asked for a password, then it checks that file for the password. If it is not there it asks you for the password, and then, after you’ve entered it, alpine asks you if you want to save that password in the file. If you say yes, then you are in business.

This has two important implications for you. One: If you want alpine to remember passwords, just create the file and it will happen. Two: If you have trouble at some later time with some kind of operation and you think that the part about asking for the password is screwing you up, delete the file and restart the program (you’ll have to know the password, of course, for when you are prompted for it later).

How do you create the file? Using the bash command ‘touch’ should do. But what file do you need to create? Well, that depends. The file alpine uses is determined at compile time. At present, it seems that the current version of alpine is using a file called ‘.pine-passfile’ (note the dot at the beginning of the file … this is a hidden file) and this file should be in your home directory.

So, to make this work:

1) Quit alpine

2) In a termnial, type:

touch .pine-passfile

3) Restart alpine, check for email and send email, and when asked for a password, enter it and respond “yes” to the prompt asking you if you want to save the password.

4) Give your mouse a little piece of cheese so it does not feel lonely.

For more information about alpine click here.

The default that alpine comes with, at least on my machine, seems to be the Epiphany browser I have no idea why. And when it goes there, it opens the browser and freezes the alpine screen, so I have to close the browser to go back to the email.

How quaint.

What I want it to do, of course is to open a tab in the most recently touched instance of Firefox, and not freeze the browser. This way I can navigate quickly through the links and open the ones I want to see as rapidly and efficiently as possible, each in a new tab.

To make this work, you need to do two things. First, navigate to the option for url-viewer in alpine. Second, enter the full path to the firefox browser. You can’t just enter “firefox” because … well, it won’t work for some reason that escapes me.

Navigate to the url-path by starting at the main menu, going to setup [S], then Configure [C], then ctrl-W to search and put in ‘url-v’ as the shortest string that will get you where you are going right away.

Then hit enter, and type in:

/usr/bin/firefox

Then reach over to your mouse and give it a little pet so it does not feel lonely, then hit enter and accept the value, Exit setup [E], confirm exit [Y] and go back to reading your email.

So, in short,

MSC ctrl-W url-v[ENTER]/usr/bin/firefox[ENTER]EY

(the MSCWE and Y need not be in upper case, it is just convention to show them that way)

Now, url’s will open in firefox, in the last used window, in a new tab.

Now, if you are more of a geek today than you were yesterday, you’d set your URL reader to lynx. If you do that, Lynx will open as a process in the same terminal window alpine is using (though this behavor can be altered by entering switches in the url-viewer option section, most likely) so you will need to quit [Q] lynx to get back to alpine. Try it, it’s a trip. Lynx is a bitch.

How, if tomorrow you find yourself waking up as even more of a geek than you did today, use a shell script using wget and some perl one liners to convert the url contents into a well behaved text file that you then process using sed.

Tame Teh Internet!

For more information about alpine click here.

It is possible, even probable, that other distros install alpine in a manner that functions correctly, and this may be a bug in the Ubuntu distribution, but I’m not sure. In any event, this is what you can try to fix it:

From within alpine, be at or go to the main menue

go to setup (S)
go to configure (C)

search for “spell” using ctrl-W (hit ctrol-w then type in “spell” without the quotes and hit enter)

You will arrive at the option “Spell Check Before Sending” … check that if you like, up to you.

Hit ctrl-W again and accept the default (“spell”)

You should now be at the option “Speller” which probably has no value set.

Hit enter to allow entry of a value, and type in:

aspell -c

This assumes you have aspell installed, which, if yo ure using Ubuntu you do. Note that the tricky part here is the ‘-c’ option. This causes alpine to invoke aspell in the “check spelling” mode.

If that does not work, complain in the comments below and someone will figure it out for you. Maybe.

For more information about alpine click here.