SECTION_I: {HOW}

ArgStr and ArgInt are a couple of short functions that will take the pain out of parsing through command line args.
Copy these and paste into your app. [Usage Instructions]
 

#define STREQ(a,b) (strcmp(a,b)==0) char * ArgStr(char* aName,   char* aDefault, int argc, char** argv) {   int i;     for( i=0;i<argc-1;i++)     {         if(STREQ(aName, argv[i]))         {             return argv[i+1];         }     }     return aDefault; } long ArgInt( char* aName,   int aDefault, int argc, char** argv) {     char buf[16];     sprintf(buf, "%ld", (long) aDefault);     return atol( ArgStr(aName,  buf, argc, argv)); }

 
 

SECTION_II: {WHY}

It is easy to do things with a CLI program that would be difficult, if not impossible, to do with a GUI. The most common advantage of CLI apps is the ability to run them in a batch oriented mode.

CLI apps often have superior "guts" when compared to GUI apps. What I mean is that the inner workings of the app, the operations hidden from the user, usually work better/faster/more reliably then the inner ops of a GUI app. The reason for this is brutally simple -- the GUI programmer must spend more time on the interface, maybe up to 50% of the development time. The CLI programmer, on the other hand, will spend at most a few hours on the interface, it is so minimal. Thus, the CLI guy has more time to dedicate to optimization and reliability than the overworked GUI guy.

CLI apps are portable by definition. Standard C/C++ was designed with the CLI in mind -- CL args are passed to main through argc and argv, user input goes through stdin/stdout, and file IO is standardized, too. If you write a pure CLI app in C, you should have very little difficulty in porting it to Win3.1, Win95, DOS, Unix, or Linux.

The GUI developer is not so lucky. There is presently no commonly accepted standard for graphic UI. So, If someone writes a GUI app for a particular OS, he or she will have a difficult time porting it over to Win3.1, DOS, UNIX, Linux, etc.
 

Obviously, beauty is a subjective term, and different people have different criteria for beauty. But even a programming paradigm could be evaluated for its beauty quotient.

Which is more beautiful, the GUI or the CLI? I have my opinion, and I'll try to prove it with an analogy (however, don't forget that Bjarne Stroustrup said that "proof by analogy is fraud").

To begin the analogy, let us consider and compare the beauty of two fundamentally similar tools, the first being the Swiss Army knife.

Some may consider the Swiss army knife to be beautiful, with its built-in toothpick, magnifier, tiny little scissors, various blades, and (heh heh) reamer. This knife is a generalist. All things to all people, a jack of all trades... but sadly, a master of none. The magnifier doesn't make things look all that much bigger, the scissors don't do too well with corrugated cardboard, and the reamer... what the hell's that for?

Now let's look at the second tool in this comparison: the razor blade.

A paper-thin shard of spring steel, with cutting edges along both sides, the razor blade has one purpose and one purpose only : to slice through objects of a particular consistency -- and to do it efficiently. It's not very good at picking teeth or filing nails or magnifying or reaming (whatever that is), but it does very well at what it was designed for.

And it's dangerous too. You either use a special holder to keep it from slitting your fingertips, or, if you feel wreckless enough to handle it with your bare hands, you cover one edge with a piece of masking tape and hope that you don't slip.

So, which do you think is more beautiful -- the Swiss army knife, or the razor blade? If you honestly believe that "less is more" the the answer is clear. The blade, like the CLI, with its combination of pure efficiency and raw simplicity, is more beautiful.
 

A properly designed CLI app is modular, almost like a function. You can call it, pass it some args, and it returns a value to stdout or into a file. It is even possible to call CLI apps from within a C program as if they are functions, through use of the Standard C system call.

For example, say you wanted to perform a spell check on a file from within a C program you're writing. You can use the UNIX spell app in conjunction with system as such:

       system ("spell myfile.txt > myerrors.txt");

This call will scan through myfile.txt, find any spelling errors, and put them into myerrors.txt, which is then usable by the same program.

I dare any Microsoft fans to come up with an example that calls Word's spell checking facilities from within a simple C app.
 

Finally, the real reason one should write CLI apps: they're easy! Spend your time programming for the CLI and ignoring the GUI, and you'll definitely get more programmatic bang for the buck.
 
 

[To Parent Directory]