[screen-devel] [bug #36676] screen shows "standout" instead of "italics" on terminals which support the latter (rxvt-unicode)

Follow-up Comment #8, bug #36676 (project screen): Hello, Same here. Any known work-arounds? [http://mesreviews.com/] ___ Reply to this item at: ___ M

Re: [screen-devel] screen maintainer?

Karl Berry wrote: And otherwise, we're looking for a new maintainer. So if you are interested in taking care of screen going forward, please write me and we can discuss. I'd be willing to pitch in, though I don't have a lot of time. I'd like to work on documentation and on patching, bugfixi

Re: [screen-devel] Re: screen maintainer?

Adam Lazur wrote: I agree, 2 sets of documentation sucks. The crusty old unix guy inside my head is screaming "DROP THE TEXINFO, IT'S EVIL", but the gnu project probably disagrees ;) I agree on both counts. I put the man page into my book, and printed a version of the Info documentation.

Re: [screen-devel] screen maintainer?

Micah Cowan wrote: Any and all help is absolutely appreciated! Regarding the documentation: are you familiar with the new vertical split, and layout features? These are things that do not appear in the documentation, but need to before a release can be made. I've heard of the vertical split, b

[screen-devel] row/column report escape sequence (and patch)

lseq.html#CSI%20Ps%20;%20Ps%20;%20Ps%20t David diff -Nru screen-4.0.2.orig/ansi.c screen-4.0.2/ansi.c --- screen-4.0.2.orig/ansi.c 2003-12-05 06:57:05.0 -0700 +++ screen-4.0.2/ansi.c 2008-06-26 22:25:26.0 -0600 @@ -1225,6 +1225,11 @@ SaveCursor(); break; case 't':

[screen-devel] Patches (and vert. splits)

I downloaded the current version from the git repository, and don't seem to see any vertical split commands anywhere (including comm.c). Also, several of the patches in the patches/* directory do not patch against the current repository; for one, the gcc4.0 patch appears to have been incorpora

[screen-devel] Requested feature: reduce bloat!

I simply cannot take in all of the features that screen has (vertical split? check. alternate xterm buffer? check. Full stdin/stdout piping capability? check. Extended registers? check. Macros? check. 256 colors? check. Multiuser? check. Scriptability? coming.) How about we *strip out* some o

[screen-devel] Another feature request

One thing that would be a good idea perhaps is a -V option: that is, an option that explains all of the optional parts that have been compiled into screen. Examples of this already exist for apache and vim, and perl I think. Also, since lua scripting is in the wings what about making the c

[screen-devel] [bug #40238] [braille.c:707]: (warning) Logical conjunction always evaluates to false: n < 0 && n > 3.

URL: Summary: [braille.c:707]: (warning) Logical conjunction always evaluates to false: n < 0 && n > 3. Project: GNU Screen Submitted by: dcb314 Submitted on: Thu 10 Oct 2013 16:10:12 GMT

[screen-devel] Screen returns 1 after successful -ls.

I was advised to send patches here. I couldn't immediately figure out how to fix it, so I made a bug (44000). Then, I figured it out, so the patch is attached. diff --git a/src/screen.c b/src/screen.c index 8b36bea..bd51b8a 100644 --- a/src/screen.c +++ b/src/screen.c @@ -1179,7 +1179,8 @@ char **a

[screen-devel] [bug #50044] Update lookup tables to support Unicode 9.0.0

Follow-up Comment #5, bug #50044 (project screen): I also use weechat inside screen, and this is now affecting me quite badly. Applying the attached patch to screen fixes it for me. I think the problem is now worse with Debian Stretch having been released, as weechat compiled with a newer glibc

[screen-devel] Re my post about UTF8 fonts corrupting the hardstatus

Hi I posted before I had signed up. If someone has replied to my post, could he cc it my personal address please? Thanks

[screen-devel] Hardstatus corruption with some unicode characters

Hi Using: Screen version 4.06.02 (GNU) 23-Oct-17 Slackware 14.2 x86_64 Terminator-gtk3 terminal Font: DejaVu Sans Mono for Powerline Book When using some of those newish characters/symbols, like beermugs, headphones, musical notes etc., the hardstatus will start behaving strangely. Also some app

Re: [screen-devel] Re my post about UTF8 fonts corrupting the hardstatus

On Fri, 27 Oct 2017 19:28:51 +0100 David Woodfall wrote: Hi I posted before I had signed up. If someone has replied to my post, could he cc it my personal address please? Thanks Hi, I guess, you mean: https://savannah.gnu.org/bugs/?52296 seems like you tried to use utf8 character in bug

[screen-devel] Using bindkey -m affects screen command line as well as the copy mode table

I've been using 'bindkey -m' to set some actions for a the keys 'y' and 'o'. I find that it has also changed the bindings for the command interface (c-a :). Now I cannot type ':source' because the 'o' is intercepted and instead a blank ' ' is printed. The same with 'y'.

Re: [screen-devel] Using bindkey -m affects screen command line as well as the copy mode table

On Mon, 6 Nov 2017 00:02:41 + David Woodfall wrote: I've been using 'bindkey -m' to set some actions for a the keys 'y' and 'o'. I find that it has also changed the bindings for the command interface (c-a :). Now I cannot type ':source' becau

Re: [screen-devel] [bug #53602] Screen corruption with some wide glyphs

On Tuesday 10 April 2018 14:03, Amadeusz Sławiński put forth the proposition: Follow-up Comment #5, bug #53602 (project screen): Yes, you can post there. No, as far as I remember it won't propagate. You can also ping me on #screen on freenode, for faster discussion. ___

Re: [screen-devel] [bug #53602] Screen corruption with some wide glyphs

On Tuesday 10 April 2018 14:03, Amadeusz Sławiński put forth the proposition: Follow-up Comment #5, bug #53602 (project screen): Yes, you can post there. No, as far as I remember it won't propagate. You can also ping me on #screen on freenode, for faster discussion. I have finally found the

[screen-devel] [bug #52248] Screen doesn't release pty TIOCEXCL on quit

Follow-up Comment #1, bug #52248 (project screen): I have just encountered this exact same issue. The symptoms are incredibly mysterious. This happens only with screen. Other tools (picocom, cu) do not enable exclusive locking on the PTY, so they work ok. After connecting to the PTY with screen,

[screen-devel] [bug #52248] Screen doesn't release pty TIOCEXCL on quit

Follow-up Comment #2, bug #52248 (project screen): It appears that for a plain TTY device, screen sets the exclusive flag when opening it, but relies on sending a break to unlock the device. The desired behavior is to always unlock the device when exiting regardless of sending a break. _

[screen-devel] [bug #52248] Screen doesn't release pty TIOCEXCL on quit

Additional Item Attachment, bug #52248 (project screen): File name: 0001-Disable-exclusive-mode-on-TTY-device-when-closing.patch Size:2 KB _

[screen-devel] [feature request: auto unscroll-lock on detach]

We run a bunch of screen sessions on some real-time processing and typically only attach to them to investigate issues. Unfortunately, sometimes we detach from the session with the session scroll-locked causing the processing to be halted until someone notices. I'm looking for a new command-line o

Re: [screen-devel] (no subject)

Hey Joe, Which screen version are you using? Try compiling from master, the issue should be solved there. -David El sáb., 6 jun. 2020 0:39, Joe Yeung escribió: > Hi, > > I am using screen to connect to /dev/pts/X which is mapped to a VM's > serial port using QEMU. > The

Re: [screen-devel] [bug #23952] Screen can't set stop/parity bits on serial

Here's a quick and dirty patch for 4.8.0 ... I didn't investigate if the BSD side allows those settings (it's BSD, screw'em) On Sun, Nov 21, 2021 at 7:54 AM Marc Haber wrote: > Follow-up Comment #1, bug #23952 (project screen): > > This has been lying around in the bug tracker for 13 years now

Re: [screen-devel] [bug #23952] Screen can't set stop/parity bits on serial

and here's the man/texinfo patch On Sun, Nov 21, 2021 at 12:59 PM david kerns wrote: > Here's a quick and dirty patch for 4.8.0 ... I didn't investigate if the > BSD side allows those settings (it's BSD, screw'em) > > > > On Sun, Nov 21, 2021 at

Re: [screen-devel] [bug #23952] Screen can't set stop/parity bits on serial

no problem. Do what you need to get it in. On Tue, Nov 23, 2021 at 6:58 AM Marc Haber wrote: > Hi David, > > I can confirm that this patch seems to work as advertised. Thank you. > > It didn't show up in the bug tracker though, are you ok with me > forwarding the patch

Re: [screen-devel] Fix Incorrect Password when reattaching

On Mon, Mar 28, 2022 at 10:39 AM Daniel Santos wrote: > Hi. > > After spending almost a whole day trying to figure out, in the Internet > and on the manual pages, why the screen program was not accepting my > password of my user in my GNU system, I found out that screen, when > installing from so

Re: [screen-devel] using screen for connecting two machines via serial port

Typically, you run getty on one computer (the host), then screen (or some other terminal emulator) on the second. getty will prompt you for a login/password and then spawn a shell. I suppose you could just spawn a shell directly (from systemctl), but that is, obviously, insecure. Ultimately, what

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

I'd argue for a global replacement of sprintf(dest, ...) to snprintf(dest, sizeof(dest)...) Unfortunately, that's probably not an automated task. from the man page: The snprintf() and vsnprintf() functions will write at most size-1 of the characters printed into the output string (the si

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Mon, Jul 8, 2024 at 8:02 AM Alex Naumov wrote: > On Mon, Jul 8, 2024 at 4:48 PM david kerns > wrote: > >> I'd argue for a global replacement of sprintf(dest, ...) to snprintf(dest, >> sizeof(dest)...) >> Unfortunately, that's probably not an automated ta

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Mon, Jul 8, 2024 at 9:11 AM Alex Naumov wrote: > > > On Mon, Jul 8, 2024 at 5:43 PM david kerns > wrote: > >> On Mon, Jul 8, 2024 at 8:02 AM Alex Naumov >> wrote: >> >>> On Mon, Jul 8, 2024 at 4:48 PM david kerns >>> wrote: >>

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Tue, Jul 9, 2024 at 6:31 AM Vincent Lefevre wrote: > > As said, you need Autoconf version 2.71 or higher. > You have only 2.69, which is very old: > > > $ autoreconf --version > > autoreconf (GNU Autoconf) 2.69 > > Copyright (C) 2012 Free Software Foundation, Inc. > [...] > > well, not sure ho

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Tue, Jul 9, 2024 at 1:00 PM Alex Naumov wrote: Install the last available autoconf: https://packages.fedoraproject.org/pkgs/autoconf/autoconf/ GASP! install from source onto RHEL? where's the stability in that?? lol ok, I found the solution: sudo yum install autoconf-latest of course, then yo

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Wed, Jul 10, 2024 at 1:35 AM Alex Naumov wrote: > > Hey David. > Thank you for the patch. > It looks like this patch alarm user in case of overflow, right? We don't > need to alarm users. We need the stable bug free code. > The task is to find all cases where overflow

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Wed, Jul 10, 2024 at 5:49 AM Alex Naumov wrote: > Ok, then remove it please and show us what we're going to have in git. > I modified the .patch file directly snprintf_3.patch Description: Binary data

Re: [screen-devel] [PATCH] Really avoid a potential buffer overflow for 'home'

On Wed, Jul 10, 2024 at 7:33 AM Alex Naumov wrote: > I still don't understand why we need this? > > REPORT_SNPRINTF(max, sizeof(buf)) > Adding a length limit to prevent a buffer overflow protects against malicious intentions. However, It truncates the destination string to something less than ma

Re: [screen-devel] [bug #66147] screen crashes in attacher.c:465 when compiled with FORTIFY_SOURCE=3

On Fri, Aug 30, 2024 at 3:01 AM anonymous wrote: > > Indicating that > https://git.savannah.gnu.org/cgit/screen.git/tree/src/attacher.c#n465 > causes > the crash. > > unsolicited input :) as I read it: p = m.m.command.cmd; n = 0; for (; *av && n < MAXARGS - 1; ++av, ++n)

Re: [screen-devel] [bug #66147] screen crashes in attacher.c:465 when compiled with FORTIFY_SOURCE=3

On Fri, Aug 30, 2024 at 5:39 AM david kerns wrote: > > On Fri, Aug 30, 2024 at 3:01 AM anonymous wrote: > >> >> Indicating that >> https://git.savannah.gnu.org/cgit/screen.git/tree/src/attacher.c#n465 >> causes >> the crash. >> >> &

[screen-devel] [bug #66153] Several acconfig.h variables are undefined in 5.x

: None Planned Release: None Work Required: None ___ Follow-up Comments: --- Date: Sat 31 Aug 2024 05:58:45 PM UTC By: David Gilman The file acconfig.h was removed in

[screen-devel] [bug #14277] Compile fails on solaris

Follow-up Comment #14, bug #14277 (project screen): Why is this closed? The bug is still in the latest release and I don't see any evidence here that's been committed to the latest sources. So unless I'm mistaken, the bug is still present. Dave __