Archive for December, 2017

CLI for development tools

Command Line Interfaces (CLI) are pretty common on UNIX and UNIX-like systems. It can be intimidating for casual users of computer systems but the power and abilities of such interfaces cannot be denied. The scripting capabilities and the almost seamless ability to chain together a couple of small programs to automate processes makes for an interesting process that creates and evolves an efficient system overtime.

It is worth noting that most of the CLI programs/tools, on the platforms that have supported them historically, are quite memory efficient. If there is a feature on a CLI program but also exists on a graphical user interface (GUI) program, it is a better bet that memory management is better on the form.

Over the last decade or so, Windows has been making an effort to improve the CLI capabilities that exists on their platform. However, since CLI has not been a central focus of Windows since their departure from MS DOS, you have an extensive number of GUI based management and scripting tools that were primarily geared to “enterprise” editions of Windows. That historical move spawned the certification exams to prove to enterprises that they are dealing with qualified people while spawning script kiddies on the consumer end of that spectrum.

The creation and introduction of PowerShell seems to have provide an opportunity for Windows to restructure it’s internal architecture while also improving the CLI experience on the platform. Of course, PowerShell taps into the clean and consistent architecture that the .Net framework has been gradually encouraging across Microsoft platforms. The Win32 API was so ubiquitous that VBScript becomes an essential construct for scripting in the enterprise but that also means that if you can code of ASP (Active Server Pages) and ADO (Active Data Objects), you can probably write and/or understand a script for AD (Active Directory).

A historical context here: while many people who remember the introduction of Java and the many marketing monikers of “Write Once, Run Everywhere” may have thought of the .Net framework as a chance to make a version of that architecture for Windows and By Windows, the truth is that it was a better way to structure the platforms owned and run by Microsoft.

The much I have been reading and understanding of the CLI features on Windows has the inclusion of WSL (Windows Subsystem for Linux). The first time I experience the command line interface, I actually wanted to know how has the core OS (operating system) has changed to allow this to work and what and how security protections flow across radically different architectural designs.

There still seems to exist, as an effort to provide superior CLI experience on Windows, without seamlessly jumping back to a GUI. That was one of the reasons, I was searching for command line IDEs/text editors … over and beyond syntax highlighting.

I was hoping to run some of them on WSL.


1 Comment