Firstly, I hope this is the right place for this question.
I have an odd problem with screen detaching. I can detach from most every screen I create, except one I am using to host a minecraft server.
When I hit control A D, all I get is another '>' symbol.
I get the same if i Hit control D.
I am doing the same thing that works on other screens, could this one be different somehow?
Ok, heres watcha wanna do. When you log into your unix system you get sent to the main screen. (The screen you first see) what you want to do, is type "screen". This will make you a new screen session. Now in this new screen session, start up your server. Once its started you can now CTRL+A D out of it, and it will take you to the main screen. I had this same exact problem. You NEED to have at least 2 screens to be able to do CTRL+A D.
Related
I started a putty window, changed the font, and then did Windows-Left to fit it to the left side of the screen and it decided to do the screenshot below. The only way i've found to make it go away is the log off/on but that's obviously impractical and doesn't fix the problem.
I've had it in the past but not this bad. It usually happens when I move or resize the window. Is there a setting to have it just auto resize by default?
[edit] and then, about :05 later out of nowhere, it popped away. I'm just sitting here doing something else and it changed back to normal.
That means that you (or someone else) is connected to the same Byobu session from another computer with a smaller terminal size.
You should be able to kick the other session using Alt-F6.
Full disclosure: I am the author and maintainer of Byobu.
For mac user, by querying from the help info ctrl-a + ?, one could simply run the bash script $BYOBU_PREFIX/lib/byobu/include/tmux-detach-all-but-current-client to kick other sessions.
I am considering writing a graphical tool that will show you what gnu-screen sessions you have and what windows are available in them. You would then be able to, for example, click on the window title and it would take you there. I do not want to modify gnu-screen in any way so that my tool can work with existing installations on other machines and so on.
I can get ordinary output from programs running inside screen out of the screen session by using a log-file, or by copying the last few lines into the exchange-buffer. What I really need in order to make a nice user interface though is the contents of the status line (the line that temporarily appears at the bottom of the window). For example, to get the list of windows in a session I can send the windowlist command, but the result is never part of the output. Does anyone know if there is a way to make screen put its messages into the log, into a paste-buffer, into the current window, or anything similar where I can grab it from another program?
I am writing a client/server-application and when I'm testing the code I want to be able to have both the server and client in a separate terminal (+ vim). For this I thought I could use GNU Screen and divide the terminal in multiple windows (and it works great!). But I have a problem when I want to detach the whole session with windows and all. When I try to reattach the session I don't get them in windows like I arranged it, but instead they attaches like "normal" screen instances.
Also, is there a way to change the size of a screen window? Like change the height proportions of two windows splitted vertically.
your first question isn't possible because the regions (the way the windows are displayed) are bound to a single screen instance and not to a screen session.
C-a :
resize
see man screen for more explanation of the resize command
Sometimes when I am using less within a screen tab, the arrow keys display ^[OA, ^[OB, ^[OC, and ^[OD instead of doing what I want them to do. Is there something I can do to fix this and gain control of less again?
enter !reset at the less prompt
I have found that reset from within screen does not solve the problem sometimes, as it's the outer client/shell whose state is actually confused and screen captures the control characters from reset and prevents them from reaching the outer client. In this situation, I have to detach my session (Ctrl+a, d), run reset, then attach to the session again (screen -r).
If it happens from time to time, it seems, that some application (e.g. cat or less a binary file) shatters your console by sending it control characters. You need to run reset command from command line to recover.
Otherwise you have to trick your terminal application. I suggest you to use CryptoTerm which allows you to define custom key mappings.
Another thing to check is your TERM variable. In my case I ssh into a Linux box and run less inside screen - the TERM variable was set to 'screen' - which breaks arrow keys. It works perfectly if I run less this way:
TERM=xterm less <file>
Is there an SSH client that can present a client side GUI interface to the screen* program?
I'm thinking of an SSH program that would hook in with screen's session handling and map client side actions (clicking on a tab, ctrl-tab, scrolling, possibly even allowing several tabs to be seen at the same time) to whatever it takes to make screen at the other end do it's thing.
* The screen program that allow multiple virtual consoles under a single terminal session, for example you can run several apps under a single SSH connection and switch between them as well as other cool things.
An interesting idea, and quite possible (vim7's tabs show as clicky GUI tabs in gnome-terminal), but I don't see the benefit of doing this..
Using the follow ~/.screenrc shows "graphical" tabs:
startup_message off
vbell off
hardstatus alwayslastline
hardstatus string '%{gk}[ %{G}%H %{g}][%= %{wk}%?%-Lw%?%{=b kR}(%{W}%n*%f %t%?(%u)%?%{=b kR})%{= kw}%?%+Lw%?%?%= %{g}]%{=y C}[%d/%m %c]%{W}'
..which look like the following (after renaming the tabs using ctrl+a,a:
x http://img216.imageshack.us/img216/9401/picture4myi.png
You can scroll around in a screen session using "copy mode", by doing ctrl+a,[ and using the cursor keys (press Esc or ctrl+c to exit it)
You can also attach to the same screen session multiple times using the screen -x flag (rather than -r), so you could use any tabbed terminal emulator, and open one tab for each screen-window.
If you really did want to start implementing this - one option would be to look into modifying gnome-terminal, to copy the behaviour with vim's tabs for screen. Or, write your own screen client - you don't need to do anything as fragile sounding as scraping the terminal - there's a FIFO file in (usually) /tmp/uscreens/S-$USER/$PID.sessionname which I think is how screen communicates, and remember screen is open-source!
Interesting idea. I use screen everyday both on my local machine and for SSH sessions. I think your biggest problem is that I suspect most screen users are commandline junkies like me who just won't see the benefit of making a gui for tabs. In fact, I have all my terminals in one gnome-terminal window under different tabs, and having screen's text-based tabs is a nice way not to confuse the two.
I suspect it could be done, but you'd be writing a specialised terminal emulator which analyses screen's output (custom .screenrc) and retrofits the gui.
A lot of work for minimal gain.
ctrl+a shift+'
.. gui front-end to screen? what are you talking about??
also, because my rep is so low, and i cant comment, id like to LOL # geoffc for his comment in the question
I've never seen one, but the following may help you. Add to your .screenrc
To show a row of "tabs" on the bottom
caption always "%{.bW}%-Lw%{.rW}%n %t%{-}%+Lw %=%{..G} %{..Y} %m/%d"
To show the current program as the screen name [assuming you're using bash and your prompt ends with "$ " by default; others shells are the exact same idea]
shelltitle "$ |sh"