I'm having an issue with getting tmux to perform as I'd expect. I only learned about it today, so it'd be really helpful to get an explanation of what is going wrong.
Overview
I go to my terminal and type tmux new -s test_session to create a new session with a name. Once in the tmux session, I activate a conda environment, but the next part is where my problem lies. I want to exit (or, I guess, "detach") from the session, such that the session is running even when I don't have it up in the terminal window. I try "exit", but don't get a response. I try Ctrl+B, D (Ctrl and B together, then D) to "detach" as well. When I use this command, it does return to my regular terminal window, but when I type tmux ls, I get no server running on /tmp/tmux-2017/default.
To the best of my knowledge, I'm following the instructions as giving to me by a coworker and several online sources, but nothing I do prevents the session from terminating once I detach. Please help me understand what I'm doing wrong.
TL;DR - Can't exit tmux session without terminating it.
Each command in tmux is preceded by the Ctrl+b keystrokes, and then followed by the keystroke for the tmux command. But what written cheat sheets and tutorials seem to assume is that the reader is going to understand that the tmux commands are case-sensitive.
For example, in one source I looked at, they write the command for creating a new window as Ctrl+BC. Everything is capitalized, so it's not clear if the B and C should be upper-case or lower-case. The default assumption is that since the shift key is not explicitly invoked, then you don't need it. But that is false.
In order to properly write out the command, Ctrl+b needs to be typed out without using the shift for the b, but in the case of the "new window command", C needs to be pressed while holding down the shift key.
I looked at 4-5 different sources on this topic and none of them made this fact explicitly clear. It took this video on YouTube to finally reveal that missing detail. (It's also a good starter tutorial, btw).
Related
In my ~/.zshrc, I have my PROMPT set up like this:
PROMPT='%? '
This displays the exit status (return code) of the last command executed as the prompt (in actuality the PROMPT is more sophisticated, but I've simplified it for this question).
I have quite a complex ~/.zshrc and ~/.zprofile - I use several plugins via zplug - and somewhere, in the last few months, a change has crept in that causes every new zsh session that is opened, or at least every new login session (I run it inside iTerm2 on OS X with "login session" enabled), to display an initial return code of 1. Hitting return or typing "zsh" to start a nested session does not display a 1 return code in the subsequent prompt, but 0 as expected.
I assume this means that somewhere in my ~/.zshrc or ~/.zprofile something is failing, and making its way through to the prompt. Unfortunately I've long since lost track of the change I made which might have caused this. I've tried semi-systematically removing entries from those files to try and narrow it down, but I haven't had much luck.
Are there any tricks I can apply to trying to find what is causing the problem? For example, can I show the last command which was executed that resulted in a non-zero return code?
To be clear, this is nothing more than a little obtrusive; as far as I can tell it doesn't have any other negative side effects.
In the end I figured this out. It turned out that some rogue install process had put commands I wasn't expecting in ~/.zlogin. I figured it out by progressively commenting out content in my ~/.z* files.
I have this nifty couple of lines in my .bashrc that clears my unix terminal when I press shift+alt+c:
alias cls='printf "\033c"'
bind -x '"\eC":"cls"'
However, as you could probably guess, it only works when I'm actually at the prompt. If I'm in the middle of a program such as, let's say, tail -f, then I have to get back to the prompt, press shift+alt+c, then go back to the program (or ctrl+z, shift+alt+c, then fg).
I'm thinking it would be cool if I could somehow listen for keys while this other program is running. It's probably impossible, but I figured I'd ask here before I gave up. Any ideas?
Thanks!
Not going to work. That's your shell doing that.
Your shell isn't active when something else is.
You could do this sort of thing with your terminal if you really wanted to though (assuming it allows you to control it sufficiently) since your terminal sees the keys first.
When I SSH into a particular server and launch screen, it ignores my CTRL+a key combo. Instead of CTRL+a c creating a new screen window, it instead acts as if I had just typed c. Other key combos fail in a similar way.
I've tried launching screen using screen -e ^jj to bind to j instead of a, but I still get the same result as above.
I tried adding a .screenrc file to my homedir that I know works on other machines, but it has no impact.
I also tried launch a zsh shell instead of bash.
Any ideas where to start to try and fix this? This basically renders screen unusable.
Thanks
screen reads commands from several configuration files during startup, as described in the FILES section of the man page or the Customizing Screen section of the User's Manual (also available, if it's installed, by typing info screen).
The files read are:
The file named by the $SYSSCREENRC environment variable (this may or may not be enabled)
/etc/screenrc
The file named by the $SCREENRC environment variable`
$HOME/.screenrc
(These interact and are searched in various ways that I don't entirely understand.)
In your particular case, based on the comments, the system on which you're running screen happens to have a /etc/screenrc file that contains an escape command that overrides the default.
A digression: in my own $HOME/.screenrc I have:
escape ^#^#
This sets the escape character to the null character, which can be entered by typing Ctrl-space. I find it easier to type, and less likely to conflict with other uses, than the default Ctrl-A. The only conflict I run into is the Emac set-mark-command function, and for that it's easy enough to type it twice.
Every now and then when using the ack-vim plugin the font in my window will change to all symbols. I've yet to see any pattern to when this happens. Any suggestions on the cause and possible remedy would be appreciated.
I've seen that happen when binary content got printed to the terminal. Do your Ack queries potentially include binary files?
A fix might be
:!echo -e '\ec\e(K\e[J'
These ANSI Escape sequences attempt to reset the terminal:
# "ESC c" - sends reset to the terminal.
# "ESC ( K" - reloads the screen output mapping table.
# "ESC [ J" - erases display.
This looks like the typical character set translation enabled by the Shift Out control character; you usually just need to send the Shift In control character to counteract it.
Basically, something is outputting a C-n character (Control-N, U+000E, named Shift Out) which tells your terminal to switch to a different display character set. You should be able to get your terminal to switch back to the normal display character set by sending a C-o (Control-O, U+000F, named Shift In) to it.
If you are in Vim, then you can probably send the C-o with a command like this:
:!printf \\017
You will have to type (or paste) this command “blindly” since (due to the alternate character set) you will probably not be able to read what you are typing. If you are typing it (not pasting), then you can also type C-v C-o (to insert a single, literal C-o) instead of the backslashed octal, if that is easier to remember.
If you find that this problem occurs only sporadically when you use the vim-ack plugin, then perhaps some bit of the text results contains the problematic Shift Out character. You might try searching for the file with a command like this:
grep -FRl $(printf \\016) .
Once you know the names of the files, then you should be able to use Vim to search for the character (start a search and type C-v C-n to insert a literal C-n). Maybe it is just some garbage that you can clean out, or maybe you can configure your ack-based searches to exclude the problematic files.
You also tagged the question with tmux. I can not tell for sure, but it looks like the top line might be a tmux status line. Since this line is also corrupted it indicates that it your external terminal emulator that has switched character sets, not just one of your tmux panes.
If you send Shift Out or Shift In directly to a tmux pane it will only affect that pane (each pane is emulated independently), so your status like could not have been munged just by a stray Shift Out hitting a single pane.
If you are running inside tmux, then the easiest way to reset the outside terminal is to suspend and resume your tmux client (or detach from and reattach to your session). tmux pretty much resets the outside terminal when it gives up control.
Depending on the situation, you may also have to reset the character set of the tmux pane by sending it a C-o, too (i.e. printf \\017 at a shell, or a :! prompt in Vim).
It is easy to see how a stray Shift Out could reconfigure a single tmux pane, but it is harder to see how it could have “leaked” out to reconfigure the external terminal (tmux is pretty good at isolating things like this). However, there is a control sequence that tmux recognizes that instructs it to pass data directly to the external terminal (thus “leaking out”), but it is much less likely that you would randomly encounter this sequence since it is much longer:
printf '\ePtmux;%s\e\\' 'stuff bound for the external terminal'
You could use it to send the restorative Shift In like this:
printf '\ePtmux;%s\e\\' $(printf \\017)
You will also want to tell tmux to redraw itself after this (by default, the refresh-client command is bound to C-b r).
It is probably easier to just suspend and resume (or detach and reattach), but this sequence is useful if that is not possible. It also provides a means toward understanding what kind of sequence might “leak” out of tmux to switch the character set of the external terminal.
I'm playing around with making a simple terminal-based game with Ruby, and I'm currently trying to come up with a way of reading input from the terminal.
So far I've been using gets, but I'd like to have the game react instantly without requiring a newline (so you don't need to press a key, THEN enter).
I've figured out I need to put the terminal in non-canonical mode, and I'm assuming I can do that by calling $stdin.ioctl. The problem is, I'm not sure what arguments or flags I should be passing to this, and the documentation and searches just lead to information about the underlying C function.
Can anyone tell me what I should be calling $stdin.ioctl with? I'm using Terminal.app/tcsh on OSX Leopard.
Edit: This is what I ended up using, thanks to MarkusQ:
%x{stty -icanon -echo}
key = STDIN.read(1)
Your problem is outside of ruby.
Easiest answer: wrap your IO in %x{stty -raw echo} and %x{stty -raw echo} to change the mode with stty.
You'll probably want to do and ensure an exit handler to make certain the mode is set back when you exit.
-- MarkusQ