Wanting to give byobu a looksee as a screen 'update' of sorts. I start it with
byobu
and instead of the status line sitting at the bottom of the screen, everytime it updates it pushes to an additional line underneath the previous one. before long, the screen (putty) is filled with status line echoes.
How do I stop this?
running puttytray v0.62 on win7 to ubuntu 12.04
Putty defaults to a translation encoding of ISO-8859-1 where as Ubuntu sends out UTF-8 encoding.
Click on your server in the Load, save or delete a stored session window. Then click on the Load button.
Next, in the Category panel on the left click on:
Window -> Translation
Change the drop down under "Received data assumed to be in which character set" to UTF-8.
Once you do that then click on Session in the top of the Category panel and then click on save in the stored sessions area.
I am not saying this is the correct fix. I am just telling you all what fixed it for me without having to do any crazy stuff to the server.
Cheers!
This seems to be an issue with the default byobu backend. By default, byobu in Ubuntu 12.04 uses tmux as the backend. You can change this by running byobu-select-backend and selecting screen (option 2).
While not a solution as to why tmux is doing this on PuTTY sessions, it fixes your issue for the screen scrolling.
The UTF-8 setting works wonders. I usually set this together with Terminal => Keyboard => "Function keys and kepad" from "ESC[n~" to "Xterm R6" and save it as default configuration in Putty. That last option enables the use of the F key functions in Byobu. It's pretty much useless without.
I had a similar issue on a debian Testing/SID server, and it was an issue with several detached screen sessions loose on the system. ps aufx |grep -i screen should find orphaned screen sessions.
I tried sudo byobu-select-backend and tmux is the default on Debian Testing as well, I chose 'screen' but when I tried $ byobu the same scrolling behaviour ensued.
So I ran $ byobu-select-backend as my regular user and selected 'screen' again.
This time, running byobu showed me the detached screen sessions, so I could select them and shut them down gently.
#phanku's answer, namely that the terminal's encoding should be set to UTF-8, allowed me to fix the same problem that the OP described when accessing a byobu session (on Ubuntu 12.04) from a Mac OS X iterm with the help of Michael Hendrick's post that describes setting iTerm to UTF-8:
menu: View -> Show Session Info
Session tab: change Encoding from "Western (ASCII)" to "Unicode (UTF-8)".
for me the problem was related to how compatibility was set:
in the terminal, go to:
right-click, choose 'profiles' > 'profile preference'
choose the 'compatibility' tab
change 'ambiguous-width characters' to 'Narrow'
or
just click on the 'reset' button
it worked for me ...
I use iTerm2 in macOS and run into the same problem. The encoding is already set to UTF-8 but no help. Here's the solution that works for me:
Open Preferences > Profiles
Choose the profile with the problem
Go to Text tab on the right
Uncheck the Treat ambiguous-width characters as double width option
Done.
Related
Scenario
From a Windows 10 Anniversary Update client ...
Open a web browser, copy / paste some text from a website (eg. GitHub)
Use PuTTY 0.67 to SSH to a Linux VM (eg. Ubuntu 16 Xenial Xerus)
Open a file in Vim
Hit i to change into Insert mode
Right-click to paste the clipboard contents
Issue
Unfortunately, when I right-click in the PuTTY session, rather than pasting clipboard contents, what's actually happening is that Vim is going from INSERT mode to (insert) VISUAL mode. I don't think I've ever seen anything like this before.
Question
Does anyone know why this is happening, and how I can paste my Windows client clipboard into the SSH / Vim session?
It appears that this issue is due to a change in defaults for VIM version 8.0 and higher.
Previous versions had mouse mode turned off (mouse=), but the new default is mouse mode turned on (mouse=a).
There are 3 ways to deal with this situation:
Adapt to it: With mouse mode turned on, the new way to paste is shift-right-click (at least in PuTTY)
Change it: You can turn off mouse mode for your current VIM session by typing :set mouse= and <enter>
Revert it: You can override the new defaults by calling VIM with the "C" switch (vim -C {filename}) and it will revert back to the Vi "compatible" settings for that session
Of course you can always add set mouse= to your .vimrc file to make it permanent. But that doesn't work for me because I hop around on too many different systems.
I solved this problem by turning off mouse mode.
:set mouse=
I faced the same problem
You just need to change in the vmrc file
vim $HOME/.vimrc
set the following in the file
set mouse-=a to .vimrc
It worked fine
Just like this:
How can I get this?
open emacs and toggle-frame-fullscreen
click C-x 5 2 create new frame
then toggle-frame-fullscreen again
Known Issues & Solutions:
It seems like a bug, with frame as tab GUI, the buffer text rendering may suck...
I didn't install tabbar package.
Hammerspoon may be suitable for this.
Ran into the opposite issue. As it happens, Emacs on my laptop would create a native macOS tab wherever make-frame-command (C-x 5 2) is called. Strangely enough same was not happening on my desktop.
Turns out the culprit is System Preferences->General->Prefer Tabs settings.
When set to the default value of "in full screen", make-frame will create tabs only in full screen. Other options are "always and "never". Turns out my laptop was set to always.
Since does not always make sense for the default behavior of Preview and Emacs to match, the following lines in ~/.emacs.d/init.el will prevent tabs from being created.
(setq mac-frame-tabbing nil)
There are also mac-move-tab-to-new-frame and other mac-... commands to deal with native tabs.
I use iTerm2 as my terminal on OS X. When I SSH into a machine, I like to name my tabs by going into the session preferences (cmd + i). Whenever I run another bash command after setting this preference, the tab title goes back to the default that it was when I first SSHd in.
Browsing around for an answer, I found this answer by Chad that is working for me:
export PROMPT_COMMAND=''
echo -e "\033];MY_NEW_TITLE\007"
I don't really understand the PROMPT_COMMAND line, though I tried looking it up.
Can someone explain this in simple terms?
Same question for the 2nd line, as I don't even know how to begin researching that.
To keep the original tab:
Go to Iterm's Preferences > Profiles > Terminal
Uncheck "Terminal may set tab/window title"
Now you can name your tab, ssh into a server, exit and still keep the original tab name.
Credit to: https://groups.google.com/forum/#!topic/iterm2-discuss/czV-sv4ykzI
You can read iTerm2 escape code .
I didn't read the related iTerm2 code thoroughly, but it seems like an interface to manipulate iTerm2.
I guess iTerm2 does this magic by parse the output of screen if the contents fit special format(start by "\033]" and so on), iTerm2 will consider that's the information mean to sent to itself.
I used tabset node plugin. It works like a charm, and also color codes each tab, and has multiple options to color code, add a badge and even bring up a color picker to choose.
On OS X 10.10 (Yosemite), the keyboard shortcut to paste the clipboard Command ⌘+V behaves like Page Up.
Right now I'm able to reproduce this issue only in Mail and Evernote.
Pressing Super+v, Super+v does pageup, paste though.
I use Karabiner to remap some keys, but never Command ⌘ keys.
If I close Karabiner it doesn't change anything.
I have at some point used vim, the pbcopy terminal command, and some OS configuration from https://github.com/mathiasbynens/dotfiles/blob/master/.osx
But I don't see why this could be a problem.
Does anyone know how to fix this or why it happens?
Are you able to replicate this issue in multiple users on your machine? If so, then the issue is likely to have something to do with the modifications you outlined above (such as Karabiner or Vim), or some larger operating system related issue.
If you're not able to replicate the problem in multiple users, it could be related to a problematic preference file. If you open a Finder window and navigate to ~/Library/Preferences, you could try moving the com.apple.HIToolbox.plist to your Desktop, logging out, then logging back in and testing again.
Let us know if either of those suggestions help!
I'm trying to use the new iTerm app on my Snow Leopard Mac, but my Ctrl seems to be completely dead (as in non-responsive, as in nothing happens when I type Ctrl+a except for an outputed 'a') and I haven't found anything useful while googling. The closest match was this thread here on stackoverflow, but everything in Terminal.app works as it should.
And, even more strange - I can Ctrl+z myself out of applications, but I can't save files in Emacs (C-x C-s) or any other keyboard shortcuts that uses a Ctrl shortcut. And it's not local, since Ctrl is as broken on my iMac as it is on other unix computers I've sshed onto with iTerm. I've tried both in bash and zsh.
I've tried to remove all files concerning iTerm.app in my ~/Library/Application Support, and I've tried the very latest version (currently 13 h old) of iTerm I could lay my hands on, but to no avail.
Any ideas?
This seems to be an iTerm bug.
You can work around it by creating a key mapping in the profile settings.
Add a mapping for ^x so it sends 0x18 (which is the encoded form of ctrl+x).
I suggest to check this post to see if the ctrl key is enabled in your preferences
https://apple.stackexchange.com/questions/52041/how-to-press-control-key-on-mac
Did you try to configure key bindings for this terminal emulator as specified in the iTerm wiki:
http://code.google.com/p/iterm2/wiki/Keybindings
at last, have you try set -o emacs or set -o vi?
If it works, set it in your ~/.bashrc to run it at login.