Human Interface Guidelines for Command Line Applications

Human Interface Guidelines for Command Line Applications. I've always wished that Command Line apps were a little more usable. I think that a few guidelines, if followed would make the command far more approachable and intuitive. The GNU habit of using single dashes for abbreviated arguments and double dashes for full text is handy, but can often be confusing when described in man, info and simple descriptions. I am sure that there is documentation on these design standards for GNU tools, but until I find it, I wanted to post these ideas, based on what I have found useful in the command line apps I have used. * All programs, when run with no arguments, should not execute but display a simple description and list of common commands.
Example:

$>foo Description:

foo is a sample application meant to serve as a example of proper command line behavior.

Examples:

To start foo: foo --start
To start foo with a file: foo --start filename.ext

* When running in a non-interactive manner, a command to stop the program should be displayed.
Example:

$>foo --start
To stop foo, press control+x at any time.

* If the program is passed an argument that it does not understand, it should produce a "friendly" error message and display the simple description.
Example 1:

$>foo --bar
foo does not understand your request to "bar"
Description:

foo is a sample application meant to serve as a example of proper command line behavior.

Examples:

To start foo: foo --start
To start foo with a file: foo --start filename.ext

Example 2:

$>foo bar
foo could not find a file named "bar"
Description:

foo is a sample application meant to serve as a example of proper command line behavior.

Examples:

To start foo: foo --start
To start foo with a file: foo --start filename.ext

So whats up with the name Sunergos anyway?(Pt.2)

I mentioned in part one that Sunergos was supposed to be an operating system. That's not completely true, but we'll stick with that for now. I didn't describe exactly what Sunergos was meant to be, and there is one reason for that: Mission Creep. It is the bane of all project leaders, even when that project is naught but vaporware.

Initially, Sunergos was born on windows, when I worked for a tech support company and nearly every application I used was web based. At this point, I'd had almost five years of web development under my belt. After setting the windows shell to use Internet explorer, I set about creating an interface for all of the resources I used for my day to day work. With that an idea borne of a bit of ambition, normally absent from my psyche, reared it's ugly head: A browser-based desktop. Not a new idea, I know. but in that idealistic turn of the century, it was certainly something I had never seen.

Working on a windows based platform (first 98, and later 2000) posed some serious stumbling blocks, not the least of which was the availability of free information. While I was far from an expert with *nix, my experience with Openbsd and later Mandrake 7.2 led me to the (correct) assumption that the open source community was the ideal outlet for this nearly all consuming idea. With an open source operating system as a base I could customize the entire environment, tuning everything to my purpose, and distribute the whole thing.

This put me at a serious disadvantage, though. As I have previously indicated, I had limited experience with this environment. However, that great electronic oracle-- the Internet-- could provide all that I needed and I set myself to achieving a state of complete saturation with my newly adopted obsession. Unfortunately, during my journey toward enlightenment, to a zen like oneness withTeh Source, the infamous bubble did it's infamous bursting. Instead of using my new-found free time to advance my cause, I took more of a chicken little approach and started stockpiling rice, beans, and 12 gauge ammunition...

Hmm, starting to get flashbacks here. I'm going to go and make some plywood squares to mount over my windows, clean my guns, and check the canned food stocks. But, I promise to be back soon for another exciting installment of "What the Hell is Sunergos." Now that the history is essentially explained, I can cover some of the stolen inovative ideas that, when combined, would have made Sunergos "The Best OS Ever"

Like a Rare Jewel

So, I've been looking at Ruby on Rails for developing a combination blog/wiki/forum/cms solution. Seeing as I am a poorly expereinced programmer, Ruby was an obvious choice. This is seriously a... well, for lack of a better word, Zen programming language. For anyone who interested in an incredibly easy to learn language that still has the power to take over the world, I recommend Ruby. It is well documented and portable enough that I will give you a personal money-back guarantee that it will work on your computer. There are many resources available for free, as I have come to expect from open source projects. I have included a quote from one that I am enjoying far too much for it to actually be programming "manual."

why’s (poignant) guide to ruby :: 2. Kon’nichi wa, Ruby

Pretend that you’ve opened this book (although you probably have opened this book), just to find a huge onion right in the middle crease of the book. (The manufacturer of the book has included the onion at my request.)

So you’re like, “Wow, this book comes with an onion!” (Even if you don’t particularly like onions, I’m sure you can appreciate the logistics of shipping any sort of produce discreetly inside of an alleged programming manual.)

Then you ask yourself, “Wait a minute. I thought this was a book on Ruby, the incredible new programming language from Japan. And although I can appreciate the logistics of shipping any sort of produce discreetly inside of an alleged programming manual: Why an onion? What am I supposed to do with it?”

No. Please don’t puzzle over it. You don’t need to do anything with the onion. Set the onion aside and let it do something with you.

I’ll be straight with you. I want you to cry. To weep. To whimper sweetly. This book is a poignant guide to Ruby. That means code so beautiful that tears are shed. That means gallant tales and somber truths that have you waking up the next morning in the arms of this book. Hugging it tightly to you all the day long. If necessary, fashion a makeshift hip holster for Why’s (Poignant) Guide to Ruby, so you can always have this book’s tender companionship.

You really must sob once. Or at least sniffle. And if not, then the onion will make it all happen for you.

For more fun and games, I highly recommend why's blog as well.

So whats up with the name Sunergos anyway?

It was never a nickname for me, although it has become one in some circles. Sunergos is a Greek word that I originally came across when looking for a synonym for the word synergy. Sunergos is the name of a Linux distribution that has been cooking on my back burner for the better part of a decade. I have no illusions as to my abilities as a programmer or *nix guru, so I have done little work on the Sunergos distro outside of theoretics and high-level planning. A few recent articles have put Sunergos back toward the frontal parts of my brain. While I doubt that I will ever see my baby birthed, I would at least like to share my vision with the rest of the world. So, over the next few days, I hope to describe some of the features I wanted Sunergos to have, as well as the articles that inspired my sense of rejuvenation. I have a feeling that logic behind my choice of a name will become self evident.

Make working flash with free tools

While this has been in the news a bit, I decided to try my hand at ActionScript recently and felt I would pass on my findings. There is an Eclipse setup (I am told) for flash development, but the massive IDEs aren't really my cup of tea, So I have found a few tools that may be of help to like-minded seekers of curiosities. First stop should probably be the Open Source Flash project at http://www.osflsh.org/ This is the holy grail of OS flash resources and where I found links to swfmill, an xml to swf and swf to xml processor, as well as the Motion-Twin ActionScript 2 Compiler, better known as MTASC. Both of these tools are available in Windows, Linux, and Mac versions. For more information on setting up these tools for flash development, see "How to structure and set up a Flash project without using the Flash IDE" on the OSFlash site.

A rose by any other set of bits

I always wondered what was up with character encoding and I found an excelent article that explains how different encodings work as well as their various origins. While it is geared more towards developers, It shouldn't be hard for anyone to grasp the concepts that are explained within. But, rather than rehash someone else's work, I'll just give you a link: http://www.joelonsoftware.com/articles/Unicode.html