Is there any way, using Tmux or anything else, to get a terminal that keeps a one-line string of text, a sort of banner, at the top?
In other words, I'm just looking for a way to set the first/top line of my terminal to a string but otherwise have an ordinary terminal.
There is no feature in tmux as such but you can get what you want by using a combination of terminator and tmux.
Related
I have a problem that is my backspace works in the terminal but not in Vim. It sent '^?' instead of '^H' and I have been trying to figure it out. I have checked my .bashrc and there is stty erase '^?' to remove the '^?' but somehow it is not working.
I have this in my .vimrc:
set backspace=indent,eol,start
set backspace=2
fixdel
This is how I would normally fix it according to my knowledge but it doesn't work in this case. I'm using xterm on Arch Linux server if that helps, I know there is a bug for xterm but I don't think that's the case. It works in Unix command but not Vim, so just the Vim that isn't working.
Any help is greatly appreciated.
Edit:
Um to clarify, I just want my backspace to delete things. My backspace doesn't delete things right now and it is giving me ^? instead of deleting. The deleting is the same as any other system that is ^H but I want to make backspace to send ^H which is delete not ^?. So instead of having to type ^H to delete, I want to do it with backspace, on MobaXterm there is a function that makes backspace to send ^H. But how do I do that on SSH?
Thanks
There's two ways to go. To the left, you see the control-H character you crave. The path that way seems clear, just a little
echo xterm.vt100.backarrowKey: true >> ~/.Xresources; xrdb ~/.Xresources
followed by either restarting all of your xterms, or pressing control and your primary mouse button on each window to bring up the menu that lets you change it per window; the menu item itself is the second one in the third section, it's right under the 8-bit controls option. That way seems to be viable. Except, beware, there's a trap door under the control-H itself, as then backspace stops working properly everywhere else except bash itself. Of course, you have part of the way out of that maze already, with your stty fu. But I kind of recall running into all sorts of other issues with that path. One of them being that the Linux console also uses ^? instead of ^H, and that's not so easy to change.
Or, the other way is to get vim to be able to do what you're trying for, using ^?. Which I think is just
:map ^V^? x
Note that I mean control-V backspace, not caret V caret question. You would also want to add this to your ~/.vimrc if that does what you need. That having been said, you didn't say exactly where in vim isn't working quite right, so it's possible you're needing a different tweak instead.
I personally hate having to go down to press the up-arrow-key when I want to repeat a command on the command line.
Is there a way to have map a bash alias to pressing the up-arrow-key? Or something that's also as convenient? I would like to just press 'n' then 'enter' instead of 'up-arrow-key' and then 'enter'
By default, bash uses the emacs keybindings. Ctrl-p and ctrl-n (for previous and next) do the same as up and down arrow.
To view and edit interactively, bash gives you the builtin bind command. help bind shows you usage, and, for example, bind -P shows you all the current bindings. Any remapping you do can be put into your .inputrc file for next time.
Also, bash provides what it calls HISTORY EXPANSION, similar to what was present in older shells. Just type !! and hit enter to execute the previous command. There's an entire section in the documentation with extra features.
Finally, I'll note that if you are repeating commands so often that hitting up-arrow enter is annoying, you might consider writing a script to do whatever you're doing.
You can issue the command set -o vi, or add it to your startup file. Then, you can hit the escape key and use the movement keys from vi to scroll. You can use k to scroll backwards, j to scroll forward, and h and `l' to move left and right.
I am using script to record a terminal session. However, inside my recorded text file, the text input and output is interlaced with strange characters that look like:
^M^[[K^[[A^[[C^ $vim session ^M
^[[?1049h^[[?1h^[=^[[1;21r^[[?12;25h^[[?12l^[[?25h^[[27m^[[m^[[H^[[2J^[[?25l^[[21;1H"session"
[noeol] 3L, 855C^
I think these correspond to return keys and other keyboard commands. Is there a way to not record these during a script session?
In the example given,
^M^[[K^[[A^[[C^ $vim session ^M
^[[?1049h^[[?1h^[=^[[1;21r^[[?12;25h^[[?12l^[[?25h^[[27m^[[m^[[H^[[2J^[[?25l^[[21;1H"session"
[noeol] 3L, 855C^
you have a mixture of cursor-movement and other escape-sequences. The ^[ is the escape character, and ^M is carriage return. As noted, script records everything sent to the terminal, and full-screen programs such as vim will always use these escape sequences. For instance, picking it apart
^[[K
clears the line,
^[[C
moves the cursor,
^[[?1049h
switches the terminal to the alternate screen,
^[[1;21r
sets scrolling margins
^[[?12;25h
sets modes (12 for blinking cursor, 25 to ensure the cursor is visible). Oddly, vim next stops blinking the cursor, resets video attributes with
^[[27m
^[[m
^[[H
before moving the cursor to the upper left
^[[J
and clearing the screen, and then hides the cursor again before
^[[21;1H"session"
[noeol] 3L, 855C
jumping to the lower left of the screen and printing a message (for reference, XTerm Control Sequences). So there is a lot going on, and it is not simply printing the screen left-to-right and top-to-bottom.
Since you are using script, it captures the output into a "typescript" file. If you want to filter those into readable form, a pager such as less using its -R option works passably well—but it misses things. The terminal emulator (with the same screensize) is the best way I know to filter the results, e.g, using a program which sends the characters to the terminal slowly. If you want plain text, select/paste from a replay (using ^S and ^Q to stop/resume) might be a way to go.
A UNIX terminal has two modes, canonical and non-canonical (also known as 'cooked' and 'raw').
The script program works by inserting itself into the message queue stack between the terminal driver and the shell (that's simplified).
The shell thinks it is talking to a terminal when it is talking with script. So what you see is what the shell sees, the raw terminal characters.
Try strings typescript
When typing a (long) command in the bash shell, if you were to make a mistake early in the line, is there a way to correct that mistake without having to navigate back to it? For example, lets say you have just entered something like this, but not yet pressed return:
git commit =m 'Some really long commit message, perhaps spanning multiple lines'
where you have accidentally typed = instead of -, would it be possible to append something to the end of the command before you press enter that would perform an in-line substitution to correct the mistake? This would be really handy to avoid having to do something annoying like
Pressing Ctrl+C and then rebuilding the command using a combination of copy and paste.
Pressing the left arrow a huge bunch of times so that it can be corrected before pressing enter.
One solution (in theory) would be to pipe the contents of the whole command through sed, however I am not sure how to capture the command as a string of text that could then be used in this manner.
What I would do : ctrl+a
then move the cursor after the =, then hit ctrl+w.
The latest delete the previous word.
Multiple shortcuts can help here:
Use ctrl+a to go to the beginning of the line
Use alt+b and alt+f to move forward and backward one word at a time
Use alt+e to open an editor ($EDITOR) containing your current command, edit it, then close your editor.
I'm very fond of vim and really would like to enhance my bash experience with vi-mode. However one thing I'm so accustomed to the emacs behavior in that, when browsing the shell history with cursor up/down, the cursor is positioned at the end of the line.
In vi-mode it's the other way around; the cursor is always positioned at the beginning of the line. It's really burned in the brain to expect the cursor at the end, having used bash in emacs mode for ... way too long.
Any chance to get the cursor position by default at the end of the line in bash vi-mode when browsing through the shell history?
You need to remap the up and down cursors:
bind -m vi-command '"\201": previous-history'
bind -m vi-command '"\202": next-history'
bind -m vi-command '"\203": end-of-line'
bind -m vi-command '"\e[A": "\201\203"'
bind -m vi-command '"\e[B": "\202\203"'
This will map previous-history, next-history and end-of-line to non-existant keys, then map up and down to a sequence of those characters. You can do the same for j/k if you want, but I'd recommend leaving them alone. That way you can do both.
This only remaps the keys when you are in command mode. On my machine, the cursor is already at the end of the line in insert mode. If this is not true for you, you can do the same using vi-insert instead of vi-command as the keymap.
I don't know of a way of doing this short of re-coding the history code inside of bash (or readline, really).
However, is it really so hard to enter Shift-A once you've found your line to start appending at the end?
If you're going to ditch emacs mode then, at some point, you're going to have to do it totally and accept the vi way of doing things. Join us, you know you want to :-)