Doing everyday tasks on a Linux CLI environment

In my last post, I detailed the horrific digital aftermath of what happened after I had tested out the Ubuntu Natty Alpha 1 release. In short, I was left with a system that refused to boot into a graphical environment at all and was forced to use the command line to do several tasks that would normally be done in a GUI. I was so surprised at how remarkably easy it was to do these tasks(web browsing, torrent downloading, CD burning) on the command line, I announced my intention of going completely GUI-less for two days.

While the "recovery console" session option found in the GDM login screen would be the closest replication of my X-less ordeal, I found that the xterm window it had was too small to show in snapshots. I decided to log into Gnome, but work solely within a maximized xterm window(alternatively you can use gnome-terminal and toggle full-screen with the F11 button). Here are the following applications I've used so far, grouped together according to general tasks:

File Management:

Midnight Commander

There's a few options when it comes to file management on the console. There are, of course, the built-in shell commands(cd, ls, touch, mkdir, rm,rmdir, etc.) ready to be used with just a few keystrokes. But if you want to navigate your filesystem in a more visual way, you can either use the built-in file navigator in the vim text editor(type ":e ." at the vim command line to activate it), or use the Midnight Commander(mc) file manager to do so. Midnight Commander is a two-paned file manager, allowing you to perform file management tasks in two places at once. It can perform file (de)compression, and includes its' own command line when you need to do precise actions on a selection.

Window Management:

Yes, the Linux command line can have a "window manager" of sorts. That window manager is called screen. It allows you to have multiple terminal sessions, similar to managing tabs in GUI terminal emulators. It's a necessity when you want to run several command line tasks at once and backgrounding will not suffice, or when have logged onto a server via SSH and wish to run something after you've exited the session. It should be available in virtually any major distribution's repositories.

Multimedia:

While it's true the command line is non-graphical, it is certainly possible to do some multimedia tasks with no problems.

For sound recording, you can use arecord to record sound from your microphone, and then pipe the output to an encoder like so:

arecord -f cd -d numberofseconds -t raw | lame -x -r – out.mp3

arecord -f cd -d numberofseconds -t raw | oggenc – -r -o out.ogg

Music On Console

For listening to audio stored on your computer, there's several console-based music players(such as gst123, aplay and the awesome opencubicplayer), but I like Music-On-Console(moc), as it allows you to play music in the background while doing other tasks. It is invoked as "mocp" on the command line(to avoid clashing with the "meta object compiler" used when compiling Qt/KDE graphical applications). While playing music, press "q" to exit back to the command line, but all the music in mocp's current directory or playlist will continue to play. You can simply re-invoke mocp to get control again.

To rip audio from a CD, cdparanoia does the job well and the output can be sent to an audio encoder just like arecord.

You can also master and burn CDs/DVDs on the command line. As I mentioned in the last blog post, growisofs can be used to both create ISO images and burn them to disc.

You can also watch movies on the command line with mplayer by invoking it like this:

mplayer -vo caca movie.avi


Office:

Vim, editing a C header file

Yup, you can do some standard office tasks on the command line. For doing calculations, there's the bc command line calculator. And there's no dearth of command line text editors(nano, vim, emacs, etc.), but there's only two apps specifically geared towards word processing: antiword and wordgrinder.

Antiword allows you to view and convert MS Word files into plain text, PostScript or PDF files. An indispensable tool if working with Word files is unavoidable.

Wordgrinder word processor

Wordgrinder is perhaps the only thing on Linux that can be called a console-based word processor. While it writes in its' own native format, it can import from and export to plain text and HTML files. It supports basic styles and paragraphs, but don't expect anything fancy. Nevertheless, its' better than plain text or forcing yourself to do TeX formatting.

SC spreadsheet calculator

For spreadsheet processing, sc fits the bill perfectly(especially if you like vi/vim). Combined with wordgrinder and abook(console address book), you pretty much have a console office suite at this point.

Internet:

While Web browsing has evolved into a very multimedia affair(Flash, Youtube, Facebook/Twitter, etc.), there's a surprising amount of things you can do on the Internet without a GUI.

ELinks web browser, viewing Groklaw.net

For console web browsing, Ubuntu ships w3m by default. While w3m is okay for viewing individual pages, that's all it's really good for. It's basically like the "less" command for web pages. For a truly decent console web browser, elinks is the way to go. It has bookmarks, download management, color support, CSS support and yet it cuts through all the useless crap(Flash, ads and popups) to get you the content you really want.

For non-interactive web interaction, wget and curl are excellent tools. You can also download torrents with the rtorrent console client(mentioned in the previous blog post and highly recommended).

For email, there's several console email clients to use. There's pine/alpine, the traditional mail command, and mutt. If you're used to using the nano text editor, alpine is the easiest option. Mutt is way more powerful, but requires a bit of configuration to get it working specifically how you want it to.

Irssi, chatting with the Kokua/Imprudence devs

For instant messaging, you can use Finch, the console version of the Pidgin instant messenger. And I've found irssi to be a very capable console IRC chat application.

Google:

GoogleCL manpage

Yes, believe it or not, Google has a command line interface for some of its' services(Blogger, Youtube, Picasa, Docs, etc.). And because of that, it gets it's own section. On Ubuntu, you can install the "googlecl" package directly via apt-get. If your distribution's package manager doesn't have it available, you could download the tarball and compile it yourself.

Graphics:

Montage of previous screenshots

You would think that in a command-line only environment, there's not much you can do with graphics. But strangely enough, that's not the case with the ImageMagick suite of command line tools. With ImageMagick, you could create and manipulate pictures in ways that was once the sole domain of GUI image editors like GIMP. The above picture is a montage of all the other pictures I took while creating this blog post, made possible by the montage tool of the ImageMagick suite. You can make composites, animated GIFs, apply various effects, and a whole lot of other things.

Gaming:

Yes, there's some terminal-based gaming options for Linux. You can connect to various text-based MUD(multi-user dungeon) games on the Internet via the telnet command. A good place to start with MUD games is The Mud Connector. If text-only isn't your thing and require something marginally more graphical, the surprisingly challenging nethack game may be right up your alley. If you've got a bunch of old DOS games lying around, you can use dosbox to play them.

Missed stuff:

I'm pretty sure I've missed a few things, so feel free to let me know in the comments.

The Second TPV developer brown-bag meeting: Wow, what a difference!

As noted in the previous blog post, the second brown-bag meeting between third-party viewer developers and Linden Lab has happened earlier today and from reading the transcripts, this time around it went way better. No griefing, sim crashing or voice problems, and the consensus is pretty much that the policy is much more agreeable as a whole.

What was discussed this time around is more "small stuff", like issues with the policy and content import and export. While Section 2(b) hasn't really changed at all, Joe Linden did recognize that there is a genuine need for extended metadata to help address legal uses of non-creator export, but the policy won't change until that happens. Fair enough, in my opinion. There are ways for creators of permissive content to get around it(host it outside of SL, collaborative builders can export their parts of builds and share it with their collaborators until the build is completed).

Also, Joe specifically wanted to address the Imprudence team about their plans to drop support for SL. This is a very positive sign for me personally, as I do prefer Imprudence not just for the viewer itself, but because I find the developer team to be very professional and upfront. It's also a positive sign for SL in general as well, as it shows the Lindens do not want to see a mass exodus of development support to OpenSim-based grids(although they have inadvertently strengthened OpenSim viewer support).

The only thing about the meeting that didn't change, sadly, was that again it seems no developers who are already listed in the TPV directory were in attendance. Maybe some of them didn't want to attend out of fear they would get the third degree, although it seems that given the policy changes it's just water under the bridge now and their input would be welcomed.

All in all, though, it's a 180% turnaround from last week's debacle and the first positive change I've seen from the Lab in a long while. I feel like doing a headbob:

The New Third-Party Viewer Policy: A Thing of Beauty and A Joy Forever

As noted in the previous blog post, the Lindens have quietly changed their third-party viewer policy. The changes, unlike the previous revision which amounted to nothing, address the majority of the issues raised by TPV developers and results in a more clear and simpler read for those who it's intended for.

The single biggest change is in Section 7(d), which now reads: "You assume all risks, expenses, and defects of any Third-Party Viewers that you use. Linden Lab shall not be responsible or liable for any Third-Party Viewers" Previously, the first sentence had ", develop or distribute" tacked on at the end, which put the sort of legal liability that LL themselves disclaim onto third-party developers. The new wording now makes it clear that was not the actual intent of the clause.

So with this change, for most legit TPV developers, there's nothing to fear from this policy anymore and it may even be totally okay to go for self-certification into the viewer directory(IANAL, of course, but that's my personal opinion).

There may be a few nagging issues left, such as Section 2(b) which restricts content export capability to creator-only. However, that merely applies to when on the SL grid. So it's possible to either simply have creators host permissive content outside of SL, or just have full-perm content export disabled only when on the SL grid. However for non-SL content exporting, I'd strongly recommend some sort of mechanism to convey usage beyond SL's crude C/M/T checkboxes.

Of course, certain folks who are against third-party viewers as a whole will be decrying the changes as "LL caving in to TPV developers" and "they're giving the store away to the copybotters". Reading through the policy, it's clear that's not what happened. The policy now more clearly delineates the difference between a compliant viewer and a malicious viewer(see Sections 2 and 7) and the enforcement terms(Section 8) have not changed(not counting the addition of 8(f), which merely makes clear the policy isn't intended to screw with the GPL).

Given these changes, I may not have to close down my store in SL after all. But I will continue with my current plan of opening up on other grids. It's a happy day for me :)

Update: BTW, the second brown-bag meeting has happened today. The transcript of the meeting can be found here(big thanks to Latha Serevi for the transcripts!).

Updates on the Third-Party Viewer Policy debacle

Joe Linden recently hosted a brown-bag meeting for third-party developers to discuss the TPV policy. Unfortunately the meeting accomplished very little in terms of reconciliation or possible policy revision. This was due to griefers at the meeting teleporting around and crashing the sim(those griefers sadly being some of the people attending the meeting), and expected major problems with voice.

What was interesting about this meeting is that as far as I can tell there were absolutely no third-party developers in attendance who were listed in the Lindens' third-party viewer directory. That left Joe with virtually no solid support on his side. Also there were a few people there who weren't developers at all: Wut Moorlord of Woodbury/w-hat(a known griefer) and Angela Talamasca, who basically represents anti-open source folks like Prok. Then there's the shady trio of "ex-griefer" Emerald developers Discrete Dreamscape, Fractured Crystal and Lonely Bluebird. So with that unique blend of folks there, it's no wonder it came out a disaster for both sides.

What I took away from the meeting transcripts, however, is that the Emerald devs are going to do exactly what I theorized to several friends: that the Emerald developers are going to secretly negotiate a deal with the Lindens to become the only allowed general use third-party viewer on the directory(KirstenLee's viewer doesn't count as it's meant as a specialist viewer for photographers and machinima creators), with a side deal that Onyx(the copybot/griefer client the Emerald devs use amongst themselves) will be exempt from the policy, making it a Linden-blessed copybot/griefer client under the veil of "penetration testing for the Lab". Meanwhile all of the honest devs of general use third-party viewers will get bullied out of SL to appease the Lindens and their Emerald buddies. I have very little hope that the next meeting will be anything different or produce anything positive.

So in a nutshell, for general SL use it's either the still-craptacular Viewer 2.0, Snowglobe or risk your data and privacy with the Emerald devs in exchange for jiggle boobs, fancy selection beams and lag-inducing extra attachment points. Ugh.

Update: Regarding Emerald, Prok has a new blog post up which connects almost all of the dots about these folks who, in all honesty, should have been perma-banned from the first TOS/CS violation they committed(feel free to skip her usual open source=evil BS, of course). What Prok misses, however, is the connection between Onyx and Gemini CDS. Yes, CDS will ban all copybot viewers detected, except Onyx since it's an Emerald "project". Combined with the TPV policy going into effect, the Emerald devs can run roughshod over SL with no one the wiser, with only the above choices left for SL residents.

Update 2: Surprisingly, the Lindens have quietly amended the TPV policy. From what I'm reading of it, the changes are precisely what the TPV developer community asked for. I guess that blows apart the piece of my theory of Emerald colluding with Lindens to run all the other legit TPVs out of town. However that doesn't change the likelihood of CDS and Onyx collusion.

Imprudence Developers take a stand against the Third-Party Viewer Policy

This past Tuesday I had the privilege of attending a "weekly ImpDev meetup", where Imprudence viewer developers and those(like me) interested in it's development would meet and discuss various issues, like bugs, feature ideas, and anything else related to Imprudence. The meeting, however, turned out to be the most important meeting not just for Imprudence, but for other third-party viewers as well.

The meeting was about how the Imprudence developers should respond to Linden Lab's final wording of their third-party viewer policy. Earlier today, Jacek Antonelli broke the news of their decided response. While it echoes the general response of the TPV developer community, it states it in a very professional and respectful manner towards users, developers and even Linden Lab. Jacek also announced that while Imprudence cannot agree to the TPV policy as a whole, they will honor the parts of the policy that are reasonable and do not legally endanger the project.

This response is already having a ripple effect, as it has seemed to inspire Luna Viewer developer, Fred Rookstown, to continue developing Luna but with similar changes as Imprudence. It would also seem other viewer developers will follow suit, with the possible exception of the Emerald developers as they may be secretly negotiating with the Lab to get some sort of exemption from the policy in exchange for some changes made to Emerald(most likely gutting import/export, grid manager functionalities and a few controversial features).

While this marks a very sad day for SL, conversely it's a red-letter day for OpenSim-based virtual worlds who will benefit from the increased viewer support and likely incoming users. The ball is now in Linden Lab's court, and how(or even if) they respond to this will set the status quo in SL open development possibly for years to come(if SL manages to last that long, though).

How Third-Party Viewer Developers are going to feel the pain

In my previous post, I described exactly how inter-grid content creators are going to become walled out of Second Life. But the Second Life® Terms of Service and third-party viewer policies will also bite third-party developers, hard.

In particular, the ToS and third-party policies place restrictions on GPL usage and distribution for viewers that connect to Second Life, as I've blogged about it before. Also, Section 2(b) of the third-party viewer policy will affect the major third-party viewers(Emerald, Meerkat, Imprudence etc) because they all have content export capability. If a third-party viewer developer wants their viewer to comply with the policies, then they will have to somewhat cripple that functionality(no full perm export, creator-only), despite legitimate use cases that warrant it.

A third-party viewer developer now has this hard choice to make: either cripple certain functionality and accept restrictions on usage and distribution, or rewrite their viewer as "not for Second Life use" and as a result lose much of their current user base in Second Life.

From the discussion going on in the opensource-dev mailing list, it seems virtually all third-party developers are going to take up the latter choice. But that may wind up to Linden Lab's disadvantage in the long run, because that means those viewers' innovations will be re-geared to benefit Second Life's biggest competitor: OpenSim-based grids.

Second Life about to wall up content

Ann Otoole calls out Linden Lab in her latest blog post, spelling out how Second Life is about to become a completely walled-up garden starting on April 30, 2010. She frames the discussion in the context of textures, but her argument also applies to objects, clothing/body part items and scripts(to a much lesser extent).

From April 30th onward, the Lab will be vigorously enforcing Section 2(b) of the third-party viewer policy, which also happens to be a part of the Second Life® Terms of Service.

In the opensource-dev mailing list, Lindens are suggesting content creators who wish to allow inter-grid use of their content should host it outside of the Lab's grids and services. The implication of that is that Second Life is unsuitable as a host or distribution channel for such content. For LSL scripts, that's not much of a problem because if a script's code can be viewed in-world, it's simply a matter of copy/pasting text, the Lab can't really stop that. But for other types of content(especially prim and sculpty-based objects) made for inter-grid use, the policy and the ToS combine to form a content license trap.

For example, let's say I'm creating a prefab house that I wish to be used in both Second Life and other grids. I create and host the content on my own server, by using a third-party viewer to export it to a zipped archive. I create a specific license allowing inter-grid use(or use an open license). Someone who wants to use my content logs into Second Life and imports the content in-world. Now, here's the big question:

When my licensed content is imported into Second Life®, what happens to the license for that specific copy? According to the ToS and TPV policy as it is today, my license(parts of it at least) no longer applies to that copy and can only be used within SL and it's rules. In effect SL becomes a content trap and a walled garden, both for permissively-licensed content(Creative Commons, open source, public domain etc) and proprietary content with inter-grid use allowances. So to preserve the license and the rights to my content, I must have a clause in my license that prohibits import to grids whose policies or ToS conflict with my license, otherwise the importer loses the right to use my content.

That kinda sucks, right? Well, not all hope is lost and in my next post I'll detail the painful choices third-party viewer developers and their users may have to make in the wake of the third-party viewer policies, and how this ties to content creators.

The Third-Party Viewer Policy: The shoddiest policy from the Lindens

As I noted in the previous post, coinciding with the release of Viewer 2.0 was the release of a third-party viewer policy created by Linden Lab. At the time I had read it, I did not think much that it was a bad policy nor think it would negatively impact third-party viewer developers.

I was wrong.

In fact, there's so much wording in the policy that not only negatively affected developers, but also violates terms of the GPv2.

For example, the GPL explicitly disclaims liability of a developer, yet the policy puts it on after the fact. Also, the GPL states that you may not impose further restrictions, conditions or terms of distribution beyond what the GPL specifies. The policy does exactly that.

But my biggest beef with the policy is Section 2(b), which flat out bans export of full permission content without the legal consideration when the creator of a piece of content grants exportability to the content's users. This effectively kills content licensed under Creative Commons, open source, public domain and other content whose license allows exportability.

There are other issues as well. In fact, as it stands no third-party viewer can be in compliance with the policy and be able to distribute. But thankfully, as Tateru Nino's Massively article points out, the Lab has brought the policy back to legal for a rewrite(this has been confirmed in the opensource-dev mailing list). Here's to hoping they get it right this time!

BTW, the only folks who are seriously lauding the policy as it is now, are those who are opposed to third-party viewers in general, so that should be a clue as to what's wrong with it if still in doubt.

The Spectrum of Open Source Viewers

The other day, Dale Innis posted a piece about the leaked Viewer 2.0 testing comments and how it relates to third-party viewers. A good read for sure, but what got my brain neurons firing off was from a part of a comment in a humorous response post from Adric Antfarm, about third-party viewers and Prokofy Neva's views on them: "The truth is in the middle. They are neither the savior you claim or the devil she does."

I was going to put up a comment on Adric's blog responding to the statement, but it got too TL;DR-ish, so I'll put my thoughts down below(don't worry, I'll try to keep it concise and brief).

I think the answer isn't in the middle, but rather that the answer is all three due to the fact that there are viewers that fit in each category. A spectrum, if you will. For example, let's look at viewers like Hippo, Imprudence, Meerkat and Snowglobe. The first three have third-party grid login management far superior to the official viewer's clunky "--loginuri=" command-line method. Imprudence and Meerkat have legitimate object backup capability(creator or full-perm only). Snowglobe recently gained text chat translation, Open Grid Protocol login support, and LLMedia API support(my favorite feature). These viewers, as well as some special viewers like omviewer-light and ajaxife.net are clearly beneficial to the metaverse community as a whole and should be held up as excellent examples of open source community at work.


Then there's the undeniably malicious viewers. First it was Copybot, now we have an unholy trinity of Cryolife, Thuglyfe and Neillife. All three are at their core a continuation of CopyBot's malicious intent(copy objects with no regard for the Second Life permissions system). Thuglyfe goes a step further and includes features designed to avoid parcel and estate bans. These are the kinds of viewers, open source or not, that should be fought against vigilantly.

And currently straddling the middle of the spectrum is Emerald, the most popular but controversial third-party viewer(Disclaimer: I have used Emerald, but as of late I have been using Snowglobe and Imprudence instead). There are so many cool features of Emerald I can't list them without turning this paragraph into TL;DR, so I'll go straight to some of the controversial features. First there's de-friending notification. It's okay in SL to de-friend someone and letting it pass quietly. Getting a notification that you've been de-friended is a quick way to cause drama and grief. Showing real online status and avatar keys in profiles can also be griefing-enablers.

Also the past activities of some Emerald developers don't help their viewer. However, the Emerald developers seem to be willing to work with Linden Lab on viewer policy, and they are now keen on combating malicious Emerald derivatives such as Neillife, so the jury is still out on Emerald. It can go either way.

So to either wholly allow all viewers or condemn them as Prok does are completely irresponsible and one-sided views. It will lead to either rampant copyright infringement and crime or feature stagnation, greatly harming the value of SL. A balanced view of the spectrum, however, will ensure that Second Life and it's derivatives will continue to succeed for a very long time.

Ogg Vorbis Audio Streaming *finally* comes to Second Life!

Yesterday, the latest release candidate build of the Snowglobe viewer was released with relatively little fanfare. But for Second Life residents who use Linux as their operating system of choice, yesterday marked the arrival of a feature long desired: the ability to stream an open source audio format(Ogg Vorbis) within the virtual world.

The crapiness of FMOD and the awesomeness of LLMedia

Ever since the Second Life viewer had the ability to stream music, it did so through an audio library known as FMOD. FMOD was great for streaming MP3 music, but wound up crashing the viewer when attempting to stream Ogg Vorbis. Yet according to FMOD's product description page, Ogg Vorbis is supposedly supported. This situation prompted a JIRA bug to be filed, where it never got fixed at all, despite Tofu's insistence that OpenAL fixed it. For over two years, nothing. Then hope came with the coming of the LLMedia API: a media-rendering plugin system for the viewer. Initially, LLMedia was built for Windows and Mac viewers, but as of yesterday it finally hit Linux, and it works pretty damn well.

Testing it out

Testing it out is pretty easy if you own a plot of land in-world(alternatively you could try it with your own local OpenSim installation): just grab the RC, set the audio stream in-world as you would normally do, but be aware that parcel audio settings now have their own tab in the "About Land" window. Then just hit the play button on your viewer HUD.

There is a spot of bad news, though. While Ogg Vorbis streams wonderfully without any extra plugins, Theora video does not(perhaps a Theora plugin may come out soon). Plus, rendering web pages on prims uses qtwebkit now instead of Mozilla, so depending on your Linux distribution you may need to install qtwebkit via package manager.

All in all, this is a greatly welcome development for Linux-using residents. Bravo, Linden Lab!

Update: Oh, I forgot to mention that Snowglobe also has built-in text chat translation(no more language HUDs!) and Open Grid Protocol login support.

The 1st Brownbag Meeting: Looking Pretty Good so far

Yesterday, I stumbled onto this wiki page with a transcript and an MP3 recording of the first brownbag meeting between Linden Lab and third-party viewer developers. The third-party developers were well represented, with some people fairly well known(McCabe Maxsted of Imprudence, Fractured Crystal, Chalice Yao and Lonely Bluebird of Emerald) and several other developers who I'm not familiar with. The Lindens were equally represented, and the discussion in text chat and voice was pretty formal and informative.

The meeting opened up with "What 3rd party viewer features do you think are very useful to users?" and then a Q&A with the Lindens about how the registry process might work out.

From the tone of this first meeting, the Lab might cook up a registry that is fair to all parties involved, including users. The Lab might work closer with 3rd party devs, but not get heavy-handed like the devs feared. Users could get a detailed description of approved viewers along with user reviews and ratings. And perhaps most beneficial, the Lab may finally incorporate some 3rd party features into the official viewer.

So now I'm less cautious and more optimistic about the registry, but there are more brownbag meetings to come and nothing's finalized yet. I'll post when more details surface.

The External Grid Selector Script, Version 0.2

Okay, I've managed to implement simple autodetection of Second Life, Emerald and Snowglobe viewers to the script thanks to the elegant find command. So here's the code so far:

=========

#!/usr/bin/env bash

#Second Life Grid Selector and Client Launcher
#A simple grid manager for the official Second Life viewer,Emerald and Snowglobe
#(C) 2009 Jose A. Agudo aka Second Life resident Antonius Misfit
#Licensed under the terms of the GNU General Public License v3 or at your option any later version

viewer=$(zenity --list --title="Viewer Chooser" --text="Choose a viewer:" --column="Viewers" $(find SecondLife*/secondlife GreenLife*/secondlife Snowglobe*/snowglobe))

#retrieve grid "database" which is simply a bash array variable sourced from a file
if [ -e $HOME/.grids.db ];then
source $HOME/.grids.db
else
cat > $HOME/.grids.db << EOF
#Feel free to add grids here
grids=("Second_Life" https://login.agni.lindenlab.com/cgi-bin/login.cgi "Localhost" http://127.0.0.1:9000 "3rdrock" http://grid.3rdrockgrid.com:8002/ "OSGrid" http://osgrid.org:8002/ "NixTech_Forge" http://97.107.142.118:9300/)
EOF
source $HOME/.grids.db
fi

main()
{
action=$(zenity --list --title="SL Grid Launcher" --text="Choose a grid:" --column="Grids" --column="Login URI" --print-column="2" ${grids[@]:0} "Exit" "Exit")
case $action in
Exit) exit;;
*) $viewer --loginuri=$action;;
esac
}
main
=========

The External Grid Selector script for Second Life/Snowglobe and Emerald viewers

I had promised to post this once I polished it up, but I think it's usable enough in it's present form to be considered as a 0.1 release. So here's the code:

==================

#!/usr/bin/env bash

#Second Life Grid Selector and Client Launcher
#A simple grid manager for the official Second Life viewer,Emerald and Snowglobe
#(C) 2009 Jose A. Agudo aka Second Life resident Antonius Misfit
#Licensed under the terms of the GNU General Public License v3 or at your option any later version

viewer=$(zenity --file-selection --title="Client viewer to run:" 2>&1)

#retrieve grid "database" which is simply a bash array variable sourced from a file
if [ -e $HOME/.grids.db ];then
 source $HOME/.grids.db
else
 cat > $HOME/.grids.db << EOF
#Feel free to add grids here
grids=("Second_Life" https://login.agni.lindenlab.com/cgi-bin/login.cgi "Localhost" http://127.0.0.1:9000 "3rdrock" http://grid.3rdrockgrid.com:8002/ "OSGrid" http://osgrid.org:8002/ "NixTech_Forge" http://97.107.142.118:9300/)
EOF
 source $HOME/.grids.db
fi

main()
{
action=$(zenity --list --title="SL Grid Launcher" --text="Choose a grid:" --column="Grids" --column="Login URI" --print-column="2" ${grids[@]:0} "Exit" "Exit")
case $action in
 Exit) exit;;
 *) $viewer --loginuri=$action;;
esac
}

main

================

There's definitely room for improvement, such as the possibility of using an online database of grids and choosing from an autodetected list of clients instead of manually choosing a viewer via file selection. I'll be working on those features, but if you have any other ideas, let me know in the comments.

In development: an external grid selector for Second Life/Emerald

Just a quick post announcing that I'm in the process of writing up a crude, but functional "external grid selector" for the official Second Life viewer, Emerald and Snowglobe. It will be a bash shell script using zenity to create a selectable GUI list of grids. It's written for the Gnome/XFCE desktops in Linux, but porting it to KDE, Macintosh or Windows is trivial. I'll post the code in a future post once it's polished up.