I have recently become more comfortable with the command line, but for a long time felt like that blinking cursor was telling me “you. remember. nothing. you. remember. nothing.”
I have a visual memory. I can picture a drawing of the water cycle from my fifth grade text book, and I remember that the drawing was on the left side of the page. The command line makes poor use of a visual memory (though setting up the bash shell with some colors can help), and I thought perhaps we could do better.
Ages ago, 2010ish in fact, I imagined a solution, which I called the magical command line. I pictured a series of in-context drop-downs that could guide someone who was less comfortable with this mode of interacting with the computer. For example, when a user typed gi the drop down might suggest git, gitk, git-duet, or any number of other commands beginning with the letters gi.
I also wanted a command line that would auto suggest things that could be found in help documentation (without me needing to type –help again and again). As the user finished typing git and then added a trailing space, the suggestions would auto-update to match the new set of constraints, and only subcommands of git would be suggested.
So, when I type git m, the magical command line would in a context sensitive way, realize that I’m typing a subcommand of git and auto-populate the drop-down with subcommands that begin with the letter m. Notice how the icons and colors change to let the user know they are dealing with a primary or subcommand.
As I select the second option git mv the magical command line now populates the drop-down with two file-picker triggers for both the source and destination file. Different iconography distinguishes the file picker from the regular command/subcommand suggestions.
When I choose source, it opens an OS specific file picker.
Is this still a good idea four years later? I don’t know. I think it would still help beginners and those with visual memories like mine get comfortable with the command line faster. Maybe in the intervening years something like this has already been created? If so, I’d love to hear about it. What do you think? How does your memory work best? Would this tool help you?
Note: Obviously the interaction is heavily inspired by my use of adobe products. I even proposed this to Adobe years ago because I thought it would be a great bridge-tool for designers on the nerdier end of the spectrum, but the PM just smiled and nodded. Maybe it’s actually a dumb idea? I thought I’d put it out there before I nuke this buggy laptop and possibly lose the designs forever.
Photo Credit: Carlos Rios
Comments
27 responses to “The magical command line”
I thought I remembered seeing a similar kind of project in the past six months or so, but all I could dig up was explainshell ( http://www.explainshell.com/ ) which is not even visual… although it is useful.
Definitely a good idea — almost a no brainer — why hasn’t anyone done this?
It would sure make the CLI much more fun. Simple things can make a big difference: command completion, history, etc — all stuff already there for those who remember how the magical keystrokes. Xcode and friends all give us code completion and other helpers.
I wish someone would do this. (Maybe in connection with the iTerm project?)
I think this is an awesome idea!
I’m a software engineer with terminal/shell experience going back 20ish years and this would be really, really, helpful for those commands you just don’t use everyday.
It would probably have to have the ability to be toggled on & off from a keyboard shortcut (the context menu would get annoying if I’m just `git add`-ing files), and it would probably have to be able to parse man files to build up an index… but I don’t think that would be too difficult…
I would love something like this. I’m perfectly comfortable using the command line, but I just have terrible memory so unless it’s something I do 10x a day, I forget the relevant commands.
A few have tried implementing similar ideas in the past (see https://github.com/unconed/TermKit and http://acko.net/blog/on-termkit/), but it’s very difficult to get right. The closest I’ve seen are per-application autocompletion scripts which provide hints, but not in a drop-down format. That’s not at all to say that it’s impossible. Someone would just need to have the time to go prototype it 🙂
I should also mention iTerm2 does some of the drop-down functionality today, but it’s limited: http://www.iterm2.com/#/section/features/autocomplete
This is a great idea! I am also a visual learner and non-technical by trade, although I have been learning how to code with some basic, front-end practice. I think most programmers are non-visual so they have no problem. Making it more visual would definitely make me more attracted to want to learn it. What made me wary of code was the need to have the entire image of what I was trying to build in my head. This would totally change things! I haven’t heard of any changes, but let me know if you find something!
Great idea! Outside of the few commands I have memorized from constant use (git add/commit/push, compass watch), I use Terminal along with a browser window for the necessary CL docs. I would love some kind of visual hint like that!
Something similar to finalterm.org?
As an avid command-line user, the file picker would be a pretty cool (and very welcome) addition.
However, I’m not sure how much of an advantage a drop-down of bash-completions affords, since I’ve been pretty well trained to use to list all completions and to select the completion when only one exists. One advantage that comes to mind is that you wouldn’t end up with extra lines being printed to the terminal to go through the exercise, as long as the “magical command line” would automatically trap the sequence and override the default behavior.
I don’t think this is a dumb idea at all. I know this isn’t the same thing, but if you have “bash completion” installed, you can hit [TAB] once to autocomplete commands, and twice to show a list of all possibilities.
See this short example: http://blog.jeffterrace.com/2012/09/bash-completion-for-mac-os-x.html
It doesn’t always work and it isn’t nearly as visual as the GUI you’re suggesting, but it’s something!
Very useful! Bash has a version of it: http://www.tldp.org/LDP/abs/html/tabexpansion.html
I’m more than sure this should be relative easy to script using the already existing autocomplete features in Bash shells. For example see: http://www.debian-administration.org/articles/316
Hi Nicole!
Hitting tab in bash lets you access some of this autocompletion/suggestion stuff.
Code Insight for the command line! These ideas have been floating around the development community for a long time and they’ve been implemented in various ways. I think several Windows-based implementations have used the Tab key to automatically populate that sort of thing, but IDE’s tend to use Ctrl-Space to bring up Code Insight. Even people who are familiar with the command line appreciate shortcuts and reminders like this, so it is still a worthwhile idea. I would actually be surprised if this wasn’t already implemented somehow…
Hi Nicole, 10 months ago I was contracted on a project to help build a living style guide for a python based project that used svn and git. All the engineers on the team used the command line to work with all of these.
Before this, I really had no cli knowledge, hell I don’t even think I know what cli meant. I was worried I would screw up my computer if I did something wrong in the command line.
Here is what helped me out:
Download and use iTerm instead of Terminal, specifically iTerm2: http://www.iterm2.com/#/section/home
It’s like Terminal except on steroids.
Download and use oh-my-zsh. https://github.com/robbyrussell/oh-my-zsh
This will allow you to have a custom color scheme and a nice theme for iTerm. Being a visual learner as well, I agree that the visuals of Terminal are dismal and boring.
iTerm’s color schemes and themes are 100% better than what you can do in Terminal and add a level of understanding when working with git repos.
Immerse yourself in command line tools. Instead of using a GUI to work with git, force yourself to use the command line. This helped me build my knowledge and made me more comfortable working on the cli.
After working with git on the cli, I started to get into other cli based projects like yeoman, grunt, etc. This helped broaden my understanding of the command line.
Keep a list of common commands. When I first started out I had like 5 or so commands I always ran. I wrote them down and would refer to this list whenever I needed to run them. Soon they became second nature.
Set up aliases for your common commands.
Instead of typing git checkout -b my-feature-branch you can set up an aliases and type gco -b my-feature-branch.
There are a few articles out there on git aliases and shell aliases in general.
Lastly, if you can, work with people who really know the command line well. I work with a ton of engineers and everyone knows the cli. I know that if I feel like I’ve messed something up working in the command line, I can do a google search, or usually quicker, I can talk to one of the other engineers.
So far I’ve stumbled through the command line and have become more and more comfortable in the last 10 months plus I have not screwed up my computer as I feared I would when I first started using the cli.
In regards to opening a finder app of the directory from the command line you can run the following command from your shell to open up the current directory in the finder app.
open .
Sorry for the brain dump 🙂
Hi Brett,
oh-my-zsh is great, but not only useful for themes.
There are many plugins available that could be easily enabled in your .zshrc config file (git, osx, brew, …).
Most of the plugins offers a more detailed auto completion and they already have most of the aliases build in.
One of my favorite plugins is wd, which let’s you jump between directories using self defined aliases. That’s a big time saver.
Here is a list of builtin plugins:
I would pay $5 for this.
It’s definitely worth more, but I would definitely pay $5 for it.
Hi Nicole,
At least the first part of your wish list is kind of built in to bash. If you type a few letters and hit tab, suggestions will be offered to you by the bash prompt. You are limited to executable commands for the first part of the command and files relative to the current working directory for the rest of it. There is not tab completion (yet) for commands. Honestly, git/svn/cvs all are kind of “broken” as *nix command line tools. A “proper” *nix command line tool should not take commands but instead should use only dashed flags. Still, having an autocomplete of any command line tool would be quite nifty I agree.
See http://en.wikipedia.org/wiki/Command-line_completion
I think idea definitely holds up, still.
I often hit twice to see the options available in plenty of commands that I type. Having an auto-complete prompt would be a much more user-friendly way of accessing the information though (and less keystrokes!) We’re also already used to this concept with modern code editors.
I’m not so sold on the file picker idea. I know it takes some getting used to traversing directories in the command line, but it’s nice to not have to context-switch over to the mouse to navigate in the middle of typing a command. Again, is your best friend here. I do however, like the idea of showing which part of the command is next, I always forget which order source & destination are for mv, cp, symlink, etc… (probably because I rarely use them…)
This seems like a genius idea to me. I’m not all that uncomfortable with the command line, nor am I seasoned expert. But I do find myself constantly looking up options and flags for commands that I’ve used in the past. My productivity would definitely improve. Wait, why hasn’t this been made before again?!
Much of this is available for git already, although not with the nice gui popdown.
“`
fruit-loops(master) $ git ch ()
changelog check-ignore checkout cherry cherry-pick
fruit-loops(master) $ git ch
“`
It also is aware of contents of the repository
“`
fruit-loops(master) $ git checkout ()
FETCH_HEAD ORIG_HEAD master origin/master HEAD hapi-2.x origin/hapi-2.x
“`
The git implementation is here https://github.com/git/git/blob/master/contrib/completion/git-completion.bash but this is also extensible so you can have completions for many other things as well.
The gui popup would certainly help keep the scrollback log clear of the bit of noise from the suggestions and even better you could do fuzzy vs. prefix matching, etc.
I would definitely use this for the odd occasions when I drop to the terminal.
As a developer who doesn’t get to code very much any more, the intellisense tools in Visual Studio for different languages are a lifesaver. I jump around various operating systems and IDEs but don’t spend enough time doing any one thing to maintain any kind of muscle memory, so something like this would be a great addition to my toolbelt.
I’m not a big fan of fish, but it does try to auto surgest. Fish = Friendly Interactive Shell
You Know that all of this is available with bash completion and especially for git I seldomly hit more than 2-3 characters before I autocomplete with TAB. Instead of dropdowns (who would want to flip input devices from keyboard to mouse just to clock through a gui file picker btw?) You hit Tab and get a list of suitable completions or it autocompletes ommrdy if there is only one possibility. Same for files/paths of course.
reminds me of the Roo console in the Spring Toolsuite:
https://raw.githubusercontent.com/wiki/hantsy/spring-sandbox/roo-code-assist.png
Great idea! This would be a useful tool, especially for when more visually-inclined users such as web designers need to use something as CLI-oriented as git. Sure, there are front-ends like TortoiseGit or RabbitVCS, but there are a lot of cases with git where you need to put in that one magical line of commands to make it all work…