shell vs CLI
From Wikipedia, the free encyclopediaUnix Shell:
A Unix shell, also called "the command line", provides the traditional user interface for the Unix operating system and for Unix-like systems. Users direct the operation of the computer by entering command input as text for a shell to execute.
Command line interpreter:
A command line interpreter (also command line shell, command language interpreter) is a computer program that reads lines of text entered by a user and interprets them in the context of a given operating system or programming language.
Doubts
What is a CLI application? Simply a restricted shell. And what is a shell? Think at it as an enhanced
version of a CLI application.
So why programmers still insist to write CLI applications? Why they do not extend the shells to have the
functionalities they require for their CLI applications?
Abstract
It is not too difficult to use a shell as a general purpose development
environment to implement CLI applications. I am a network programmer and
I often, very often, need simple and sometime complex CLI applications,
just to test a new protocol implementation or perform a server benchmark,
or maybe execute a simple units test or to take a look at network bandwidth.
CLI applications for network programmers are the same of shell scripts for
system administrators, both abuse of them.
I will try to demonstrate that if you need to write a CLI application you
could avoid to start by scratch but a well driven hack at your favorite shell
allows you to implement your ongoing CLI application.
For example I did it with the so popular tcsh to implement my pksh.
For several years when I needed a CLI application I started each time from
the beginning, writing and writing hundreds lines of code, until I finally
implemented a private project called gcf (General Client Framework)
containing all that I needed to perform interactions with the user, including
of course command line reading, history and completions using the GNU readline
library.
From time to time I used this common framework to develop each new CLI application
I needed and so I forgot for years how to deal with all the damn jobs of
interacting with the keyboard, but I rather than concentrated my effort on the
application domain.
Over the time I was unsatisfied with this approch mainly because my framework
lacked of fundamental mechanisms such as ability to execute external application
and piping data between them. My first istinct was to learn how to implement
such features from the shells and to re-use their code into my framework. But
unfortunately this job failed mainly because the shells I took a look at were
monolithic programs, often making use of global variables, and they were not
generally implemented as a development enviroment for the C programmers.
In a word the mechanisms the shells implements are not easily re-usable from
the C language in other projects.
But I still needed to embed my specific domains requirements into a shell and
I was really melt with such idea to use the shell as CLI, without the need to
reinvent the wheel in order to inherit from the shell itself all its native and mature
mechanisms, such as piping, built-ins, job control, a command language interpreter,
aliasing, and much more.
So I started hacking at the tcsh to add built-ins for my specific domain,
and now the pksh is exactly what I wanted for years.
Just as an example I did it with the so popular tcsh to implement my enhanced version pksh. Browse hacking link if you are interested to learn more on this issue.
So if your boss ask you to write a new CLI just say him that you will soon start hacking at the shells.
