Re: Hard status line in vertical split mode.
On Wed, Sep 19, 2007 at 07:12:11PM -0400, cga2000 wrote:
But do you mean that I would just need to build an xterm with the
enable rectangles feature enabled to benefit from faster scrolling ..
Surely there must be more to it than that?
Well, screen must be patched to use those sequences as well. That
would be in the ScrollV() function in display.c. It currently checks
if the xs/xe values cover the complete terminal width (by comparing
them to vpxmin/vpxmax), if that's not the case it refreshes the
area.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Hard status line in vertical split mode.
On Thu, Sep 13, 2007 at 11:01:04PM -0400, cga2000 wrote:
On Wed, Sep 12, 2007 at 12:31:58PM EDT, Michael Schroeder wrote:
On Tue, Sep 11, 2007 at 11:22:24PM -0400, cga2000 wrote:
I had a couple more questions about vertical split caption/status
lines:
1. After I do a vertical split, paging or searching is very slow on my
machine. Is this something to do with my configuration?
No, it's because terminals support scrolling for horizontal splits
(scrolling region), but not for vertical splits, so screen has
to do lots of redrawing. Xterm provides a box copy feature that
would help a lot, but it's turned off in the default configuration.
Dunno why...
Is this something you saw in the XTerm code? How would it help?
I am all the more curious since this slowness in vertical split screen
mode is the one problem that might deter me and presumably others from
using it on a regular basis.
If you compile xterm with '--enable-rectangles', it'll understand
some extra commands:
DECCRA Copy rectangular area
\e[ Pts;Pls;Pbs;Prs;Pps;Ptd;Pld;Ppd $v
DECERA Erase rectangular area
\e[ Pt;Pl;Pb;Pr $z
DECFRA Fill rectangular area
\e[ Pch;Pt;Pl;Pb;Pr $x
DECSERA Selective erase rectangular area
\e[ Pt;Pl;Pb;Pr ${
DECCARA Change attributes in rectangular area
\e[ Pt;Pl;Pb;Pr;Ps1;...Psn $r
DECRARA Reverse attributes in rectangular area
\e[ Pt;Pl;Pb;Pr;Ps1;...Psn $t
DECSACE Select attribute change extent
\e[ Ps *x
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Hard status line in vertical split mode.
On Mon, Sep 10, 2007 at 11:05:10PM -0400, cga2000 wrote:
Is there any way I can configure screen so as to have a single hard
status line covering the entire width of the display.
What I'm seeing is the left-most part of the hard-status line repeated
in each window and the right-most part of it is truncated.
The hardstatus always covers the complete width of the terminal,
are you mixing it up with the window caption?
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Re : Re : New screen features available
On Wed, May 23, 2007 at 12:12:35PM -0400, Jean-Yves Levesque wrote:
What I would like to see is the following:
window 1: bash shell
Window 2: group of two bash shell side by side
window 3: group of 4 bash shells in a 4x4 view.
When I go to window 1 I have one window. If I go
to next window, I would see a 2x1 layout. ^a next
would show me a 4x4 layout. ^a next would bring me
back to the single window layout.
Sounds to me like it is exactly what the layout code does.
You just have to bind ^A SPACE to layout next and create
three layouts.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Development forum?
Yeah, me too. :) ...I suspect that at least part of the bug could be
some hitch with xfce4 (which claims to be xterm) not quite conforming to
xterm's terminfo (why else should behavior differ at all from screen
running under a genuine xterm, or gnome-terminal?). But even if that's
so, some of the fault probably lies with screen, in mishandling the
situation and sending NULs that it clearly is not receiving, and that
have nothing to do with terminfo values.
Maybe 'kb' is bound to something. Try '^A:bindkey' and '^A:bindkey -d'.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Multibyte characters in the Hardstatus line
On Wed, Mar 28, 2007 at 12:04:09PM +0200, Zvi Har'El wrote:
Comparing Unicode, it replaces U+03B1 GREEK SMALL LETTER ALPHA with
U+00B1 PLUS-MINUS SIGN and so on, i.e, the Unicode values seem to be
taken modulo U+0100.
Yes, it's because StringChar() in ansi.c discards the upper bits.
To fix this bug we'd have to change the way the string gets stored.
Note that we can't just simply transcode to the display's encoding,
as the window may be displayed on multiple displays with different
encodings...
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: New screen features available
On Tue, Feb 20, 2007 at 05:32:14PM -0800, Jonathan Daugherty wrote:
# Here are the new features:
#
# - vertical split, complete with resizing
*Thank you* for this feature. I've wanted this ever since I learned
about horizontal splitting. I really like it.
I did notice one odd thing, however. If I open screen in an xterm,
say, and run ps aux, the output is very fast: basically
instantaneous. If I then run ^a| and run the same command in a
narrower window, my CPU usage goes to 100% and there is a great deal
of flickering in the terminal. In addition, it takes a noticeably
longer time to run ps aux. As a control, running ps aux in a
plain screen window (not split) or a plain xterm of comparable width
results in the faster behavior, so I'm lead to think that screen is
involved.
Yes, currently a vertical split is expensive. As screen doesn't use
any special region-scrolling functions of the terminals it has
to do lots of refreshes. I hope to fix that soon (at least for
xterm).
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: New screen features available
On Fri, Feb 09, 2007 at 01:47:55PM -0500, Brian Mathis wrote:
I'm not sure my description is good enough, but the idea is that on a
wide terminal, you could split that space into 2, and create an extra
long terminal for 1 program to use.
This is actually doable, It's just a matter of setting up the
viewports in the canvas. Compile screen with -DHOLE to get
another example of a non-standard layout.
How about the other screen users? Do you think it's worth to
implement something like this?
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: New screen features available
On Thu, Feb 08, 2007 at 07:40:50PM -0500, Phil!Gregory wrote:
- vertical split, complete with resizing
I'll compile and play with the new code a bit later tonight to see how the
new vertical splits work with 'focus up' and 'focus down', but do you have
plans to add 'focus left' and 'focus right'?
Uh, those two are named wrong. Currently we have focus next and
focus prev, and yes, I plan to add up/down/left/right and
upmost/downmost/leftmost/rightmost as well.
- window groups
I think I can already see uses for this. (I have too many screen
windows. :)
- layouts
Likewise, especially with the vertical splits.
You probably have a lot of suggestions and enhancement requests.
I'd like, at least, to get an official response on whether you'd like to
include my patch to add RFC 1345 digraphs to the 'digraph' command.
http://aperiodic.net/phil/screen/screen-rfc1345-digraph.patch
Good question. There are a couple of issues:
1) it breaks downward compatibility
2) in the old table the order of the two digraph keys does not matter.
E.g. it contains
a - LATIN SMALL LETTER A WITH DIAERESIS
and you can press either a and a to get an a-umlaut.
This has the following use case: a user can bind
bind : digraph \
and then get an a-umlaut by pressing ^A:a, an o-umlaut by pressing
^A:o and so on (so you have created an umlaut command). That's
also why the old table has:
s - LATIN SMALL LETTER SHARP S (German)
So it probably makes sense to make this configurable and ship screen
with both tables.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: New screen features available
On Fri, Feb 09, 2007 at 02:07:14PM -0500, Aaron Davies wrote:
On 2/9/07, Michael Schroeder
[EMAIL PROTECTED] wrote:
On Thu, Feb 08, 2007 at 07:40:50PM -0500, Phil!Gregory wrote:
- vertical split, complete with resizing
I'll compile and play with the new code a bit later tonight to see how
the
new vertical splits work with 'focus up' and 'focus down', but do you
have
plans to add 'focus left' and 'focus right'?
Uh, those two are named wrong. Currently we have focus next and
focus prev, and yes, I plan to add up/down/left/right and
upmost/downmost/leftmost/rightmost as well.
Regarding this, I never got a final answer to my question about
binding shift-key combinations, such as the nicely intuitive
shift-tab for focus prev.
This already works in the current version.
Anybody have any more ideas?
As long as the keys are defined in the terminfo database it's no
big deal.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: File descriptors and screen and you
On 2/6/07, Alan Young [EMAIL PROTECTED] wrote:
I have a bit of perl code that I'm trying to make work:
sub DB::get_fork_TTY {
open my $SCREEN, qq{31 screen -t 'Child $$' sh -c tty 13 ; sleep
100 |}
or return '';
my $tty = $SCREEN;
return $tty;
}
I'm getting bad file descriptor errors, so I'm assuming screen is
cleaning up what it hands to it's children. Which makes sense.
The problem is actually something else (but you're right, screen
cleans up the filedescriptors): the 'screen' command in your
script just tells the screen backend process that it should create
a new window, so the new window is no child of your script and
cannot share the file descriptor.
I want to avoid going the tmp file route if at all possible. Is there a
way I can echo tty's output so that I can grab it from a filehandle?
You need some interprocess communication way. Some ways could be
- a tmp file (but you don't like that)
- a named pipe (but that's close to a tmp file)
- some code using sockets (complicated)
- using /proc/pid/fd to access the file descriptors of your
process. But that's not very portable. Something like:
open my $SCREEN, qq{screen -t 'Child $$' sh -c tty /proc/\$\$/fd/1 ;
sleep 100 ; sleep 10 |}
(The sleep 10 is needed to keep the process alive long enough.)
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: New screen features available
I just committed a version with more screen-like layout commands.
We now have
layout new [title]
layout select [number/title]
layout title [newtitle]
layout number [newnumber]
layout show
and the old
layout next
layout prev
layout attach
layout autosave
My ~/.screenrc file contains
layout new
bind y command -c layout
bind -c layout ylayout next
bind -c layout ' ' layout next
bind -c layout ^? layout prev
bind -c layout nlayout next
bind -c layout playout prev
bind -c layout 0layout select 0
bind -c layout 1layout select 1
bind -c layout 2layout select 2
bind -c layout 3layout select 3
bind -c layout 4layout select 4
bind -c layout 5layout select 5
bind -c layout 6layout select 6
bind -c layout 7layout select 7
bind -c layout 8layout select 8
bind -c layout 9layout select 9
bind -c layout \' layout select
bind -c layout ?layout show
bind -c layout ilayout number
bind -c layout clayout new
for playing with layouts. Thus you can use ^Ayc to create a new layout,
^Ay? to show the available layouts, ^Ayy to move to the next layout,
and so on.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
New screen features available
Hi Screen Users,
you probably wonder why the new version of screen is not already
available. Well, it got delayed a bit because of a couple of new
features I've added. The development version is available from
GNU savanna:
cvs -z3 -d:pserver:[EMAIL PROTECTED]:/sources/screen co screen
Here are the new features:
- vertical split, complete with resizing
^A | split vertically
resize [-l] [-h] [-v] amount
-l : resize is local to slice
-h : resize horizontally
-v : resize vertically
amount: 10 resize to size 10
amount: +10 make 10 bigger
amount: -10 make 10 smaller
amount: 10% make it 10% of all
amount: =make all windows equal
- better resize code using weights
the layout will stay in shape even after heavy resizing
- window groups
currently a bit ugly to create:
screen -t name //group
creates a group named name
a group is a subset of windows, ^Aw will only display the
current group and next/prev will not leave the group.
Use ^A to list all windows of the current group (this also
leaves to group, so that next/prev or a second ^A will
show the other windows.
- layouts
A layout stores the current setup of the display, i.e. all the
slices and the window assignments.
layout save Desktop1
will save the current setup under the name Desktop1. If you
detach and reattach later on, the layout will automatically
be restored. Desktop1 will become the current layout.
layout autosave off
This turns the autosafe feature off. Layouts are automatically
saved if autosave is on and the user detachs or switches to
another layout.
layout new Desktop2
Create a new empty layout named Desktop2.
layout name foo
Rename the current layout to foo.
layout next
layout prev
layout load name
Load the next/prev layout / the layout named name.
layout attach :last
layout attach name
Set the layout used when somebody is attaching. Default is :last,
this is the layout that was current when the last detach was done.
Besides the restoring of the screen on re-attach, layouts can be
used to implement a kind of virtual desktop in screen. Say
you put layout save Desktop1 in your ~/.screenrc. If you
need a new Desktop, do ^A:layout new Desktop2. You can then
use layout next to switch between both layouts.
So, feedback welcome. You probably have a lot of suggestions and
enhancement requests. Sorry that development is a bit slow at
the moment due to not enough spare time...
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: terminal devices left open after logging out
On Tue, Nov 14, 2006 at 11:55:17AM +0900, Henry Nelson wrote:
The thing is, what are these programs that should run in the background
or as a daemon? I'm not running programs in the background, but still
get these orphaned ttyp's that remain from a screen session. Any
daemons running are started at bootup, and don't have anything to do with
login users.
Could be a bug in screen's utmp handling. What OS are you running?
Thanks,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Screen does not recode the input.
On Wed, Oct 04, 2006 at 07:49:54PM +0400, balodja wrote:
Hi, dear developers. I have unicode locale(with utf8 as a local
charset). And have some programs that use koi8-r(fortunately on the
remote computer =)). I tried to use screen for recoding(:encoding koi8-r
utf8). That works fine! But my input is not recorded. As a result I have
a lot of dump because utf-characters were not recorded to koi8-r =( So,
what is this, is it a bug or a feature? Screen version 4.00.02 (FAU)
5-Dec-03
Hmm, works for me. Can you give me an example? What characters
do not get recoded?
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: how is zmodem used with GNU screen?
On Wed, Oct 25, 2006 at 10:19:24PM -0700, Adam Monsen wrote:
Can anyone give me an ultra brief intro to how to use zmodem with GNU
screen? I've got lrzsz working, I'm just not sure how to use it.
It depends whether screen is in the middle of a sz/rz transfer or
it is used as an endpoint.
1) In the middle:
Use zmodem pass in that case. This means that screen will pass
on all zmodem data. Example: your terminal emulation supports
zmodem, you log into a server and reconnect to your screen session.
In the session you need to transfer a file home, so you call
sz filename in a window.
2) As an endpoint:
You use screen as your terminal emulator, i.e. you have connected
the console of some other machine to your serial line and want
to transfer a file from the other machine to your host. So you
configure zmodem catch and run sz filename on the host.
Screen will intercept the zmodem sequences and prompt you
with a rz prompt. You just confirm this by pressing return and
the file will get transfered.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Secfix release for screen: screen-4.0.3
Hi Screen lovers,
I've just released screen-4.0.3. This is not the promised next version
with vertical split and other cool things, but just a security release
that fixes two bugs in the utf8 combining characters handling. The
bugs could be used to crash/hang screen by writing a special string
to a window.
The fixed version is (as usual) available via:
ftp://ftp.uni-erlangen.de/pub/utilities/screen/screen-4.0.3.tar.gz
Credits go to cstone Rich Felker for finding the bugs.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Bash 3.1 and login shells
On Mon, Oct 23, 2006 at 10:28:27AM -0500, Aaron Griffin wrote:
So it appears I posted this long ago (just did a searc through the
ML), but this still isn't resolved... is anyone aware of this issue:
On 3/31/06, Aaron Griffin [EMAIL PROTECTED] wrote:
So bash 3.1 no longer works happilly with the 'shell -bash' or
'deflogin on' settings. Downgrading to bash 3.0 fixes this just fine
with the exact same settings. This is kind of annoying.
Would anyone happen to know a fix, either for screen or bash?
It should work if you compile bash with NON_INTERACTIVE_LOGIN_SHELLS
defined. I don't think this has changed between bash-3.0 and
bash-3.1, though.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Tab bar
On Fri, Oct 13, 2006 at 09:00:06AM +0200, Hr. Daniel Mikkelsen wrote:
In my head, screen 0 is to the right of screen 9, not left of screen 1,
because of how keyboards look.
You mean between screen 9 and screen 10? Very strange.
Is there any way to get screen to represent this on such a tab bar?
Do not use screen 0, start with screen 1 instead. Make ^A0 switch to
window 10 instead of 0.
(e.g. put
bind c screen 1
bind 0 select 10
screen 1
at the end of your ~/.screenrc file)
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Using screen's su command to attach to somebody else's lost session
On Mon, Sep 18, 2006 at 03:48:48PM +0800, Wayne Ivory wrote:
1.I modified a forklift driver's .profile to do a screen -list and
look for the word Attached. If it is found then it does a screen -x
to attached to the dropped session, otherwise it runs screen and invokes
the ERP system. This works ideally! Now thinking ahead, it's possible
that a forklift driver may go to lunch or even go home whilst he has a
dropped session, so I would like his supervisor to be able to do the
attach so I started checking out the add* commands. At the very least
I'd like we IT people to be able to attach by logging in as root so I
did this and tried invoking screen's (not unix's) su command. It
prompted me for the user name and unix password and then prompted me for
the screen password. I tried leaving it blank, entering the word none,
entering the same password as the unix password, but in all cases screen
replied with Sorry. How can root attach to a general user's session?
You should add multiuser on and acladd root to the user's screenrc
to allow root to attach to the session. Then root can attach with
screen -x username/
Screen's internal su command is just for switching internal ids
if you're already attached. You probably will never need it.
2.As a variation on the theme of the above case, when the forklift
driver goes to lunch he may not log out. When he comes back if he is
assigned to a different forklift that is not logged in then he will log
in and his .profile as it stands will detect the Attached session and
attach to it, but of course this will go multi-user on the live
connection so when another driver jumps on the original forklift the two
drivers will be fighting for control of the one session. How can I tell
if an Attached session is the result of a dropped radio link or if it
is live?
If screen -ls prints Attached then screen never received a hangup,
so there is no way to detect if it is dropped or still alive.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: screen -m -d breaks backspace
On Fri, Sep 01, 2006 at 06:24:47PM -0400, Clint wrote:
Hello,
Recently, I suspect due to a debian update, something changed on my system
where launching screen in detached mode breaks the backspace. The backspace
now deletes the whole line and control backspace deletes the previous
character. What's odd is that running screen normally (without -m -d)
leaves backspace working fine.
That's because screen can't clone your tty settings if you run it
in -m -d mode, so it makes up some standard settings (actually taken
from SunOS 4.1.3 a long time ago). Those settings have erase=\177 and
kill=\b, they are hardcoded in tty.sh. Maybe Debian changed them in
the update.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Always give bell msg
On Wed, Aug 23, 2006 at 04:12:09PM +0200, Maurice van der Pot wrote:
Last year I sent this message to the list, but to date I have not had
any replies. Should I conclude that this patch does not have a chance of
making it into screen or did it just slip through the cracks?
Well, it's just not decided yet. There wasn't much demand for this
feature and I'm not really in favour of bloating screen with to many
features and commands. I'd prefer an option for the 'bell/bell_msg'
instead of an extra command.
One other thing I'm considering is if it would make sense to extend
the bell/activity/silence message handling by allowing any screen
command, instead of just showing a message.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: vim syntax highlighting does not work in screen
On Sun, Aug 20, 2006 at 08:58:35PM -0400, Eric Wood wrote:
If all you're using screen for is the protect your editing session from
connection drops, try screen's little bother called dtach. I never use
screen ever since I found dtach because it doesn't foul with my emulation.
Screen has to fiddle with the emulation because it supports reattach
from different terminal types.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Sending command to a detached screen
On Wed, Jun 14, 2006 at 12:58:21PM +0530, [EMAIL PROTECTED] wrote:
We are using screen version Screen version 4.00.02 (FAU) 5-Dec-03 and
wants to issue a command to a detached screen. If my screen name is kamal,
and I try the following command, it does not work
screen -S kamal -X 'exec exit'
exit is the command which I want to issue to kamal screen.
If you just want to send the string 'exit' to the window, use:
screen -S kamal -X 'stuff exit'
or (if you also want a newline):
screen -S kamal -X 'stuff exit
'
If you want to kill the window, use:
screen -S kamal -X kill
If you want to kill screen, use:
screen -S kamal -X quit
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: script to run screen with multiple telnet windows?
On Wed, Jun 21, 2006 at 06:53:23AM -0300, Germn Gutirrez wrote:
If I remove the NEED_DISPLAY and then execute:
screen -dmS test -t one
screen -S test -X at one stuff ls `echo -ne '\015'`
Ends with a Dead ??? screen session
Oh right, that one liner patch is not enough. Sorry, I confused it
with a similar bugfix.
But try
screen -S test -p one -X stuff ls `echo -ne '\015'`
instead, there's no need to use the 'at' command.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Showing /dev/tty12 (or similar) syslog output in screen window
On Tue, Jun 20, 2006 at 05:21:35PM +0200, Nikolai Weibull wrote:
Anyway, let's assume then that I don't write my messages to
/var/log/messages and only write them to /dev/tty12 (or a similar
device). Now, how do I display the output sent to terminal /dev/tty12
(or similar) in a window in screen?
Not entirely sure but I don't think that is possible.
Probably not, no, but as I don't know I asked.
If it's just console output you're looking for you can try
'console on'...
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Supressing Flow Control?
On Thu, May 18, 2006 at 04:27:15PM -0400, Aaron Davies wrote:
Do you guys have any suggestions for suppressing flow control? I'm
following a previous reccomendation and running screen on windows
under PuTTY/Cygterm, but the flow control behavior of ^S is making
emacs impossible to use. Is there something I can do to screen or
getty to fix this?
Hmm, the automatic flow code should disable flow control if you start
emacs. What is the output of ^Aibefore/after starting emacs in screen?
It should contain +flow before and -flow after.
If everything fails, add defflow off to your ~/.screenrc file.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Backspace/Delete Issues?
On Fri, May 12, 2006 at 03:02:54PM +0200, Alain Bench wrote:
On Thursday, May 11, 2006 at 11:44:24 -0400, Aaron Davies wrote:
On 5/11/06, Alain Bench [EMAIL PROTECTED] wrote:
| $ infocmp -1 | grep kbs
| kbs=^H,
Nope, I get \177
Good. It's the good kbs value, describing PuTTY's default config
Terminal - Keyboard - Backspace: Control-? (127). So all directly
running apps are correctly informed about what the key sends, and they
do work. Screen itself also could need this information.
Actually I don't know a single application that looks at kbs. The
right way is to check the ERASE stty setting.
You should check for some bogus 'bindkey -k kb ...' line in the
system screenrc file and the .screenrc in your home directory.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: colors #8-16 are not bright
On Sat, Mar 25, 2006 at 02:13:15PM +0100, Alain Bench wrote:
Is that dark #8-15 colors a bug? And is there a solution or
workaround sufficiently generic to work with any terminals having 16 or
more colors?
I think this is a bug, screen should not use the xterm compatibility
hack if the colors terminfo entry is greater than 8.
The xterm code works like this: most xterms understand 16 colors, but
have colors#8 in the terminfo. Because of this, screen writes both
the bright and dark codes to the terminal if $TERM looks like xterm.
As a workaround, you can add
termcapinfo putty* XT
to your ~/.screenrc.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: screen on 256 color xterm
On Mon, Mar 27, 2006 at 10:50:38AM +0200, Nikolai Weibull wrote:
On 3/27/06, Dr. Johannes Zellner [EMAIL PROTECTED] wrote:
On Sun, Mar 26, 2006 at 11:46:52PM +0200, Nikolai Weibull wrote:
Have you compiled screen with --enable-colors256?
wow! trivial cause. No. I used screen as it comes with debian. Compiled
myself with 256 colors enabled and everything works as expeced. Thanks!
:-). Perhaps it's time to enable it by default? I can't imagine why
you wouldn't want it on. Doe s it potentially break something?
No, it can't break things, but it needs a little bit more memory.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Programs run in screen freeze up if my SSH session lags
On Mon, Feb 06, 2006 at 04:28:11PM -0500, Philip Mak wrote:
Problem: I'm running a program inside screen over SSH, but if my internet
connection lags out, then that program gets paused too.
How can I make the program not wait for my internet connection? I
don't want to detach from screen because I want to see what the
program's doing (when I'm not lagged out).
Maybe the 'nonblock' and 'defnonblock' commands help here.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: termcap-query feature
On Thu, Feb 02, 2006 at 09:58:15AM -0600, Aaron Griffin wrote:
On 2/1/06, Michael Schroeder
[EMAIL PROTECTED] wrote:
A screen-256color terminfo entry is probably the way to go...
And possibly a screen-88color terminfo entry too... urxvt and a
handful of others support 88 colors (who decided that? 88? what kind
of number is that?).
88 = 16 + 4*4*4 + 8
IIRC it's the original 16 colors plus an 4x4x4 rgb cube plus
8 extra grays.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: How do I get a windowlist to STDOUT?
On Tue, Jan 03, 2006 at 11:28:26AM -0600, Aaron Griffin wrote:
On 1/3/06, Robert Blackwell [EMAIL PROTECTED] wrote:
I have been digging around to find a nice way to output the windowlist to
STDOUT but have not seen an easy solution.
I would like to be able to do something like this
screen -X windowlist windows.txt
I've been looking for something similar with the paste command (if
that's the right name) - so screen -X paste will dump the current
copy buffer. I don't think any of the commands actually output to
stdout when run from the command line. Might be a nice thing to hack
in though.
You can use 'screen -X writebuf filename' to dump the copy
buffer into a file. If you need stdout dump the content into a
tempfile and write the tempfile to stdout.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: reset
On Wed, Dec 28, 2005 at 06:30:18PM +, bill wrote:
Is there a way to fully reset a terminal? I was playing around
with some ncurses() stuff today, failed to reset the terminal
and left things in a bad state. C-a Z failed to help. Is there
a stronger reset available?
No, currently you can only reset screen's internal window state.
I had to quit screen completely to recover.
Detaching and reattaching should also help.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: vertical split
On Sun, Dec 18, 2005 at 05:28:07PM +, bill wrote:
Here's a patch that does the vertical split. It doesn't put any delimiter
between the windows, which can be disconcerting, since when you
first create the new region (^A V), absolutely nothing noticeable
happens. But if you ^A-tab you'll be in the new region, and a
next will make something show up. This was
a diff against 4.0.3, which I gather from Michael's comment may
be the wrong thing to diff against.
Hey, that's the easy part. If it was that easy it would have been
in screen reight away. You have to add resizing, stacking and the
like. Just habe a look at vim.
(And please don't use EXIT_FAILURE/EXIT_SUCCESS, we're all using
unix here. I much prefer 0/-1)
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: fFtT implementation
Btw, here's the current status:
On Sun, Dec 18, 2005 at 04:38:36PM +0100, Michael Schroeder wrote:
Planned features for the next release:
- sending the tty file descriptor from the frontend to the
backend over the unix domain socket, so you won't get error
messages after an 'su' to a different user.
Done.
- creating a little suid-root multiuser helper, so that multiuser
mode doesn't need the big screen binary to be suid-root.
Not started. My current idea is to throw out all of the seteuid(),
UserContext(), etc code. Does anybody run a suid-root screen out
there?
To make everything work again, the suid-root helper needs the
following functionality:
1) attach to multiuser screen
2) remove/set utmp entries (not needed on systems with utempter)
3) chown ptys (not needed on systems with unix98 ptys)
- a couple of minor improvements, like the input buffer problem.
- maybe vertical split, if I still have some time left.
And I forgot one major point:
- change the code so screen *never* blocks on a dead display.
This is not that hard, the biggest part is a reimplementation
of the Msg() mechanism.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: unknown terminal screen.linux
On Fri, Oct 28, 2005 at 03:09:34PM +0100, Mark Himsley wrote:
If I am using a screen window on the FC3 machine and I ssh to, for
instance, a Redhat 9 server I get the following error:
$ ssh [EMAIL PROTECTED]
unknown terminal screen.linux
unknown terminal screen.linux
Uh huh. The Fedora guys are strange. Try:
mkdir /usr/share/terminfo/s/screen-backup
mv /usr/share/terminfo/s/screen.* /usr/share/terminfo/s/screen-backup
I don't see why you would need those extra terminfo entries.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: [monitoring-like] would like to be warned when I have mail (fetchmail -c)
On Wed, Sep 28, 2005 at 11:26:33PM +0200, Gerhard Siegesmund wrote:
Mhm. There is not much to check. The script basically looks like this:
#!/bin/sh
while true; do
call_command_to_get something (e.g. fetchmail -c)
echo something
sleep some time
done
It should work if you use just echo, as this is a shell builtin.
If that 'echo something' is an external command or a pipe you have
to use 'echo something || exit 1'.
How exactly does the script look like?
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: X cut and paste
On Thu, Sep 15, 2005 at 12:51:38PM -0500, Aaron Griffin wrote:
On 9/15/05, Michael Schroeder
[EMAIL PROTECTED] wrote:
Planned features for the next release:
- maybe vertical split, if I still have some time left.
Hooray! Out of morbid curiosity, what would be the implications of
converting screen to use ncurses (ignoring the workload, of course) -
could it be done? I think it'd improve portability and reduce the
code base a bit and would give you the capability to handle V/H
splits easilly, and even floating windows or something
Actually screen's display functions can do all of this and lots
more, so there is no need to switch to ncurses.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: X cut and paste
On Tue, Sep 20, 2005 at 11:15:11AM -0500, Aaron Griffin wrote:
Hmmm, didn't know that. I did notice it was possible as the layers
took into account all the information needed already (x,y,h,w).
Well, you just need the right setup. Try compiling screen with -DHOLE,
for example.
Admittedly I didn't attempt to patch it because the layers stuff seems
to span 3-4 files, so it was hard to follow.
All the clipping is done in layer.c, the raw output functions
are in display.c.
Maybe I will do
something with it - or at least try. Would you, by chance, be willing
to accept patches to get rid of the KR style? Call me OCD, but if I
was going to work on screen at all I would *have* to clean it up a bit
- and I just might be crazy enough to do it 8)
I'm against changing to ANSI, as we have prototypes you don't
get extra functionality and screen won't complile with some older
compilers anymore. It's the same thing as throwing out support for
old OSes, it's just a bunch of ifdefs that doesn't hurt much.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: X cut and paste
On Thu, Sep 15, 2005 at 11:39:02AM -0400, [EMAIL PROTECTED] wrote:
The list has been very quiet lately. I hope everyone is having a good
vacation.
I'm using HP-UX. When I start my X server and XDMCP to a box, login and
start screen, everything is OK. When I telnet to another host and try to
paste text into vi, there's a lot of text loss. It happens with rlogin as
well.
This happens when screen's input buffer is full. Known problem. I'll
try to fix it in the next version of screen.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Screen Problem (fwd)
Let's ask screen-users@gnu.org if somebody with HPUX experience knows what's going on here. Cheers, Michael. - Forwarded message from Carlos Vanegas [EMAIL PROTECTED] - I installed screen-4.0.2 in HP-UX 11.11 (in format depot) and I ran screen very good the last Thursday , I made some testing and everything was so good, but on Friday when I try to run screen in the same terminal (vt100) I saw the next messages: -- screen Cannot find terminfo entry for 'vt100'. If I open a xterm, received the similar messages: -- screen Cannot find terminfo entry for 'xterm'. I removed the screen software and install again, and everything was ok, but today Monday, I have the same problem. I appreciate if you can help me. Thanks !!! - End forwarded message - ___ screen-users mailing list screen-users@gnu.org http://lists.gnu.org/mailman/listinfo/screen-users
Re: Multiple screen -X commands fast after eachother fail
On Wed, Aug 17, 2005 at 08:19:15PM +0200, Wouter Coekaerts wrote:
If I send multiple commands with screen -X, only the first one gets
executed. An example (the problem is not with the stuff command itself,
that's just an easy test case):
screen -X stuff abc; screen -X stuff def will only put abc in the
screen. Putting a sleep 1 in between them fixes it.
A script I wrote does something like this, and a Gentoo user originally
reported this to me. I can't reproduce this on Debian sarge, but my (more
or less up-to-date) Debian sid has the problem too. But they have the same
screen version (4.00.02), so I don't know which version of what actually
causes this.
Well, I can't reproduce this but I'm pretty sure I know how this
can happen. If named pipes are used the backend has to close and
reopen the pipe to clear the EOF status. If the second 'screen -X'
is fast enough it will write to the old pipe and thus get lost.
You can either
1) recompile screen to use unix domain sockets, or
2) recompile screen with BROKEN_PIPE defined in config.h, or
3) use the 'eval' command and only one 'screen -X' call.
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: Interesting things found in ncurses that affect screen
On Mon, Jul 18, 2005 at 07:37:58AM -0400, Thomas Dickey wrote:
On Mon, 18 Jul 2005, Michael Schroeder wrote:
On Mon, Jul 18, 2005 at 06:25:24AM -0400, Thomas Dickey wrote:
The code's doing what it is intended: when screen is running in UTF-8
mode, it ignores the termcap information, only accepts the UTF-8 encoding
for line-drawing characters.
No, that's not right. There once was a version of screen that
ignored termcap information, but this got changed a long time ago...
That's hard for me to see, since I haven't seen a recent changelog for
screen, so determining what it does means I get to read through the code.
*grin*. That one counted as bugfix, so there is no entry in the
changelog (aka patchlevel.h).
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
Re: screen with 256 color xterm
On Thu, Apr 21, 2005 at 01:53:52PM +0200, Johannes Segitz wrote:
Hello,
is it possible to use screen with a 256 color xterm? Setting TERM to
xterm-256color before starting screen results in scrambled output of
commands. Changing TERM from screen to xterm-256color in screen doesn't
change that. Would be very nice to have this under screen since my vim
colorscheme needs 256 colors.
You have to define COLORS256 in config.h...
Cheers,
Michael.
--
Michael Schroeder [EMAIL PROTECTED]
main(_){while(_=~getchar())putchar(~_-1/(~(_|32)/13*2-11)*13);}
___
screen-users mailing list
screen-users@gnu.org
http://lists.gnu.org/mailman/listinfo/screen-users
