We have more and more operating systems, but the unix/linux command language tools are the go-to source of basic command line tools for them all. These tools have proprietary and cultural weirdnesses that committed practitioners have mastered and by now constitute a badge of honor or mark of attainment, but make a sometimes formidable barrier to new users. There is room in the world for a more consistent, discoverable and portable command language to build on this stable heritage and constitute a new standard.
This is not dis on GUI. I will say that (I am a dinosaur, therefore) I find CLI more precise, functional and natural than GUI for many tasks. I find it more convenient to use when I’m leaning over somebody’s shoulder to show them something. But I fully admit that your mileage will vary, and am not intending to take your GUI away from you. But I think there is benefit from further investment in CLI.
What’s wrong with linux command line?
I’m proposing changes to CLI syntax for all commands. This is heretical in some quarters, so first a disclaimer. All props to K&R! Long live GNU! They built a large, stable and enduring edifice from pretty minimal components: command line tools, a convention for command line syntax and MAN pages.
But not all OS’s have the same shell, and at least half of the muscle memory that gains you efficiency in these environments comes from shell metachars – pipes, redirection and globbing. And scripts, combining these elements.
All of these tools suffer a common problem – a very lightweight syntax convention that must be implemented “in the spirit of KR” but by different programmers of varying committment and sophistication.
Nothing new to see here
Other computer system families have faced this problem in the past and come up with the idea of a standardized command language then shimming the various tools into a consistent implementation of that language. Specifically, I’m specifically influenced by Digitial Command Language of the ’70s and ’80s, which is what I cut my teeth on. Older practitioners would certainly say that IBM J[E]CL and AS/400 CL dealt with this problem first, and I agree. Computer technology and technologists are now old enough to have to bend to the forces of history. A specific shout-out to Monad and Powershell, which is a more modern take on the issue, from Microsoft this time. I acknowlege the influence of all these precedents and cheerfully set off in my own slightly off-kilter direction.
So, what is it?
It’s a thin shell on top of command line programs. It offers a consistent syntax over “everything”: files, devices, networks, jobs …. It “transpiles” your input into a pipeline of native programs. It might have some builtins of its own. It might have some specialized pipe operators to make tabular data more tractable.
In any case it does not have flow control: you embed these command lines into the shell script language of your choice. I’m initially aiming at (subcommand mode of) Xonsh, because I love Python.
It will have some points of integration for a parent shell: returning the expected kind of exit status for shell flow control; supporting completion for command and syntax discovery.
Many command languages have been designed, most of the form _CL, but apparently no popular one so far called “BCL”. I hereby stake my claim for Bob’s Command Language, BCL.