snarlferb/blush

blue shell

blush

Contributing

I'm looking for like-minded people to collaborate with. Feel free to clone and make pull requests as you please. Contributors can create their own branches or use default. We are in the early stages of spitballing ideas, and theres nothing terribly serious going on yet—if you want to get the ball rolling and start a conversation, then i would be delighted to join you in that process.

Preface

I need to have a shell that's as fast as mksh, but w/ some of the same traits as bash (if someone wants to help me test/make comparisons i would appreciate it) The main reason being because i plan to use it while building Linux From Scratch.

Ideas to play with

• Implement the histsearch (otherwise known as "Reverse-i-search") more accurately to how it functions in bash, within the same line; and that way it doesnt submit lines for each character.
• Automatic line editing and buffering, with the ability to recall previous commands from history, edit them before execution, and search through command history using shortcuts like Ctrl+R for reverse-i-search.
• In order to describe some changes appropriately, i have to go over related terms. The term buffer is very much integral to the way the shell manages characters & commands; A buffer (specifically an input buffer) acts as a temporary storage area used to manage and manipulate characters and strings as they are inputted by the user, and eventually, processed as commands. The command history buffer stores previously entered commands and allows you to recall and reuse them. And the display buffer holds the current state of the command line as it appears on the screen.
• Buffering then refers to how the shell handles the input before it's executed. Typically, when you paste multiple lines of code or commands into a shell with buffering enabled, it retains those lines in an input buffer, allowing you to edit or review them before submitting them for execution, and thats one such thing we plan to reshape.
• Commands to consider adding: caller, compgen (maybe), compopt (maybe), coproc, cpio (i just like this command, even as a separate idea), declare (maybe), logout, readarray, shopt...
• Panels: Normal mode should be a simplification upon commands, that is, a constant layer that you have the option of customizing yourself, like Transformed<command> : _B_... The transformed commands being equivalent to a binding target sequence (e.g., "\C-d"), and setting each simplification to the binding action (e.g., _B_ or whatever)—which is for those people who dont like the default ViMode (and would presumably be found in ~/.panelrc) In my head, the panels go by: "xemacs-" (regardless of transpose behavior), "n-", "ins-", "mi-" and "ur-" panel, which may be activated upon pressing Mod+Key or whatever.
• Please bare with me, as ive fried my brain while trying to put this in order. You can use set -o vi which lets you have it enabled in the same way as traditional command shells. Otherwise, you'd have (setw -o npanel or set -o <allpanels>, whichever way it ends up being), which may be setw -/+ o (enable/disable) from a key binding—depending on if we decide it'll switch on the ability to have panels, or if its the panels themselves that are to be set. This implies you can do the same with Insert Mode, so you can choose to switch modes in a new way, or emulate the traditional feel—And wherein it can be set to whichever key (<inspanel> : "\033OP" or "\033OP": "sw_to_inspanel" or whatever it ends up looking like)
• So in other words, you can keep the traditional Vi mode, wherein its disriminated in such a way where it doesnt exist simultaneously as a "Panel", or you can have them enabled/disabled simultaneously (as in an X/O Panel you simultaneously flip, changing that particular layer of binding targets) An error should occur if setw -o inspanel is set without being also being assigned to a particular <Key>, and the same isnt the case for set -o vi, which would be preserving the traditional. And again, this is just the rough idea im starting with so many parts are liable to change.
• There may be a few other things—the only subtlety being that we should try to keep the same vague sense of principles that the original project had; albeit simplified so it relfects the right amount of modernization.
• Once we work on that, then it'll be utilized as the main shell for Linux From Scratch, which i will start making a collection of scripts for in temporary-link

---

pre-alpha - status: almost ready