0

I use iTerm2 and I realized that when I'm using screen: ssh -t [username]@[domain].edu 'screen -DR'

I noticed the following vagaries:

  • I can't use my mouse to scroll up and down in an iTerm2 window

  • I can't use ctrl-a to go to the beginning of line

  • I can't use ctrl-e to go to the end of a line

  • My ~/.bash_profile isn't sourced

I'm sure there's others but how can I make the behavior be as if I just ssh'd in without a screen session?

1
  • Impossible to say not knowing how your iTerm2 is set-up, what your local shell modifications are, how screen is configured. If I understand you correctly you start iTerm2, then within iTerm2 start screen, and then ssh out? For me everything except for Ctrl-A (which unsurprisingly doesn't work) everything works as designed. Ctrl-A is screen's primary command sequence, to get to the beginning of line you'd have to do Ctrl-A a .. P.S.: I usually launch screen on the server rather than on the Mac, in case I get disconnected.
    – tink
    Commented Aug 25, 2022 at 2:20

1 Answer 1

0

The keyboard shortcuts you mention are implemented by the Bash shell. If they don't work, that likely means you're not using Bash as your shell for some reason – though it's a bit odd that Screen starts a different shell than what SSH does:

  • Check if your ~/.screenrc file has any "shell" or "defshell" commands.
  • Check if the shell reported by getent passwd $USER in the last field is /bin/bash.
  • Check if printenv SHELL (outside Screen) matches what getent reports.

On some systems, if your actual login shell is set to something weird, you might need to manually tell Screen to use bash with the shell bash screenrc setting. (For example, it is possible that your server actually has /bin/sh as the user account's shell, but sh's ~/.profile is then configured to start /bin/bash on top. In this case, the 'sh' shell started by Screen won't read ~/.profile and won't jump to bash.)


Your ~/.bash_profile won't be sourced for non-"login" shells. The outer shell that you started Screen from was a "login" shell; the ones within Screen are usually non-login and it's expected that they will only load ~/.bashrc but not any "profile" scripts – that's to avoid each new Screen window from unnecessarily starting things that were already started by the initial shell.

Things like aliases and functions should be put in ~/.bashrc instead, but the "shell" setting in screenrc can be used to force the shell to be started in "login" mode by prefixing its command with a -, e.g. -bash.


Standard terminal-based scrolling will not work with multiplexers such as Screen or tmux, and that's partly by design: the multiplexer is its own terminal emulator and drives the outer terminal in a more direct way, where text doesn't as much scroll out as it is erased and overwritten.

For example, when your Screen session has two panes split horizontally, text from the bottom pane has to be explicitly erased when it's about to scroll out of view, otherwise you'd end up with garbage in the top pane. (How would the scrollback work if your Screen session had two panes split vertically?)

Because of this, Screen is usually configured to deliberately switch the outer terminal into "alternate screen" mode, disabling iTerm2's scrollback for the duration. You can try using the altscreen off setting in your screenrc to prevent this from happening, but don't expect iTerm's scrollback to make much sense.

Instead of doing this, you can enter Screen's "copy mode" using Ctrl-a[ to be able to scroll through a specific pane.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .