Whither the weather? Linux CLI solutions

Spread the love

The command line is a great place to get weather information. Here, I discuss one cli-app for current conditions and forecasts, in the larger context of why you would ever want to use the command line anyway.

There are several ways to use your computer to check the weather. One is to use the Nakob Weather Rock method. Suspend the computer using a rope from a tripod of sticks. If the computer is swaying, that means it is windy. If the computer is wet, that means it is raining. And so on. Like this:
i-b0a90f9dc37a589c3a59cdd10e2ba665-weather_cli_00.jpg

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:

i-c983430a3ba9dd197637f16aa2cae1a8-weather_cli_01.jpg

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-501af201d56bd0158822ab5f07a8865f-weather_cli_02.jpg

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:
i-d4d1dde9fda953611e302c19815c2051-weather_cli_03.jpg

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-12ac5169bd34e1810be26815351fa7db-weather_cli_04.jpg
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.

Have you read the breakthrough novel of the year? When you are done with that, try:

In Search of Sungudogo by Greg Laden, now in Kindle or Paperback
*Please note:
Links to books and other items on this page and elsewhere on Greg Ladens' blog may send you to Amazon, where I am a registered affiliate. As an Amazon Associate I earn from qualifying purchases, which helps to fund this site.

Spread the love

12 thoughts on “Whither the weather? Linux CLI solutions

  1. You have inspired me to write a command line app using lynx –dump to dump out http://probcast.com/, which is very good for Washington and Oregon weather – this site gives the most likely weather along with likely extremes.

  2. James, consider the possibility that their pages are rendered from some source data that you can drill to and use more easily than the final HTML. But, parsing down HTML is a blast.

    You might also consider wget rather than lynx, and consider processing the raw html with sed.

  3. lynx renders the text with –dump, which is what I want. Does wget have a text rendering feature? I don’t think so but I could be wrong. If the page were XML I’d think about Pyxie, but I’d prefer not to deal w/ parsing the tags.

    I think the MM5 data these maps are based on is publicly available, but that would be non-trivial although not hard. It is a fun idea, but I already have tons of personal coding projects to work on.

  4. I was thinking the tags might be useful. For example, I wrote a script that would mine a science domain for species names, recognizing them as having two or three words surrounded by em codes. When pointed at a site like Animal Diversity Web, it did very well, virtually no errors, since emphasis typeface is almost never used there unless for a species name.

    In your case, a particular unique div may include all the stuff you are looking for.

  5. Plus, that site has the mouseover comments, which may be the info you are REALLY looking for. Will lynx get at them? I assume they are hidden in the javascript or something.

  6. … I’ve got my laptop maximally configured to provide real estate to any app that opens on it.

    You could do more. On my desktop, I have everything on a single Gnome panel (vs. the usual two), and that one is set to auto-hide. On my netbook, I use a netbook-oriented distro that includes the Maximus window manager, which eliminates the panels as well as auto-maximizing.

    I also have two fewer toolbars in my Firefox. But I still lose almost a quarter of the vertical screen space, until I hit F11.

  7. I wanted to “split” my weather forecast script into four Quadrants matching my Terminal Size (80 x 24)

    The weather data is handled by conkyForecast, a python script by kaivalagi found at http://ubuntuforums.org/showthread.php?t=869328
    (Conky NOT required to use it!)

    Script is at http://pastebin.ca/1978836
    Screenie is at http://i771.photobucket.com/albums/xx360/E522260/Screenshot-trans.png

    Changing terminal resolution doesn’t change the output. I’d need help with that detail.

    Enjoy!
    Peace.

  8. After struggling getting the right Metar data and weather station info configured for weather-util ( I know nothing about weather ) and after seeing the data on http://weather.noaa.gov/pub/data/observations/metar/decoded/ is plain text I decided to write an extremely simple script to give me the basic functionality I need.

    First go to weather.noaa.gov find the closest station to your location and the four letter “id”. Go through the http://weather.noaa.gov/pub/data/observations/metar/decoded/ index and find your four letter id??.TXT this file provides the up to date weather info. Then I wrote this script-

    # Make a executable text file named weather with script and save in /usr/bin (substitute your four letter id everywhere I used mine KRIV.TXT)

    #!/bin/bash
    readfile=/tmp/KRIV.TXT
    function downWinfo {
    wget -O /tmp/KRIV.TXT weather.noaa.gov/pub/data/observations/metar/decoded/KRIV.TXT
    }
    downWinfo &> /dev/null
    echo “Local Time: `date`”
    cat $readfile
    exit 0

    Now just type weather in a terminal and it will display current weather information.

Leave a Reply

Your email address will not be published. Required fields are marked *