These are some messy things. If none of them can be separated into segments, join them together. It should be said that these messy things should be put at the end to get a chapter similar to a glove box, but since most of these messy contents are related to historical commands, let's put them together for a moment.
The repeat of the two commands is mentioned in the previous historical command Editing Section. One is the repetition between different instances of complex applications, the other is the repetition of complex commands on different systems and machines. The reuse of Bash's history command function in the latter type of command can be totally overwhelmed. After all, shell is powerful, and can only be used within one session range of one machine. In fact, even on a machine, as long as it is between different shell sessions, the history command function of Bash has become powerless.
What should we do? In fact, there is no difficulty. This is not a problem for many people. As long as the command is copied between different terminal of X Window, it is OK. It looks simple. However, for me, this countless copy and paste operations is a big problem. You don't have to agree to my point of view, but think about the huge number of days that day after day, you will feel some of my feelings. The two copy and paste operations once and twice and the ten thousand and two copy and paste operations are totally different. Quantity. The quantity can be changed to many things ......
So we respect the quantity. I need to use Emacs to solve this problem. The specific method is nothing magical. After all, you still need to copy and paste it. This is a curse that cannot be escaped. The only thing we can do is find a way for Emacs to deal with these annoying tasks.
So there is an extension called jump. Jump is a cute guy. Most of the time, when I run a complex command on tivhpi03, to avoid typing it again on tivvm273, I will enter M-x jump, then, this command will jump to the shell-buffer of tivvm273 and appear after the current shell prompt.
Let's take a look at the specific code of jump. The code is actually very simple. It is nothing more than getting this historical command, jump to another window, and then paste the command. It turns out that I jumped to another window, located at the bottom of the shell-buffer, and directly pasted the command behind the shell prompt, later, in order to be more general (in fact, I often used the jump command in non-shell-mode), I removed the code to the end. Usually in the shell-mode environment, the cursor position is mostly behind the current shell prompt. So the impact is not big.
Because this command is very commonly used, I bound it to the Ctrl-C j key combination.
Another thing is actually a very interesting question. What is the problem? Screen output. Didn't you think of it? Not only historical commands, but also historical output. Why? In software quality testing, terminal outputs not only command execution results, but also evidence in the software quality issue report.
When it comes to this, someone may think that it is important, and the output is there. But just think about it, is it that easy? Well, I tried to answer one of my questions. When you just caught a very large log and someone came to you to check the results of a command you ran before, what should you do? There is no visible content in the scope of the upstreaming screen, and all the capacity is covered by the log. What should I do at this time? In fact, this situation is quite common in software quality testing. When you find that an application has a problem, you must check the log or even read several logs to find the problem.
At this time, you still need Emacs shell-mode for help. As mentioned above, Emacs is a text editor. The workspace in the text editor is a variety of buffers, and shell-buffer is also a buffer. This buffer contains all the commands input and output information in this shell session. All are the keywords here. Once a log is cat, it will no longer overwrite the previous command and output information from the original terminal. When your day's work ends, if the content is important to you, you can also save an article or code, save the shell-buffer of Emacs as a file for later use.
Speaking of this, let's review the log problem mentioned below. Although the historical commands and historical output will not be washed out from terminal due to the log content, but these endless log contents occupy space here is indeed an inconvenient thing. Can we clear it from the screen? In fact, emacs has long considered this issue. The shell-mode of Emacs provides the comint-delete-output command to delete all the output of the previous command. In Emacs shell-mode, this command is usually bound to the Ctrl-C Ctrl-O key combination. In this way, after reading a log, you only need to enter the Ctrl-C Ctrl-O key combination to convert the output content that is in the way of such a line.
Yes, as shown above, because of the existence of this command, even after ls has a relatively large directory, you can also use ctrl-C Ctrl-O to delete the read content. From then on, your screen will become very clean, and only those truly valuable content will occupy the screen space, and will have a place in the saved buffer file.
However, the embedded Emacs command is the same as the bash ^ command, and there is a scope of impact. Comint-delete-output can be deleted only by the command that has just been executed. In other words, if you habitually execute an LS-LTR after CAT logs, then you will find that "a cut is too late ...", Comint-delete-output can no longer Delete the log Content you want to deal. Of course, there are solutions. Isn't it a buffer? Check the beginning, select the end, and delete the middle. It is no different from all other buffers. To say so, it is not too troublesome to do so every day. So I expanded a new command myself. This command is used to delete the output information of the "previous" command that comint-delete-output cannot handle. The name of the command is "some". It was just because I didn't think about what it should be called when I expanded this function. After a while, I found that some of the commands were already used, so there is no change in name.