When I first started working in tech support, I was given a csh and once I figured out all it could do, I enjoyed using it. I found the editing to be cumbersome from time to time, but it was better than retyping everything.
One of my co-workers, Kamal (of IguanaCam fame), was an avid proponent of the Korn Shell. Every time he wanted to show me something on my terminal, he would grumble when he forgot that I wasn’t using ksh. Many times he tried to convert me, but learning a new shell wasn’t high on my list of priorities.
I often complained to Kamal how cumbersome vi was (at least I thought so at the time). One day I asked him for some pointers on vi, because every time I saw him do something in vi, it looked like magic. He agreed with the one condition that I at least try the ksh. All he wanted to do was to show me one thing and if after that I still wanted to use the csh, that was my own decision. Not that he would stop grumbling, just that it was my own choice.
The one thing that Kamal showed me convinced me of the errors of my ways. Within a week, I had requested the system administrator to change my login shell to ksh.
What was that one thing? Kamal showed me how to configure the ksh to edit previous commands using the same syntax as the vi editor. I felt like the csh editing mechanism was like using a sledge-hammer to pound in a nail. It does what you want, but it is more work than you need.
Many different shells have a history mechanism. The history mechanism of both the ksh and bash have two major advantages over that of the csh. First, the information is actually saved to a file. This is either defined by the HISTFILE environment variable before the shell is invoked, or it defaults to .bash_history (for the bash) in your home directory. At any point you can edit this file and make changes to what the ksh perceives as your command history.
This could be useful if you knew you were going to be issuing the same commands every time you logged in and you didn’t want to create aliases or functions. If you copied a saved version of this file (or any other text file) and named it .sh_history, you would immediately have access to this new history. (Rewriting history? I shudder at the ramifications.)
The second advantage is the ability to edit directly any of the lines in your .bash_history file from the command line. If your EDITOR environment variable is set to vi or you use the
To enter edit mode, press Esc. You can now scroll through the lines of your history file using the vi movement keys (h-j-k-l). Once you have found the line you are looking for, you can use other vi commands to delete, add, change, or whatever you need. If you press “v,” you are brought into the full-screen version of vi (which I found out by accident). For more details, check out the vi or ksh man-page or the later section on vi.
Note that by default, the line editing commands are similar to the emacs editor. If vi-mode is activated, you can activate emacs-mode with
If you have been working on the command-line for a while, you may find that the command you input a while ago is no longer in the history. This happens because the shell only stores a certain number of lines (default: 500). If you really need to save more lines, you can increase it by setting the HISTSIZE variable to something like 1000.
You can display the entire history simply by inputting the
Notice that the history command is also displayed. This is simply because the command is written to the history file before it is executed. This also means that mistakes (such as commands that do no exist) are also written to the history.
One exciting thing that bash can do is extend the command line editing. There are a large number of key combinations to which you can get bash to react. You say that the key combinations are “bound” to certain actions. The command you use is bind. To see what keys are currently bound, use bind -v. This is useful for finding out all the different editing commands to which you can bind keys.