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
Related
I'm using gnome in RHEL 6.4 and I've created a desktop launcher to open a terminal window to present data from a flatfile to a user (actually the launcher opens a terminal window and executes a script file, which will present the data to the users). The data is about 650 characters wide.
I've tried two concepts that I could think of, but in both cases have been limited by (presumably) the window manager itself:
xterm -geometry 650x25 -e /path/to/my/script.sh &
and resize -s 25 650 from within the /path/to/my/script.sh
Both will make the xterm the size of the actual desktop (with my current resolution, approximately only about 300 characters wide).
This causes a problem when presenting the data in the script.sh due to word wrapping.
My current workaround is to prompt the user to resize the window manually before presenting the data to them...
Is there a way to open up the terminal window to the specified size, regardless of the current size of the gnome window? Or better yet, is there a way to use the resize the window after launch (ala resize -s ); this would be preferred as there are two types of files to present to the user. One is only 450 characters wide, and the other is 650. I would love to be able to start up at 450, and if the longer file is selected, change the window to 650.
(Of Note, I recall the Solaris Java Desktop had this behavior by default; but this behavior is typically undesirable other than in the instance described above; therefore I do not want to change the default behavior of the window manager for all windows; just on the terminal window launched with the desktop launcher!)
Appreciate any ideas!
Thanks,
KSL.
This is on Ubuntu. I have two xsessions, one on tty7 (display :0) and one on tty8 (display :1). For the record, :0 is Unity and :1 is Fluxbox. I would like to be able to take a screenshot on display :1 while working on display :0.
I'm using the Java Robot class. I've written a small screen scraping bot. The mouse movements work when I'm switched to the other virtual terminal, but the screengrabs are coming out all black (the bot has no image to act on).
I'm spawning the second xsession with:
startx /usr/bin/fluxbox -- :1
Is there a way to make the screenshots work? Is there a workaround for keeping the display active (remote desktop to it?)? Would someone be kind enough to explain why these go black when the virtual terminal is not focused?
I'm looking for the least intensive way to have a second display, mouse, and keyboard running. The path of least resistance would be a way to keep the display active when not focused.
Thanks! Sorry if any of my terminology is off, new to using a second virtual terminal.
You get a black image simply because the image you want to capture does not exist anywhere.
When a virtual terminal is active, each program that is on your display will generate its own image, and the image gets put into the video memory. When the virtual terminal is not active, the programs do not generate their image (since it would be superfluous), nothing stores those images, so you cannot capture them.
How to disable scrollback (^A[ESC]) mode in screen and just have it straight up print to the terminal instead (using the builtin scroll of my terminal emulator)?
I am using screen on gnome-terminal across an ssh session
Since the terminal has builtin scroll capabilities, I just want to be able to use the scrollwheel on the mouse to scroll as opposed to using ^A[ESC]
In command mode (^A:), set scrollback 0.
A few notes:
The current length of the scrollback buffer in lines is shown (among other stuff) by the info command (after the plus character).
Using the mouse wheel will not give the same experience that screen can offer
the terminal's scrollback contains exactly data that was actually displayed
data from inactive windows is not available
split windows will show as-is
I am answering an 8 year old question that came up in a web search - the answer was in man screen.
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?
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"