YOSH command shell

The Project

Ever since I started using Linux back in 1996 I've preferred command-line environments over purely graphical ones. However, the current command-line interfaces (CLIs) are poor user environments and are seriously in need of overhaul. A lot of progress has been made in graphical environments but few of these improvements have propagated to the command-line shells. Perhaps CLI users are thought to be strict traditionalists, or CLIs themselves are thought to be inherently inferior and thus unworthy of updating: really, I don't know exactly why this is the case. But personally, I believe CLIs still offer significant potential advantages over GUIs, especially for users who want a high degree of control over their machine. I've thought for a long time about what a modern CLI should be, and it is my hope that I can make the CLI a good environment for myself, and something other people will use, too. I'd love to see it become a standard in Linux distributions, and supplant older shells in popular use, and help to popularize the idea of a powerful and comfortable CLI command shell as part of a modern operating system.

Meditations

• "The Unix Way" - what it does right (and wrong)
• Command Line Antipatterns - The real-world results of efforts to make CLI programs easy to work with without improving the underlying CLI.
• What does the GUI approach teach us?
• Common OS Features I'd Like To See Die
• What is a CLI shell?

New Shell Design

In order to reach my goal of a modern command shell as a friendly, interactive programming language with the whole system as the language's "environment", I've devised the following specifications for YOSH:

• Built-in datatype system with numeric types, symbols, structures, objects, etc. Where traditional UNIX shells create a shell programming environment where commands are linked together by text streams, YOSH will link programs together using structured data.
• Enhanced data display and browse features: Because YOSH is intended to deal in data structures rather than text streams, the processes for displaying this data to the user become more important. As a result, I believe YOSH and any related front-ends should incorporate features allowing the user to scroll through data lists and expand or collapse data trees in the display.
• Native serialization formats for data represented using YOSH datatypes, to allow YOSH data to be stored, retrieved, piped between commands, etc. with relative ease
• Extendable class hierarchy for describing and interfacing with different filetypes
• Extended calling interface for YOSH-compliant programs. Programs written to work with YOSH will be able to read and write YOSH data structures, cooperate with command-line processes such as tab completion, act as persistent objects, and so on.
• POSIX-friendly syntax: I don't believe that all I want to accomplish with YOSH can be made to work within the constraints of the POSIX command shell specification, but I do want to create an environment to which people accustomed to these environments can readily adapt.

Design Discussions

• Rich Datatypes without Datatype Fascism: The basic idea of the YOSH shell is to introduce a richer set of datatypes to the command shell and the programs that run in it. Some people who I've discussed the idea with have assumed that this means that programs that would operate in this environment must communicate in a common data format mandated by the shell. In a sense this is true: but the key idea is that programs must use some common format to identify how their data is encoded: it is not necessary that the programs actually change how they encode their data.
• YOSH Syntax Concepts: A basic overview of the ideas upon which the YOSH design is being built.

See Also

• fish shell: I would classify the fish shell as a kind of cleanup of the traditional UNIX shells: it has some nice features and generally strives to be user-friendly. I'm working on a review of it, which you can read here.