[screen-devel] [bug #65748] Change name of window when width too small disables the function entirely

[anonymous]

Follow-up Comment #2, bug #65748 (group screen):

Thanks, I appreciate it! I'll just wait for the next release then.

David E Larsson


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #65748] Change name of window when width too small disables the function entirely

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?65748>

 Summary: Change name of window when width too small disables
the function entirely
   Group: GNU Screen
   Submitter: None
   Submitted: Wed 15 May 2024 09:46:46 AM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.1
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Wed 15 May 2024 09:46:46 AM UTC By: Anonymous
If a window is too narrow to change the name of it by pressing ctrl+a A, that
function is disabled entirely. Even after making the window bigger or worse,
even if you change to a different window, pressing ctrl+a A doesn't do
anything. Thus the message has been shown ('Width XX too small'), you can
never change any window's name anymore.

This bug doesn't seem to appear in the master branch, but is present back to
at least 2018 in the screen-v4 branch.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65748>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #65631] Starting screen session detached causes higher than usual CPU usage

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?65631>

 Summary: Starting screen session detached causes higher than
usual CPU usage
   Group: GNU Screen
   Submitter: None
   Submitted: Tue 23 Apr 2024 03:18:56 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Tue 23 Apr 2024 03:18:56 PM UTC By: Anonymous
Hello,

I've come across a problem with specifically screen with the switches -d -m.
The switches seem to cause the CPU usage to sit at around 100% single core
usage for the server and just over 50% usage for screen itself. Attaching
session also fails to pass keystrokes properly (keystrokes end up sending
outside of screen session for some reason?)

Issue seems to occur exclusively with BeamMP-Server (Multiplayer server for
BeamNG Drive, https://github.com/BeamMP/BeamMP-Server ).

screen ./BeamMP-Server <- no issues
screen -d -m ./BeamMP-Server <- High CPU usage

System Info:
Debian 12 (bookworm)
Kernel 6.1.0-20-amd64
Core2Duo E8400






___
File Attachments:


---
Name: screen@no@switches@.png  Size: 8KiB
<https://file.savannah.gnu.org/file/screen@no@switches@.png?file_id=55960>
---
Name: running@outside@o...@screen.png  Size: 9KiB
<https://file.savannah.gnu.org/file/running@outside@o...@screen.png?file_id=55961>
---
Name: screen@w...@switches.png  Size: 8KiB
<https://file.savannah.gnu.org/file/screen@w...@switches.png?file_id=55959>

AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://git.savannah.nongnu.org/cgit/administration/savane.git/snapshot/savane-d3aec29d5294756baedbbbd2796ad0b2d841864b.tar.gz

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65631>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #65513] Escape code handling rewrites codes between application and terminal

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?65513>

 Summary: Escape code handling rewrites codes between
application and terminal
   Group: GNU Screen
   Submitter: None
   Submitted: Mon 25 Mar 2024 12:46:16 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Mon 25 Mar 2024 12:46:16 AM UTC By: Anonymous
Due to its the escape code handling resulting in an internal simulation of the
effect rather than recording of the code, screen can emit different escape
codes from those it was originally given. In some cases the substituted codes
are not equivalent, depending on the terminal.

This is particularly noticeable with recent coreutils' colourisation of 'ls'
output, as since commit 52aeae2c ("dircolors: colorize backup files with
bright black"), this has potentially included aixterm rendition codes. The bug
becomes evident in the linux virtual console when backup files listed are
interspersed with regular files - "bright black" (ie. grey) colour is seen as
expected, but regular files may be in standard white or bold white depending
on whether they appear first or last.

Capturing the output of `printf '%b' "TERM=$TERM: " '\033[90m' '(90m)'
'\033[0m' '(0m)' '\033[1m' '(1m)' '\033[0m' '(0m)\n'` with /usr/bin/script is
informative, with "TERM=linux: ^[[90m(90m)^[[0m(0m)^[[1m(1m)^[[0m(0m)^M"
resulting from output capture in the linux terminal and "TERM=screen.linux:
^[[90m(90m)^[[39m(0m)^[[1m(1m)^[[m^O(0m)^[[10;1H" from output under screen. On
a monitor it is evident that the behaviour of the linux console differs from
screen's internal emulation: specifically a bold attribute is also added by
the former, which in this demonstration remains in effect until manually
requested and then cancelled. When demonstrating with 'ls', a suitably-named
executable file has a similar restorative effect.

https://unix-junkie.github.io/christmas/Comparison%20of%20Terminal%20Emulators%20-%20Colour%20Support.html
suggests other graphical terminals also use this interpretation of the aixterm
colour codes and may therefore be similarly affected by inappropriate
substitution of the 'sgr0' escape sequence.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65513>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64789] Hexadecimal zeroes (0x00) characters are not send

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?64789>

 Summary: Hexadecimal zeroes (0x00) characters are not send
   Group: GNU Screen
   Submitter: None
   Submitted: Wed 18 Oct 2023 02:50:18 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Wed 18 Oct 2023 02:50:18 PM UTC By: Anonymous
When trying to send a raw binary value using hexadecimal notation such as
"screen -X stuff $'\xB5\x62\x0A\x04\x00\x00\x0E\x34'", the 0x00 bytes are not
send at all. I checked it with an oscilloscope.

I suppose there is something related to interpreting the string as null. This
must work, plain C++ using a boost library is able to send raw 0x00.

This bug makes the tool not capable of using it to send binary data.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64789>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63619] screen crashes on reattach in st terminal

[anonymous]

Follow-up Comment #5, bug #63619 (project screen):

Currently on Gentoo, was having issues with st and can confirm the patch fixed
it. 

example patch file, located in
/etc/portage/patches/app-misc/screen/st-fix.patch


diff --git a/os.h b/os.h
index 2a1c2ca..40402ae 100644
--- a/os.h
+++ b/os.h
@@ -507,7 +507,7 @@ typedef struct fd_set { int fds_bits[1]; } fd_set;
  */
 
 #ifndef TERMCAP_BUFSIZE
-# define TERMCAP_BUFSIZE 1023
+# define TERMCAP_BUFSIZE 
 #endif
 
 #ifndef MAXPATHLEN




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63619] screen crashes on reattach in st terminal

[anonymous]

Follow-up Comment #4, bug #63619 (project screen):

Hi, I don't know if this is helpful but just wanted to confirm that this
happens for me on Arch linux, signal 11 caught when I try to reattach to a
local screen session in st. Reattach works fine in the framebuffer console,
and works fine over ssh to another Arch box, so this certainly seems to be a
st specific problem, but not a MacOS specific one.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64669] An English grammar error, possibly caused by a typo: a window, not an window.

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?64669>

 Summary: An English grammar error, possibly caused by a typo:
a window, not an window.
   Group: GNU Screen
   Submitter: None
   Submitted: Thu 14 Sep 2023 03:08:08 PM UTC
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: Cur Dev Sources
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Thu 14 Sep 2023 03:08:08 PM UTC By: Anonymous
There is an English grammar error in the documentation. Possibly caused by a
typo:

Referring to
https://git.savannah.gnu.org/cgit/screen.git/tree/src/doc/screen.texinfo#n1526


This section describes the commands for switching between windows in an

That should be a. Not an. For readiness, the next line, n1527, begins with
@code{screen} session.
For an explanation of the grammar rule see 
https://lists.debian.org/debian-l10n-english/2023/09/msg8.html .








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64669>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64659] Bad cursor offset with UTF-8 combining characters

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?64659>

 Summary: Bad cursor offset with UTF-8 combining characters
   Group: GNU Screen
   Submitter: None
   Submitted: Tue 12 Sep 2023 11:55:30 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.1
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Tue 12 Sep 2023 11:55:30 PM UTC By: Anonymous
When outputting text with UTF-8 combining characters, such as diacritics, the
resulting cursor position appears to be internally inconsistent.

I'm attaching a test program that produces different output between Screen and
directly in the outer terminal. The displayed text will also change within GNU
Screen itself depending on how it gets redrawn (scrolling one line at a time
vs. with pgup/pgdn, or switching between panes).

I don't think this is the same as bug #51890 or bug #63634, though it may be
related.

Thanks for maintaining GNU Screen!






___
File Attachments:


---
Date: Tue 12 Sep 2023 11:55:30 PM UTC  Name: combining.c  Size: 4KiB   By:
None
Test program that prints the letter A with various diacritics
<http://savannah.gnu.org/bugs/download.php?file_id=55132>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64659>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64601] Resizing the terminal while changing a window's title with (C-a A) prevents you from ever using (C-a A) again

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?64601>

 Summary: Resizing the terminal while changing a window's
title with (C-a A) prevents you from ever using (C-a A) again
   Group: GNU Screen
   Submitter: None
   Submitted: Sun 27 Aug 2023 03:18:30 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Sun 27 Aug 2023 03:18:30 AM UTC By: Anonymous
# Steps to reproduce:
1. Open screen.
2. Press (C-a A) to bring up the prompt to change the window's title.
3. Resize the terminal window.
4. Observe the "Aborted because of window size change" message.
5. Press (C-a A) again.

# Expected behavior:
The prompt to change the window's name appears.

# Actual behavior:
Nothing happens.

# Workarounds:
You can still bring up the command line with (C-a :) and use the `title`
command to rename the window.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64601>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63619] screen crashes on reattach in st terminal

[anonymous]

Follow-up Comment #3, bug #63619 (project screen):

I don't think you need MacOS to reproduce this. I run some gentoo linux
installations, I use st as a terminal emulator, and screen crashes regularly
with 'sig 11 caught' when I try to reaattach to a screen session. This
workaround makes screen at least usable again for me.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[anonymous]

Follow-up Comment #18, bug #36676 (project screen):


> Strange, for me master branch works with italics in xterm (vim user here)

You are right. After taking a careful look, it's a tricky issue. Emacs does
indeed have italics support after switching to screen master. However, it is
broken. What should be italics, is displayed underlined. But some italics show
up now e.g. in the menu bar. And outside Emacs, but still inside screen, xterm
now displays italics correctly.

It would be great if a new release of screen could be made to get this feature
on regular package managers. In the meantime, I will try to figure out what is
wrong with Emacs.



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[anonymous]

Follow-up Comment #17, bug #36676 (project screen):

[comment #16 comment #16:]
> I just tested master branch (rev 6931ba07ca1646df8dee85485f9867b23b34fcf1)
using xterm (v383) and emacs (29.1). It did not work, italics showed up as
underlined characters. Running emacs on the same setup but outside screen
worked as expected.

Strange, for me master branch works with italics in xterm (vim user here)
since almost two years. This is main reason to compile screen myself. May be
check your terminfo/whatever emacs uses, perhaps it do not see itself in a
position to allow italics rendering? Or output raw escape codes directly in
shell to check if it works.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[anonymous]

Follow-up Comment #16, bug #36676 (project screen):

I just tested master branch (rev 6931ba07ca1646df8dee85485f9867b23b34fcf1)
using xterm (v383) and emacs (29.1). It did not work, italics showed up as
underlined characters. Running emacs on the same setup but outside screen
worked as expected.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[anonymous]

Follow-up Comment #14, bug #36676 (project screen):

This bug shows up with status fixed, but still affects the current release
(Screen version 4.09.00 (GNU) 30-Jan-22) used together with mainstream
terminals such as xterm or rxvt-unicode.

As other users have noted, this is a quite annoying issue as it makes it hard
to use Emacs inside Screen. Lots of modern Emacs packages display a lot of
colored and italics text, which due to this issue shows up with long broken
underlines beneath.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64378] screen manpage has misleading bash example

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?64378>

 Summary: screen manpage has misleading bash example
   Group: GNU Screen
   Submitter: None
   Submitted: Mon 03 Jul 2023 06:40:44 PM UTC
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Mon 03 Jul 2023 06:40:44 PM UTC By: Anonymous
Bug fixed in Ubuntu, discussion at
https://bugs.launchpad.net/ubuntu/+source/screen/+bug/1986839
where they asked me to submit the bug upstream.  Patch is included there as
well; savannah will not let me attach diff here.

Quoted from that linked page:

The screen(1) page in version 4.09.00 describes the 'shell' command/option
ending with

   [...] If the command begins with a '-' character, the shell
   will be started as a login-shell. Typical shells do only
   minimal initialization when not started as a login-shell.
   E.g. Bash will not read your ~/.bashrc unless it is a login-shell.

This is incorrect and misleading. According to the bash(1) page, it only looks
for ~/.bash_profile (and similar files) for a login shell, but looks for
~/.bashrc when "an interactive shell that is not a login shell is started".

Obviously minor priority, but should be trivial to fix since it's just an
example filename.










___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64378>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64254] Attach a screen sessoin without being forced to provide a password

[anonymous]

Follow-up Comment #4, bug #64254 (project screen):

@nathnialjohn - i think the password /command/ has been removed from the most
recent version of screen, which included the ability to set an arbitrary
password or disable it. 

I think you are looking at old documentation.

It now apparently always uses PAM to authenticate the account. 


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #64254] Attach a screen sessoin without being forced to provide a password

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?64254>

 Summary: Attach a screen sessoin without being forced to
provide a password
   Group: GNU Screen
   Submitter: None
   Submitted: Fri 26 May 2023 02:09:14 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: Cur Dev Sources
 Discussion Lock: Any
   Fixed Release: 5.0.0
 Planned Release: 5.0.0
   Work Required: None


___

Follow-up Comments:


---
Date: Fri 26 May 2023 02:09:14 AM UTC By: Anonymous
Dear screen maintainers & devs, 

Thanks for maintaining GNU screen!

>From ChatGPT I learnt, that in "GNU Screen 4.99 (or current dev branch), the
ability to disable passwords was removed, and there is no straightforward
configuration option to achieve this. Password authentication is now enforced
by default in GNU Screen 4.99 and later versions."

I couldn't figure out a way using the docs to disable GNU screen's password
prompt when re-attaching a detached session. 

My issue and my temporary workaround is described here: 
https://marcgloor.github.io/gnuscreenpatch.html

Can you confirm that the ability to disable passwords was intentionally
removed? If so, I would request this option to be re-added to the program
logic again. 

Thanks
Marc







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?64254>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63341] Copy mode (Ctrl-A ESC) blocks stdout

[anonymous]

Follow-up Comment #3, bug #63341 (project screen):

I love screen, but I agree that the original posted described a bug.  When I
enter copy/scrollback mode, I certainly do not intend to "pause the output". 
All I am trying to do is to scrollback to read the terminal messages that are
inaccessible because screen blocks the usual scrolling mechanism.  

Incidentally, a Google search suggests that a possible solution is to add a
line to the .screenrc file:

# Enable scrolling
termcapinfo xterm* ti@:te@



  


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63870] Monochrome mode

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63870>

 Summary: Monochrome mode
   Group: GNU Screen
   Submitter: None
   Submitted: Sun 05 Mar 2023 02:10:50 AM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Sun 05 Mar 2023 02:10:50 AM UTC By: Anonymous
Can we get a command or switch I can pass to "screen" on the command line to
force the TERMCAP/terminfo to always be monochrome?

Why am I asking this?  Well, I want to put a status display up on a HP 100LX
(which is connecting to a Raspberry Pi Zero with an Ethernet adapter via
serial port cable).  It only does 2-bit greyscale (black, white, and 2 greys)
because it's an LCD screen.

If I do the following:

1. set TERM to "pcansi-m" 
2. run "screen -S test" on the Pi Zero
3. connect to the Pi Zero from the HP 100LX  (serial connection)
4. set TERM to "pcansi25m" (terminal does 25 lines )
5. run "screen -x test" on the serial connection
6. run "set | grep TERMCAP"

...and the "AX" capability is set. It should be cleared (not showing).  Color
is wasted on the HP 100LX and screen (if told "force monochrome") shouldn't
turn it on.








___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63870>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63473] Attaching to session started with -Dm vertically centers prompt

[anonymous]

Follow-up Comment #2, bug #63473 (project screen):

Looks like the height of the daemon is fixed leading to the problem I
encountered.  I wonder if it should make use of the screen size instead or if
there is a way to align the resize to the top of the screen instead of the
bottom.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

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

[anonymous]

Follow-up Comment #13, bug #36676 (project screen):

I can still see the issue happening on 4.08.00 (Debain package 4.8.0-6).

The command `printf "\e[3mitalics\n\e[0m"` 

- Outside of screen italic text works fine (both on TerminalApp and ttyd)
- Inside screen it renders as reverse video




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63473] Attaching to session started with -Dm vertically centers prompt

[anonymous]

Follow-up Comment #1, bug #63473 (project screen):

Looks like the detached command spawns with a height of 24 then the attach
command spawns with the real height (say 62) and the ensuing resize results in
38 lines of padding above the prompt.

So I am not sure this is actually a bug although it does bring some
difficulties to my use case.  Should the detach command be taking into account
the size of the terminal that spawned it?  Is there a way to provide it with a
size?  Looking into it now...

Alternatively it would also work if there was a way to make the resize move
with the top rather than the bottom as it currently does.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63361] Screen should also put cursor at 1 in LineFeed if autolf is on.

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63361>

 Summary: Screen should also put cursor at 1 in LineFeed if
autolf is on.
 Project: GNU Screen
   Submitter: None
   Submitted: Mon 14 Nov 2022 03:19:43 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Mon 14 Nov 2022 03:19:43 AM UTC By: Anonymous
https://vt100.net/docs/vt510-rm/LNM.html

diff --git a/src/ansi.c b/src/ansi.c
index 9ee4ffa..3c83ded 100644
--- a/src/ansi.c
+++ b/src/ansi.c
@@ -1493,7 +1493,7 @@ static void Return(Window *win)
 static void LineFeed(Window *win, int out_mode)
 {
/* out_mode: 0=lf, 1=cr+lf */
-   if (out_mode)
+   if (out_mode || win->w_autolf)
win->w_x = 0;
if (win->w_y != win->w_bot) {   /* Don't scroll */
if (win->w_y < win->w_height - 1)







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63361>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63361] Screen should also put cursor at 1 in LineFeed if autolf is on.

[anonymous]

Follow-up Comment #1, bug #63361 (project screen):

I meant 0 but my brain was thinking "first column"



___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63341] Copy mode (Ctrl-A ESC) blocks stdout

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63341>

 Summary: Copy mode (Ctrl-A ESC) blocks stdout
 Project: GNU Screen
   Submitter: None
   Submitted: Thu 10 Nov 2022 07:24:54 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Thu 10 Nov 2022 07:24:54 PM UTC By: Anonymous
scroll.py:


#!/usr/bin/env python3
import time
with open("/tmp/scroll", mode="w") as f:
t1 = time.time()
while True:
t2 = time.time()
tdiff = t2 - t1
t1 = t2
text = f"tdiff={tdiff} {'' if tdiff > 0.5 else ''}"
print(text, flush=True)
print(text, flush=True, file=f)
time.sleep(0.01)


Steps to reproduce:

- Run './scroll.py' in a screen session
- Run 'tail -f /tmp/scroll' in another terminal
- Press 'Ctrl-A ESC' to enter copy mode

After a few seconds, the 'tail' output freezes.  Exiting copy mode generates
this output:


tdiff=0.010303020477294922 
tdiff=5.808627605438232 
tdiff=0.010957002639770508 


I think this behavior is a bug, because it violates the principle of least
surprise.  Scrolling up or selecting text in a terminal should never block
program execution. Screen could be a nice tool for running simple daemons,
except that copy mode is basically an outage generator.

What could screen do when the scrollback buffer is full?
1. Kick the user out of copy mode
2. Make a copy of the currently-visible buffer region







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63341>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63217] Add OSC 52 support to set OS clipboard (includes patch)

[anonymous]

Follow-up Comment #2, bug #63217 (project screen):

Sure thing, I've merged your patch and mine to support OSC 10/12/52.

Best regards,

Nieko Maatjes

(file #53920)

___

Additional Item Attachment:

File name: screen-osc-10-12-52.diff   Size:3 KB
   




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63217] Add OSC 52 support to set OS clipboard (includes patch)

[anonymous]

Follow-up Comment #1, bug #63217 (project screen):

If you are in that part of the code anyway, can you also fix the sequence for
auto-detecting light/dark themes? I can attach a patch for that although not
compatible with the already posted one.

-Neal Fultz

(file #53878)

___

Additional Item Attachment:

File name: screen-osc.patch   Size:5 KB




___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63217] Add OSC 52 support to set OS clipboard (includes patch)

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63217>

 Summary: Add OSC 52 support to set OS clipboard (includes
patch)
 Project: GNU Screen
   Submitter: None
   Submitted: Sat 15 Oct 2022 03:06:38 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.99.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Sat 15 Oct 2022 03:06:38 PM UTC By: Anonymous
Hello!

The OSC 52 escape sequence allows for programs to write to the OS's clipboard,
which e.g. makes it possible to copy text programmatically, and/or from a
remote session without having to use the mouse.

Screen sorts of supports this when wrapping the OSC 52 sequence in DCS
markers, e.g. like this:
printf "\033P\033]52;c;$(printf "%s" "test" | base64)\a\033\\"

However, this doesn't work in nested screens.

The included patch adds OSC 52 support to screen itself, so the DCS markers
are no longer necessary. (They continue to work just fine, though.)

Best regards,

Nieko Maatjes






___
File Attachments:


---
Date: Sat 15 Oct 2022 03:06:38 PM UTC  Name: screen.diff  Size: 3KiB   By:
None

<http://savannah.gnu.org/bugs/download.php?file_id=53860>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63217>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63212] variables do not show in status bar

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63212>

 Summary: variables do not show in status bar
 Project: GNU Screen
   Submitter: None
   Submitted: Fri 14 Oct 2022 01:55:42 PM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: Cur Dev Sources
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Fri 14 Oct 2022 01:55:42 PM UTC By: Anonymous
noticed with version 4.99.0 ; still occurs in c3e84d2


in my config, I have:

hardstatus alwayslastline '%{-b gk}[%{-b Y}%D %d, %c%{-b g}]-[%{+b Y}%l%{-b
g}] (%{-b yk}%-Lw%50>%{yr}%n%f* %t%{yk}%+Lw%<%{-b gk})%=[%{+b Wk}%H%{-b gk}]'


it stopped working properly when I decided to have truecolor in my term and
moved from 4.9.0 to 4.99.0


it is independent of whether "truecolor on" is set in config or not.

it is independent of the terminal (tested in xterm, urxvt, and on a
framebuffer console)

colored status line also went from "bright colors scheme" to "dull gray
scheme"

attachment shows on the bottom left 4.9.0 ; overlapping is 4.99.0






___
File Attachments:


---
Date: Fri 14 Oct 2022 01:55:42 PM UTC  Name: screen.png  Size: 14KiB   By:
None

<http://savannah.gnu.org/bugs/download.php?file_id=53850>

___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63212>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #63096] IPV6 utmp entry shorthand address should include least significant bytes

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?63096>

 Summary: IPV6 utmp entry shorthand address should include
least significant bytes
 Project: GNU Screen
   Submitter: None
   Submitted: Fri 23 Sep 2022 02:40:53 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Fri 23 Sep 2022 02:40:53 PM UTC By: Anonymous
When gnu-screen writes into utmp the IPv6 address of connected ptys, it looks
like:

user pts/0Sep 23 07:18 (2602:512a:b522:551e:3f90:1da6:437c:3a49)
user pts/1Aug 21 08:42 (2602:S.0)
user pts/2Aug 21 08:42 (2602:S.1)
user pts/4Sep 16 17:02 (2602:S.2)

when there's IPv6 addresses that can't be reverse resolved.  The prefix 2602::
could mean a LOT of different hosts.  The suggestion is to use the least
significant digits of the IPV6 address (...3a49:S.0), or perhaps
(2602...3a49:S.x) in the utmp entries.

Note that the shorthand was probably meant for chopping up fully resolved
names and not unresolvable IPV6 numeric IP addresses.  The current handling,
if it effectively were used for IPv4, would show as (127:S.0) for 127.0.0.1
which again is a lot of hosts, and would venture that using even (127...1:S.0)
or (...1:S.0) would be more useful to people debugging connections, where one
could look in the kernel IP connection tables to find the remote address.







___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?63096>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #62667] httpss -> https

[anonymous]

Follow-up Comment #1, bug #62667 (project screen):

Argh, the first 2 times it said it hadn't been accepted because I didn't enter
the Orwell book's name.


___

Reply to this item at:

  

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #62667] httpss -> https

[anonymous]

URL:
  <https://savannah.gnu.org/bugs/?62667>

 Summary: httpss -> https
 Project: GNU Screen
   Submitter: None
   Submitted: Thu 23 Jun 2022 08:53:34 PM UTC
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None


___

Follow-up Comments:


---
Date: Thu 23 Jun 2022 08:53:34 PM UTC By: Anonymous
I wanted to be funny with this by including just the patch (given the last 2
log messages), but I think the URLs below are going to be stripped.  The
ironic joke is that it wasn't going to be funny anyway!

The bug is that the latest commit (c3e84d) did http -> httpss.


diff --git i/COPYING w/COPYING
index e69192f..771760c 100644
--- i/COPYING
+++ w/COPYING
@@ -1,7 +1,7 @@
 GNU GENERAL PUBLIC LICENSE
Version 3, 29 June 2007
 
- Copyright (C) 2007 Free Software Foundation, Inc. 
+ Copyright (C) 2007 Free Software Foundation, Inc. <https://fsf.org/>
  Everyone is permitted to copy and distribute verbatim copies
  of this license document, but changing it is not allowed.
 









___

Reply to this item at:

  <https://savannah.gnu.org/bugs/?62667>

___
Message sent via Savannah
https://savannah.gnu.org/

[screen-devel] [bug #62010] Configure script is missing from release

[anonymous]

URL:
  

 Summary: Configure script is missing from release
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 08 Feb 2022 12:04:24 PM UTC
Category: Build/Install
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.9.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: 4.9.0
   Work Required: None

___

Details:

Instructions still say to run "sh ./configure" - however "configure" is not in
the release, so we get an error - "Can't open ./configure"

I apologize if I'm missing something obvious

Thank you!




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #61534] long session names break screen with no error message/rails

[anonymous]

URL:
  

 Summary: long session names break screen with no error
message/rails
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 23 Nov 2021 07:22:00 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

screen will allow you to specify a long session name without error, but does
not work if your session name is too long.  For initial sessions, this causes
there to be no session created, but no error:

jmcminn@dukhat:~$ screen -S
averyverylongsesssionname
-d -m bash -c 'ping -c 600 localhost'
jmcminn@dukhat:~$ screen -ls
No Sockets found in /run/screen/S-jmcminn.

jmcminn@dukhat:~$

For renamed sessions, the rename command takes, but results in a "Dead"
session that cannot be attached to or further interacted with:

jmcminn@dukhat:~$ screen -S shortname -d -m bash -c 'ping -c 600 localhost'
jmcminn@dukhat:~$ screen -ls
There is a screen on:
102297.shortname(11/23/2021 11:00:57 AM)(Detached)
1 Socket in /run/screen/S-jmcminn.
jmcminn@dukhat:~$ screen -S shortname -X sessionname
averyverylongsesssionname
jmcminn@dukhat:~$ screen -ls
There is a screen on:

102297.averyverylongsesssionname
(11/23/2021
11:00:58 AM)(Dead ???)
Remove dead screens with 'screen -wipe'.
1 Socket in /run/screen/S-jmcminn.
jmcminn@dukhat:~$




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #61504] screen within screen cuts off argument lists

[anonymous]

URL:
  

 Summary: screen within screen cuts off argument lists
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 18 Nov 2021 01:08:13 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.6.2
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Within a screen session, I did

screen make -kj28 {1..1}.task

and it behaved as if I had only passed the first sixty parameters.

REPRO: If you have a script t.sh

#!/bin/sh
echo $#
sleep 5

then 'screen ./t.sh {1..100}' displays 101 and pauses for five seconds, whilst
'screen screen ./t.sh {1..100}' displays 62 




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #61392] cursor shape is not correct when I switch or exit a window

[anonymous]

URL:
  

 Summary: cursor shape is not correct when I switch or exit a
window
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 27 Oct 2021 04:01:01 AM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Here is my ~/.inputrc file:

set editing-mode vi
set show-mode-in-prompt on
set vi-cmd-mode-string "\1\eP\e[2 q\e\\\2"
set vi-ins-mode-string "\1\eP\e[6 q\e\\\2"
set keymap vi-insert
return: "\e\n"

How to reproduce:

0 Create a window, the cursor should show a vertical bar
0 Create another window, cursor shows a vertical bar too
0 Input "exit" then press Enter key, the second window will exit

Now you can see a block cursor in the first window, but it is expected to
remain a vertical bar.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #61354] prevent xterm resizing on startup

[anonymous]

URL:
  

 Summary: prevent xterm resizing on startup
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 19 Oct 2021 02:45:28 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

screen without -A resize the xterm window upon startup (and upon suspend or
exit too).

We'd want a way to configure in .screenrc the -A option to prevent any xterm
resizing at all by default.





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #60985] no passthru if unbindall

[anonymous]

URL:
  

 Summary: no passthru if unbindall
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 28 Jul 2021 08:28:39 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: Cur Dev Sources
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Hi,
I put unbindall in my .screenrc file.

I noticed that if I press control A or control B they are not received by the
underlying shell.

Is there a way to do so?





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #60949] Screen session closes even though the I/O is still there

[anonymous]

URL:
  

 Summary: Screen session closes even though the I/O is still
there
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 20 Jul 2021 08:52:27 AM UTC
Category: Crash/Freeze/Infloop
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: Later
   Work Required: None

___

Details:

When you start my Java-App via screen and my app tries to self-update, the
screen session just closes in the middle of it.
This is how the self-updater works:
1. Download update-jar into /downloads and make a copy of the downloaded
update-jar also in /downloads
2. Start the update-jar (which detects that it is inside the /downloads dir)
and close itself
NOTE: The I/O never closes because the update-jar inherits it.
This means that on regular windows/ubuntu terminals this works without
problem.
3. The update-jar now replaces the original jar with its copy and starts the
original (now updated) jar




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #58132] screen -r hangs terminal

[anonymous]

Additional Item Attachment, bug #58132 (project screen):

File name: screen.dumpSize:0 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #59183] Switching regions with the mouse fails with wide regions

[anonymous]

URL:
  

 Summary: Switching regions with the mouse fails with wide
regions
 Project: GNU Screen
Submitted by: None
Submitted on: Sat 26 Sep 2020 09:12:19 AM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.8.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

I'm trying to determine if this is a bug in screen, related to switching
regions with the mouse when using a wide monitor.

To reproduce:

screen
C-a | # vertical split
C-a TAB   # change focus to new region
C-a c # new window
C-a : mousetrack on

I can now click with my mouse to move back and forth between the two regions,
each with its own window.

However, if I make my terminal emulator window sufficiently wide (either
before or after the above procedure),
I can no longer click on the right region/window to activate it.

I can make the two windows have a width of 222 and 223 cols, respectively (as
measured by "tput cols"),
by dragging the terminal emulator window to resize it. Soon after that, I can
no longer select the righthand region/window
with the mouse. 

The most intriguing thing from googling was an old post/patch related to a
similar problem with a similar magic number, 223 = 255 - 32.

https://lists.gnu.org/archive/html/screen-devel/2012-07/msg4.html
https://stackoverflow.com/questions/24700444/gnu-screen-mouse-limitation


I am using iTerm2 and this version of screen, from MacPorts:

$ screen --version
Screen version 4.08.00 (GNU) 05-Feb-20

$ echo $TERM
xterm-256color

Snippet from screen startup:

Capabilities:
+copy +remote-detach +power-detach +multi-attach +multi-user +font
+color-256 +utf8 +rxvt +builtin-telnet

I see the same behavior if I use a different terminal emulator (OS X
Terminal.app) and/or if I SSH to an Ubuntu 18.04.5 LTS machine and run screen
with version

$ screen --version
Screen version 4.06.02 (GNU) 23-Oct-17





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #59056] Add tab completion to window select mode

[anonymous]

URL:
  

 Summary: Add tab completion to window select mode 
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 02 Sep 2020 11:21:10 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

It would be nice if there was tab completion during the window select (')
operation.  If I have two windows that have the first few characters the same,
and I enter just those common characters and press ENTER, Screen takes me to
the first matching window. It would be nice if pressing TAB either expanded
the window name, or showed me a list of matching names to allow me to finish
my selection.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #59013] Incorrect logic for SOCKET_DIR (/run/screen) permissions

[anonymous]

URL:
  

 Summary: Incorrect logic for SOCKET_DIR (/run/screen)
permissions
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 26 Aug 2020 02:22:40 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.6.2
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

screen.c (near lines 809 - 812)
Program is using the running user and their access as the master permissions
on the directory for all users.  Hence, screen constantly panics mandating
different permissions when multiple users (of differing privleges) attempt
execution.

Program should not be mandating permissions for access beyond current user's
scope.

Tested in Fedora 31 with packaged RPM.
SOCKET_DIR = /run/screen and is a common base directory for user sub-directory
holding sockets.

When /run/screen is not 755:
User owning directory receives panic demanding 755 permissions.
(This demonstrates the bug.)

When /run/screen is 777:
User with group access receives panic demanding 775 permissions.
(This demonstrates the bug.)

When /run/screen is 775:
User with world access receives panic demanding 777 permissions.






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #58527] MacOS 1500000 baud problem?

[anonymous]

URL:
  

 Summary: MacOS 150 baud problem?
 Project: GNU Screen
Submitted by: None
Submitted on: Mon 08 Jun 2020 01:33:07 AM UTC
Category: Build/Install
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.99.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Hi,

Is screen on MacOS uncapable of doing B150 ?
~~
% make
gcc -c -iquote. -DSCREENENCODINGS='"/usr/local/share/screen/utf8encodings"'
-DBUILD_DATE='"2020-06-08 03:06:45"' -g -O2 -Wall -Wextra -std=c11 tty.c -o
tty.o
tty.c:1090:12: error: use of undeclared identifier 'B150'
{150, B150},
  ^
1 error generated.
make: *** [tty.o] Error 1
% 
~~




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #58132] screen -r hangs terminal

[anonymous]

URL:
  

 Summary: screen -r hangs terminal
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 07 Apr 2020 03:17:07 AM UTC
Category: Crash/Freeze/Infloop
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: None
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: 4.8.0
   Work Required: None

___

Details:

On screen version 4.8.0, attempting to reattach to a detached session with
screen -r hangs. The session is not displayed, and the only way to get out is
to kill the terminal. Processes under the session continue running, but there
is no way to reattach to the session itself.

Encountered on the current version of Arch GNU/Linux both with the
distribution provided package of screen 4.8.0 and the source 4.8.0. Problem is
not present source build of 4.7.0.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #58014] sched.h must be renamed to avoid a build failure with uclibc

[anonymous]

URL:
  

 Summary: sched.h must be renamed to avoid a build failure
with uclibc
 Project: GNU Screen
Submitted by: None
Submitted on: Sat 21 Mar 2020 05:33:15 PM UTC
Category: Build/Install
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Release: 4.7.0
 Discussion Lock: Any
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

There is a  system header that got shadowed by "sched.h".
While Screen itself doesn't include , other system headers might
include it indirectly. This broke the build when using uClibc with pthread
support.

To fix this build failure, we have patched screen for nearly 6 years in
buildroot with
https://git.buildroot.net/buildroot/tree/package/screen/0005-rename-sched_h.patch

You'll find attached an updated version of this patch.



___

File Attachments:


---
Date: Sat 21 Mar 2020 05:33:15 PM UTC  Name:
0001-Renamed-sched.-c-h-to-eventqueue.-c-h.patch  Size: 13KiB   By: None



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #57748] Screen buffers ESC keypresses indefinitely since sgr support patch

[anonymous]

URL:
  

 Summary: Screen buffers ESC keypresses indefinitely since sgr
support patch
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 05 Feb 2020 11:21:49 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.7.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Building 4.7.0 and 4.8.0 screen from source, I noticed that I must press ESC
twice in vim within screen to exit insert mode. Running showkey -a I can see
that the ESC keypress is not delivered to the pty within screen until a
subsequent key is pressed, with no set timeout.

Reverting 40819ffe2b7ff2cbcb93d7b73d553179e57a27e1 alleviates the problem,
although there is still a delay controlable by maptimeout.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #57628] Can't access $HOSTNAME in screenrc file

[anonymous]

Follow-up Comment #5, bug #57628 (project screen):

[comment #4 comment #4:]
> $HOSTNAME (as I see in bash) seem to be provided by
> shell expansion logic and are not true environment
> variables set in environment.
> [...]
> You can see this by running 'env' command and observing
> that both of them are missing there. 

I'm pretty sure this isn't true and that "env" just doesn't have $HOSTNAME in
its environment because $HOSTNAME is not (or rather is no longer) exported by
default.

This is how I checked my assumption:
- "env | grep HOSTNAME" works after "export HOSTNAME" (so at least it
*behaves* like a normal environment variable)
- the man page doesn't say anything special about $HOSTNAME
- I can't find any special handling in the bash sources.

The patch is very short, but I thought I should point this out because it was
brought up as a rationale. I also wonder if the patch is the right thing to
do. Wouldn't it be surprising for users to special-case a normal environment
variable? An entry in the CHANGES file of bash shows that bash consciously
decided not to export it.


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #57571] screen --version exits with non-zero exit code

[anonymous]

URL:
  

 Summary: screen --version exits with non-zero exit code
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 09 Jan 2020 09:53:48 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.7.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:


This is inconsistent with other GNU programs and is annoying when e.g. probing
for existence of screen from make, scripts, etc.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #57551] man page says C-a \ to quit, but C-a C-\ is what actually does quit

[anonymous]

Follow-up Comment #1, bug #57551 (project screen):

There's a related oddity related to the unbinding in the etcscreenrc example
file that ships with 7.4.0.  That file contains this:

#remove some stupid / dangerous key bindings
bind ^k
#bind L
bind ^\
#make them better
bind \\ quit

However, C-a C-\ still does quit (with a prompt), and C-a \\ does nothing. 
Commenting out the bind ^\ seems make no difference.  
Perhaps I'm just not understanding how bind is supposed to work even after
reading about it.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56841] U+1f9e1 seems to cause screen display corruption

[anonymous]

Follow-up Comment #1, bug #56841 (project screen):

I've attached two images showing the difference between a normal terminal and
a terminal running gnu screen. The differences are quite clear.

(file #47437, file #47438)
___

Additional Item Attachment:

File name: terminal.png   Size:38 KB


File name: gnu-screen.png Size:37 KB




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56841] U+1f9e1 seems to cause screen display corruption

[anonymous]

URL:
  

 Summary: U+1f9e1 seems to cause screen display corruption
 Project: GNU Screen
Submitted by: None
Submitted on: Sat 31 Aug 2019 04:28:35 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.2
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

When I paste U+1f9e1 into gnu screen in a terminal session the cursor will
leap back onto the character rather than staying in front. If I just use a
regular non screen terminal session the error does not occur. It also
eventually seems to corrupt the display with TUI programs.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56674] Make it possible for screen to ignore terminal commands to change window titles

[anonymous]

URL:
  

 Summary: Make it possible for screen to ignore terminal
commands to change window titles
 Project: GNU Screen
Submitted by: None
Submitted on: Fri 26 Jul 2019 03:18:41 AM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

See https://unix.stackexchange.com/q/532203/135943 for a more complete problem
statement.

I believe this use case was simply overlooked, because the following
conditions all have to apply before you will feel the pain of this missing
feature (and then you will indeed feel the pain):

1. Working in a large infrastructure with many servers (i.e. thousands),
2. Where you want a consistent name for some window regardless of what server
you log into in that window,
3. And where it is impractical or impossible (organizationally) to modify the
rc files on all servers you might log into.

What I am requesting is a simple option in screen, ideally configurable either
per-window or globally for a screen session, to "set window title sticky" or
some such, so it would ignore escape sequences from the shell, and would only
change the window title if explicitly changed with the "title" command (C-a A
by default).




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56063] pass through of escape codes to the terminal

[anonymous]

Follow-up Comment #5, bug #56063 (project screen):

Thanks for the help!

Some information in case others are looking:

the ocs52.sh

script mentioned in the forum link: 

and the important excerpt:

# Send a DCS sequence through screen.
# Usage: 
screen_dcs() {
  # Screen limits the length of string sequences, so we have to break it up.
  # Going by the screen history:
  #   (v4.2.1) Apr 2014 - today: 768 bytes
  #   Aug 2008 - Apr 2014 (v4.2.0): 512 bytes
  #   ??? - Aug 2008 (v4.0.3): 256 bytes
  # Since v4.2.0 is only ~4 years old, we'll use the 256 limit.
  # We can probably switch to the 768 limit in 2022.
  local limit=256
  # We go 4 bytes under the limit because we're going to insert two bytes
  # before (\eP) and 2 bytes after (\e\) each string.
  echo "$1" | \
sed -E "s:.{$(( limit - 4 ))}:&\n:g" | \
sed -E -e 's:^:\x1bP:' -e 's:$:\x1b\\:' | \
tr -d '\n'
}


___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56063] pass through of escape codes to the terminal

[anonymous]

Follow-up Comment #4, bug #56063 (project screen):

Also see the thread on the hterm mailing list - screen only allows a certain
size to be escaped, so each chunk needs to be wrapped, instead of one large
one:
https://groups.google.com/a/chromium.org/forum/#!msg/chromium-hterm/J3_x2Bd5yXU/80qGVEdFEQAJ;context-place=forum/chromium-hterm

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56063] pass through of escape codes to the terminal

[anonymous]

Follow-up Comment #2, bug #56063 (project screen):

iTerm2_script 

related tmux bugs:
https://github.com/tmux/tmux/issues/846
https://github.com/tmux/tmux/issues/1388

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56063] pass through of escape codes to the terminal

[anonymous]

Follow-up Comment #1, bug #56063 (project screen):

arakiken

could be a start

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56063] pass through of escape codes to the terminal

[anonymous]

URL:
  

 Summary: pass through of escape codes to the terminal
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 02 Apr 2019 08:46:45 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

I would like to have the possibility to pass escape codes unhandled through
screen to the terminal.

for tmux the escape characters in the original escape codes have to be
doubled.
'\033Ptmux;' is prepended to the string and '\033\\' (ESC \) is appended.

This would allow me to let the terminal handle sixel graphics but I think
there are many more use cases for it.

regular sixel code:

printf
'\033Pq#0;2;0;0;0#1;2;100;100;0#2;2;0;100;0#1~~@@vv@@~~@@~~$#2??}}GG}}??}}??-#1!14@\033\\'


sixel code wrapped for tmux - tmux will pass it through to the terminal:

printf
'\033Ptmux;\033\033Pq#0;2;0;0;0#1;2;100;100;0#2;2;0;100;0#1~~@@vv@@~~@@~~$#2??}}GG}}??}}??-#1!14@\033\033\\\033\\'
printf
'\033Pq#0;2;0;0;0#1;2;100;100;0#2;2;0;100;0#1~~@@vv@@~~@@~~$#2??}}GG}}??}}??-#1!14@\033\\'
| sed 's/\o033/&&/g;s/^/\o033Ptmux;/;s/$/\o033\\/'






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #56027] Typo in man page

[anonymous]

URL:
  

 Summary: Typo in man page
 Project: GNU Screen
Submitted by: None
Submitted on: Fri 29 Mar 2019 09:29:51 AM UTC
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: Cur Dev Sources
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

trailiing - should be trailing






___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #55709] Bracketed-paste mode causes Terminal.app to flash

[anonymous]

Follow-up Comment #1, bug #55709 (project screen):

Managed to test it on xterm, too. The final BEL character is not necessary
there, either. 

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #55709] Bracketed-paste mode causes Terminal.app to flash

[anonymous]

URL:
  

 Summary: Bracketed-paste mode causes Terminal.app to flash
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 14 Feb 2019 07:10:57 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: Cur Dev Sources
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

As far as i can tell, screen sends the sequence

  ESC [ ? 2 0 0 4 h BEL

to enable bracketed-paste mode. That last BEL character causes macOS'
Terminal.app to beep. Why is it sent? Terminal.app does not need it and
neither does xfce4-terminal.

I can't test a real xterm right now, because I can't figure out how to paste
in it with a Mac mouse. =)





___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #52485] lock on /etc/utmp on AiX > 6100-09-07-1614

[anonymous]

Follow-up Comment #2, bug #52485 (project screen):

I can confirm the something is up with screen and AIX. I expereinced it this
morning after starting screen and then putting my laptop to sleep only to find
10mins later then no on could login to the AIX Server

Details:
MAINTENANCE LEVEL:  7100-04
SERVICEPACK LEVEL:  7100-04-04-1717

Screen version from AIX_Toolbox
screen  ppc  3.9.10-2 
   @AIX_Toolbox  

As root a screen is started then forcibly disconnect from it. At that point
AIX can not spawn a new terminal. You can get as far ssh prompting you for
password but you can not get a shell. (Thankfully I recovered access with ftp
and rsh). 

Once the screen process was killed login was possible again. I see nothing in
alog or /var/log/system that would give any hint of an error.

-Mike

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #55505] Loading new session with virtualenv activated

[anonymous]

URL:
  

 Summary: Loading new session with virtualenv activated
 Project: GNU Screen
Submitted by: None
Submitted on: Fri 18 Jan 2019 09:23:55 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Hi,
I've been using screen with virtualenvs for the first time today and I noticed
something. It's not a bug, but I don't know if it's wanted or not so I'd
rather submit an issue.

When a virtualenv has been activated and one starts a new screen session,
virtualenv keeps activated. Here is an example :

```
toto@machine : which python3
/usr/bin/python3
toto@machine : source venv/bin/activate
(venv)toto@machine : which python3
$HOME/venv/bin/python3
(venv)toto@machine : screen -S
toto@machine: which python3
$HOME/venv/bin/python3
```

Again, it's not really a bug but better knowing it.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #55274] Release new version

[anonymous]

URL:
  

 Summary: Release new version
 Project: GNU Screen
Submitted by: None
Submitted on: Mon 24 Dec 2018 01:28:53 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Many commits have landed in master since the most recent release (v4.6.2),
this should of course mean that many issues have been fixed:
https://git.savannah.gnu.org/cgit/screen.git/log/?qt=range=v.4.6.2..master

Please, release a new version.  :-)




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #55251] Defining a screen number and enabling captions makes man pages lines duplicate when using the search function

[anonymous]

URL:
  

 Summary: Defining a screen number and enabling captions makes
man pages lines duplicate when using the search function
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 20 Dec 2018 05:31:30 AM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

I'm using Arch Linux and GNU Screen version 4.6.2. When I set both the options
"screen 1" (or any number) and "caption always" (or "hardstatus
alwayslastline") in my .screenrc, and then I try to use the search function in
any man page, every line on the screen appears duplicated. It happens only in
the screen number defined in "screen 1" (or whatever number). It's
reproducible in any Screen version that I could find, using any terminal
emulator or even the console, and it happens at least in Arch and Gentoo.

A demonstration of this problem can be seen in this video:
https://youtu.be/jNIiJfAvdvA




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #54776] comm.h needed for list_{display, generic}.o

[anonymous]

URL:
  

 Summary: comm.h needed for list_{display,generic}.o
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 03 Oct 2018 08:38:13 PM UTC
Category: Build/Install
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.2
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

comm.h is needed to build list_display.o and list_generic.o otherwise parallel
builds will sometimes fail

Fixes:
 -
http://autobuild.buildroot.org/results/43105f14857dbe72d8878fc7b3db67f7bdca93cc
 -
http://autobuild.buildroot.org/results/47f4ecbec1355285633df287fc9c4e7cccde9378

So please find attached a patch




___

File Attachments:


---
Date: Wed 03 Oct 2018 08:38:13 PM UTC  Name:
0001-comm.h-needed-for-list_-display-generic-.o.patch  Size: 2KiB   By: None



___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #50748] problems with "profiling timer expired" errors

[anonymous]

Follow-up Comment #3, bug #50748 (project screen):

I'm experiencing a similar problem, except with tmux (1.8) run on a remote
server (Oracle GNU/Linux Server release 7.5) to which I am connecting via
Cygwin ssh.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #54556] screen is producing invalid TERMCAPs

[anonymous]

URL:
  

 Summary: screen is producing invalid TERMCAPs
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 22 Aug 2018 09:32:07 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

I'm running screen 4.06.02 and ncurses 6.1 on MacOS X.

Screen is creating a TERMCAP variable for my TERM that ncurses can not parse.
When I start screen an error message is printed to stderr from ncurses:
"TERMCAP", line 20, col 1, terminal 'SC': Missing separator

This error message happens when my TERM outside of screen is xterm-256color.
Within the screen, my TERM is screen.xterm-256color and screen creates this
TERMCAP for it:

SC|screen.xterm-256color|VT 100/ANSI X3.64 virtual terminal:\
:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
:li#53:co#234:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
:se=\E[23m:mb=\E[5m:md=\E[1m:mh=\E[2m:mr=\E[7m:\ :me=\E[m:ms:\
:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
:vb=\Eg:G0:as=\E(0:ae=\E(B:\
:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
:po=\E[5i:pf=\E[4i:Km=\E[M:k0=\E[10~:k1=\EOP:k2=\EOQ:\
:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:\
:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\
:F3=\E[1;2P:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:\
:F7=\E[15;2~:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:\
:FB=\E[20;2~:FC=\E[21;2~:FD=\E[23;2~:FE=\E[24;2~:kb=^H:\
:K2=\EOE:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:\
:*7=\E[1;2F:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:\
:%e=\E[5;2~:%i=\E[1;2C:kh=\E[1~:@1=\E[1~:kH=\E[4~:\
:@7=\E[4~:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:\
:kd=\EOB:kr=\EOC:kl=\EOD:km:

Note that if I set TERM=xterm outside of screen I do not get the error message
from ncurses. If TERM outside of screen is ncurses the TERM inside of screen
is screen and TERMCAP is:
SC|screen|VT 100/ANSI X3.64 virtual terminal:\
:DO=\E[%dB:LE=\E[%dD:RI=\E[%dC:UP=\E[%dA:bs:bt=\E[Z:\
:cd=\E[J:ce=\E[K:cl=\E[H\E[J:cm=\E[%i%d;%dH:ct=\E[3g:\
:do=^J:nd=\E[C:pt:rc=\E8:rs=\Ec:sc=\E7:st=\EH:up=\EM:\
:le=^H:bl=^G:cr=^M:it#8:ho=\E[H:nw=\EE:ta=^I:is=\E)0:\
:li#53:co#234:am:xn:xv:LP:sr=\EM:al=\E[L:AL=\E[%dL:\
:cs=\E[%i%d;%dr:dl=\E[M:DL=\E[%dM:dc=\E[P:DC=\E[%dP:\
:im=\E[4h:ei=\E[4l:mi:IC=\E[%d@:ks=\E[?1h\E=:\
:ke=\E[?1l\E>:vi=\E[?25l:ve=\E[34h\E[?25h:vs=\E[34l:\
:ti=\E[?1049h:te=\E[?1049l:us=\E[4m:ue=\E[24m:so=\E[3m:\
:se=\E[23m:mb=\E[5m:md=\E[1m:mh=\E[2m:mr=\E[7m:\ :me=\E[m:ms:\
:Co#8:pa#64:AF=\E[3%dm:AB=\E[4%dm:op=\E[39;49m:AX:\
:vb=\Eg:G0:as=\E(0:ae=\E(B:\
:ac=\140\140aaffggjjkkllmmnnooppqqrrssttuuvvwwxxyyzz{{||}}~~..--++,,hhII00:\
:po=\E[5i:pf=\E[4i:Km=\E[M:k0=\E[10~:k1=\EOP:k2=\EOQ:\
:k3=\EOR:k4=\EOS:k5=\E[15~:k6=\E[17~:k7=\E[18~:\
:k8=\E[19~:k9=\E[20~:k;=\E[21~:F1=\E[23~:F2=\E[24~:\
:F3=\E[1;2P:F4=\E[1;2Q:F5=\E[1;2R:F6=\E[1;2S:\
:F7=\E[15;2~:F8=\E[17;2~:F9=\E[18;2~:FA=\E[19;2~:\
:FB=\E[20;2~:FC=\E[21;2~:FD=\E[23;2~:FE=\E[24;2~:kb=^H:\
:K2=\EOE:kB=\E[Z:kF=\E[1;2B:kR=\E[1;2A:*4=\E[3;2~:\
:*7=\E[1;2F:#2=\E[1;2H:#3=\E[2;2~:#4=\E[1;2D:%c=\E[6;2~:\
:%e=\E[5;2~:%i=\E[1;2C:kh=\E[1~:@1=\E[1~:kH=\E[4~:\
:@7=\E[4~:kN=\E[6~:kP=\E[5~:kI=\E[2~:kD=\E[3~:ku=\EOA:\
:kd=\EOB:kr=\EOC:kl=\EOD:km:




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #52667] Off-by-one in RGB truecolor escape sequence parameter indices

[anonymous]

Follow-up Comment #5, bug #52667 (project screen):

I was wondering if there was already a follow up on this issue?

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #54164] race between starting backend and issuing command to session

[anonymous]

Follow-up Comment #1, bug #54164 (project screen):

in my experience, seems it is easier to trigger when the system is under heavy
cpu load. and as a bad workaround, i just put a "sleep 1" in between the 2
calls.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #54151] env var TMPDIR gets unset upon 'screen' command

[anonymous]

Follow-up Comment #2, bug #54151 (project screen):

Indeed, my new distro installs Screen setuid. Once I removed the setuid bit
and restarted Screen, TMPDIR was again inherited by new shells.

Thank you for the explanation and sorry for the noise.

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #54151] env var TMPDIR gets unset upon 'screen' command

[anonymous]

URL:
  

 Summary: env var TMPDIR gets unset upon 'screen' command
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 19 Jun 2018 09:19:55 AM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.2
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

When creating a new window by means of a 'screen' command, the new shell
doesn't inherit the TMPDIR environment variable.

This despite TMPDIR being set in Screen's environment, as verified in
/proc//environ . This happens even if Screen is started only with
the stock config file ( -c /etc/screenrc ).

I'm on Linux 4.16.14/x86_64.




___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #52667] Off-by-one in RGB truecolor escape sequence parameter indices

[anonymous]

Follow-up Comment #3, bug #52667 (project screen):

I compile screen from source to get truecolor support. When I upgraded ubuntu
recently, truecolor support broke. Specifically, I am seeing the wrong colors
being output, but not a downgrade to 256 colors or similar. Is this bug what I
should be following to see when this will be fixed or is this a separate
issue?

To see what I mean by wrong colors, see
https://stackoverflow.com/questions/50826467/screen-truecolor-ubuntu-18-04-broke

___

Reply to this item at:

  

___
  Message sent via Savannah
  https://savannah.gnu.org/

[screen-devel] [bug #53552] Wording in the man page is not the most appropriate

[anonymous]

URL:
  

 Summary: Wording in the man page is not the most appropriate
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 03 Apr 2018 07:04:13 AM UTC
Category: Documentation
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.0.3
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

In the man page for GNU screen, you can find the following:

"-O   selects a more optimal output mode for your terminal  rather  than
 true  VT100  emulation (only affects auto-margin terminals without
 `LP').  This can also be set in your .screenrc by specifying  `OP'
 in a "termcap" command."

My concern is that if something is "optimal", it cannot be
improved, so there is nothing "more optimal" than other, it would be better to
use the
construction "selects an optimal output mode for your terminal".

Thank you!




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #53173] Out of bounds heap memory read in MClearArea()

[anonymous]

URL:
  

 Summary: Out of bounds heap memory read in MClearArea()
 Project: GNU Screen
Submitted by: None
Submitted on: Fri 16 Feb 2018 09:58:10 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.2
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

I detected an out of bounds heap read in screen when building with address
sanitizer. Happens both in 4.6.2 and current git, though the code changed a
bit, so the line numbers differ. I'll attach stack traces for both.

This can be reliably reproduced for me by:
1. compile screen with -fsanitize=address in CFLAGS+LDFLAGS.
2. run screen in a terminal emulator.
3. Press ctrl-a.
4. Resize the window.

Screen will hang and the main process will have crashed with an oob read in
MClearArea.

Stack trace:
==19786==ERROR: AddressSanitizer: heap-buffer-overflow on address
0x61501154 at pc 0x561d8c848842 bp 0x7ffdea718400 sp 0x7ffdea7183f0
READ of size 4 at 0x61501154 thread T0
#0 0x561d8c848841 in MClearArea /mnt/ram/screen/src/ansi.c:2117
#1 0x561d8c8411ab in ClearLineRegion /mnt/ram/screen/src/ansi.c:1636
#2 0x561d8c8390a8 in DoCSI /mnt/ram/screen/src/ansi.c:887
#3 0x561d8c834085 in WriteString /mnt/ram/screen/src/ansi.c:426
#4 0x561d8c937335 in win_readev_fn /mnt/ram/screen/src/window.c:1443
#5 0x561d8c90ae42 in sched /mnt/ram/screen/src/sched.c:164
#6 0x561d8c8250f9 in main /mnt/ram/screen/src/screen.c:1075
#7 0x7f33026c8f85 in __libc_start_main (/lib64/libc.so.6+0x20f85)
#8 0x561d8c8204a9 in _start (/mnt/ram/screen/src/screen+0x294a9)

0x61501154 is located 0 bytes to the right of 468-byte region
[0x61500f80,0x61501154)
allocated by thread T0 here:
#0 0x7f33033ff220 in realloc
(/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.0/libasan.so.4+0xe1220)
#1 0x561d8c90640d in xrealloc /mnt/ram/screen/src/resize.c:455
#2 0x561d8c90503f in CheckMaxSize /mnt/ram/screen/src/resize.c:394
#3 0x561d8c901cb1 in ChangeScreenSize /mnt/ram/screen/src/resize.c:128
#4 0x561d8c901518 in CheckScreenSize /mnt/ram/screen/src/resize.c:100
#5 0x561d8c9150f0 in ReceiveMsg /mnt/ram/screen/src/socket.c:813
#6 0x561d8c828ee7 in serv_read_fn /mnt/ram/screen/src/screen.c:1627
#7 0x561d8c90ae42 in sched /mnt/ram/screen/src/sched.c:164
#8 0x561d8c8250f9 in main /mnt/ram/screen/src/screen.c:1075
#9 0x7f33026c8f85 in __libc_start_main (/lib64/libc.so.6+0x20f85)




___

File Attachments:


---
Date: Fri 16 Feb 2018 09:58:10 PM UTC  Name: screen-asan-oob-4.6.2.txt  Size:
3KiB   By: None
full asan errors

---
Date: Fri 16 Feb 2018 09:58:10 PM UTC  Name: screen-asan-oob-git.txt  Size:
3KiB   By: None
full asan errors


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #52733] Support for $SYSSCREENRC went missing

[anonymous]

URL:
  

 Summary: Support for $SYSSCREENRC went missing
 Project: GNU Screen
Submitted by: None
Submitted on: Sat 23 Dec 2017 10:45:18 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

While 4.6.2 has fully working support for the environment
variable $SYSSCREENRC, current git (as of 2017-12-23) seems
to have lost this support. A few occurrences of the variable
name in the documentation is all that's left.

Please restore that functionality, it is very helpful when
handling multiple versions of screen (e.g. for testing new
versions).

Using "git bisect" (bear with me, I don't know git), I think I
found the commit where support got dropped (at least the #define
ALLOW_SYSSCREENRC in acconfig.h vanished):

  [df1c012227c95dd7aafe8706f4537445ba8f5d48] rewrite configure.ac from
scratch

Having an option instead of an environment variable would be fine, too,
of course.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #52663] configure option "--disable-use-locale" is not working

[anonymous]

URL:
  

 Summary: configure option "--disable-use-locale" is not
working
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 14 Dec 2017 06:13:35 AM UTC
Category: Build/Install
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.2
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

"USE_LOCALE" is always defined.

Question: "--enable-use-locale" is [default=yes]?

In `acconfig.h`, defined "USE_LOCALE".

Attached patch file for [default=yes].



___

File Attachments:


---
Date: Thu 14 Dec 2017 06:13:35 AM UTC  Name: use-locale-can-disable.patch 
Size: 919B   By: None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #52360] Bindkey -m also affects command line (c-a :)

[anonymous]

URL:
  

 Summary: Bindkey -m also affects command line (c-a :)
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 07 Nov 2017 04:10:26 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: Cur Dev Sources
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Git clone of today 7th Nov 2017.

I set some keys up for copy mode using:

bindkey -m 'o' '...'

I find that this also affects the command mode too. When I try to enter a
command containing an 'o', instead of an 'o' I get a blank character,
therefore commands like 'source' will not work.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[anonymous]

URL:
  

 Summary: Screen doesn't release pty TIOCEXCL on quit
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 18 Oct 2017 11:19:11 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: None
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

In pty.c, ioctl TIOCEXCL takes exclusive control of the pty. Screen should
call ioctl TIOCNXCL to release that control on close. This manifests as ptys
getting mysteriously broken after using them with screen.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #52133] Use after free of D_xtable in FreeDisplay

[anonymous]

URL:
  

 Summary: Use after free of D_xtable in FreeDisplay
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 28 Sep 2017 01:57:21 AM UTC
Category: Crash/Freeze/Infloop
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.1
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

FreeDisplay() first calls FreeTransTable which frees D_xtable but does not
modify the value of D_xtable. Then SetTTY is called which calls Msg when an
error occurs. This can cause a segfault when RAW_PUTCHAR tries to access the
memory pointed to by D_xtable.

0  0x55583e7032a4 in RAW_PUTCHAR (c=110) at display.c:656
1  0x55583e6cbe4c in PutWinMsg (s=0x55583e932801  "clark-dt
-*  ",
   s@entry=0x55583e932800  "nclark-dt -*  ", start=, start@entry=0, max=40, max@entry=49) at screen.c:3053
2  0x55583e7003f6 in PrePutWinMsg (s=0x55583e932800 
"nclark-dt -*  ", start=0, max=49) at display.c:2174
3  0x55583e705339 in RefreshLine (y=65, from=, to=48,
isblank=0) at display.c:2399
4  0x55583e70630c in MakeStatus (msg=0x7ffeaa03d7d0 "SetTTY (fd 3): ioctl
failed: Input/output error") at display.c:2056
5  0x55583e6c8a68 in Msg (err=, fmt=) at
screen.c:2091
6  0x55583e6c83a1 in CoreDump (sigsig=) at screen.c:1664
7  
8  0x55583e7032a4 in RAW_PUTCHAR (c=110) at display.c:656
9  0x55583e6cbe4c in PutWinMsg (s=0x55583e932801  "clark-dt
-*  ",
   s@entry=0x55583e932800  "nclark-dt -*  ", start=, start@entry=0, max=40) at screen.c:3053
10 0x55583e700443 in PrePutWinMsg (s=0x55583e932800 
"nclark-dt -*  ", start=0, max=) at display.c:2165
11 0x55583e705339 in RefreshLine (y=65, from=, to=48,
isblank=0) at display.c:2399
12 0x55583e70630c in MakeStatus (msg=0x7ffeaa040780 "SetTTY (fd 3): ioctl
failed: Input/output error") at display.c:2056
13 0x55583e6c8a68 in Msg (err=, fmt=,
fmt@entry=0x55583e719f41 "SetTTY (fd %d): ioctl failed") at screen.c:2091
14 0x55583e6dfadc in SetTTY (fd=, mp=) at
tty.c:624
15 0x55583e707d08 in FreeDisplay () at display.c:340
16 0x55583e6c8612 in Detach (mode=mode@entry=2) at screen.c:2000
17 0x55583e6dbb52 in FinishDetach (m=0x55583e933b80 ) at socket.c:1607
18 0x55583e6ddcd5 in FinishAttach (m=m@entry=0x55583e933b80 ) at
socket.c:1424
19 0x55583e6de531 in ReceiveMsg () at socket.c:1235
20 0x55583e711583 in sched () at sched.c:237
21 0x55583e6c7113 in main (ac=0, av=) at screen.c:1466



___

File Attachments:


---
Date: Thu 28 Sep 2017 01:57:21 AM UTC  Name:
0001-termcap.c-in-FreeTransTable-set-D_xtable-to-NULL.patch  Size: 3KiB   By:
None
Patch to set D_xtable to NULL after free


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51832] Cursor is left in the wrong position after leaving altscreen

[anonymous]

URL:
  

 Summary: Cursor is left in the wrong position after leaving
altscreen
 Project: GNU Screen
Submitted by: None
Submitted on: Wed 23 Aug 2017 10:24:26 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Hi,

Since upgrading to screen 4.6.0 I have been having issues with cursor
placement after leaving altscreen. I looked through the history and found
commit 8062db33b87ed86ec54222c83babbf1aa5866ec9, which refers bug #49883
. Reverting that commit fixes the
problem.

Steps to reproduce:
1. Start screen with altscreen on
2. Press enter at your shell prompt until you reach the bottom of the screen
3. Run 'echo foo | less'
4. Press 'q' to exit

Expected behaviour:
The cursor should be at the bottom of the screen, just like it was before I
started less.

Actual behaviour:
The cursor is in the middle of my history, somewhere near the top of the
screen.

I'm running Arch Linux, up to date as of today. less 487, screen 4.6.1,
ncurses 6.0+20170527, glibc 2.25, Linux 3.16.46.

Happy to test any patches, thanks!




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51562] Reconnet by session name connects wrong session

[anonymous]

Follow-up Comment #2, bug #51562 (project screen):

This is strange. I double checked it on different machines with different
users. On all Debian Jessie machines I got connected to the wrong session
without any error or warning.

On Stretch machines with Screen "4.05.00 (GNU) 10-Dec-16" I'm getting
connected to the right screen session. So this seems to be fixed in some
version in between. That's fine for me because it rarely happens that my
session names collides.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51562] Reconnet by session name connects wrong session

[anonymous]

URL:
  

 Summary: Reconnet by session name connects wrong session
 Project: GNU Screen
Submitted by: None
Submitted on: Mon 24 Jul 2017 04:09:50 PM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.2.1
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

1. screen -S sessionname

2. screen -ls 
4508.sessionname(07/24/17 15:56:28) (Attached)

3. ctrl a d

4. screen -ls 
4508.sessionname(07/24/17 15:56:28) (Detached)

5. screen -S sessionname2

6. screen -ls
6241.sessionname2   (07/24/17 16:03:13) (Attached)
4508.sessionname(07/24/17 15:56:27) (Detached)

7. ctrl a d

8. screen -ls
6241.sessionname2   (07/24/17 16:03:14) (Detached)
4508.sessionname(07/24/17 15:56:28) (Detached)

9. screen -r sessionname

10. screen -ls
6241.sessionname2   (07/24/17 16:03:14) (Attached)
4508.sessionname(07/24/17 15:56:28) (Detached)

I tried out different session names like "test" and "testtwo" with the same
result.




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51500] windowlist -m crashes with simultaneously created windows

[anonymous]

Follow-up Comment #2, bug #51500 (project screen):

I tried it with the screen distributed with CentOS 7 (4.001.00) and with 4.6
hand compiled in CentOS 6.

I could not reproduce it in Ubuntu 14.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51500] windowlist -m crashes with simultaneously created windows

[anonymous]

Additional Item Attachment, bug #51500 (project screen):

File name: screen-crash.txt   Size:1 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51500] windowlist -m crashes with simultaneously created windows

[anonymous]

URL:
  

 Summary: windowlist -m  crashes with simultaneously created
windows
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 18 Jul 2017 08:25:30 PM UTC
Category: Crash/Freeze/Infloop
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.6.1
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Repeat with:

$ for i in one two three ; do
> screen -t $i
> done
^a:windowlist -m

Results:
Screen crashes / hangs

Work-around:
cycle through all newly created windows before trying to get a time sorted
windowlist


Similarly, windowlist -g  seems to crash if there are no window groups.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51402] SEGFAULT when querying 'info' on detached screen

[anonymous]

Follow-up Comment #5, bug #51402 (project screen):

>From your output I see that you are using UTF-8 so you don't run into the code
path in question:

#  ifdef UTF8
  if (wp->w_encoding != UTF8) // <- only for !utf8
#  endif
# endif
if (D_CC0 || (D_CS0 && *D_CS0)) // <-- null ptr derefence

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51402] SEGFAULT when querying 'info' on detached screen

[anonymous]

Follow-up Comment #4, bug #51402 (project screen):

Futher remark: Maybe the "display" variable in question depends on termcap
related configuration which might be different on our systems.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51402] SEGFAULT when querying 'info' on detached screen

[anonymous]

Follow-up Comment #1, bug #51402 (project screen):

Hidden behind three layers of macro defines, the actual null pointer is
"display". Several other places in code check for that but here it was sadly
missing, therefore:

Fix:
diff --git a/process.c b/process.c
index 2b007bc..2da24b8 100644
--- a/process.c
+++ b/process.c
@@ -5772,7 +5772,7 @@ ShowInfo()
   if (wp->w_encoding != UTF8)
 #  endif
 # endif
-if (D_CC0 || (D_CS0 && *D_CS0))
+if (display && (D_CC0 || (D_CS0 && *D_CS0)))
   {
if (wp->w_gr == 2)
  {

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51100] screen reports the wrong version

[anonymous]

URL:
  

 Summary: screen reports the wrong version
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 23 May 2017 06:30:55 PM UTC
Category: Code Architecture
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.5.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Using:
http://git.savannah.gnu.org/cgit/screen.git/snapshot/screen-v.4.5.1.tar.gz

This version reports as 4.05.01





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #51099] screenrc commands fail to execute

[anonymous]

URL:
  

 Summary: screenrc commands fail to execute
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 23 May 2017 06:28:15 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.5.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Using a "screenrc" file (via -c option or the default) does not execute
commands as expected.

example:
acladd user
aclchg user -w "#?"

This will add the user but the second command does nothing.

"writelock on" is also ignored.

If these commands are entered manually, screen behaves as expected.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #50748] problems with "profiling timer expired" errors

[anonymous]

URL:
  

 Summary: problems with "profiling timer expired" errors
 Project: GNU Screen
Submitted by: None
Submitted on: Fri 07 Apr 2017 12:06:23 PM UTC
Category: None
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.0.3
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

We are experiencing a problem in LSF that might be caused by a screen
issue/feature/bug. When resizing a Putty window or when operating on the same
screen session with multiple connections interactive LSF jobs will fail with a
“Profiling timer expired” error. Do you have any reports on such problems?
I’ll try (as soon as I have time) to reproduce the issue with screen debug
settings as described in
https://www.gnu.org/software/screen/manual/screen.html#Reporting-Bugs, but it
would be good to know if you have any other reports on such a problem. The
screen versions used are:

screen-4.1.0-0.23.20120314git3c2946.el7_2.x86_64
screen-4.0.3-18.el6.x86_64

on RH/Centos/OL Linux environments 6 and 7.


Also: the e-mail addresses (scr...@uni-erlangen.de) in the man file are not
working.  




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #50089] Screen 4.5.0 doesn't build on SunOS

[anonymous]

Additional Item Attachment, bug #50089 (project screen):

File name: screen_4.5.0_coredump.txt  Size:2 KB


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #50197] out of bounds write when dimensions are still 0, 0

[anonymous]

URL:
  

 Summary: out of bounds write when dimensions are still 0, 0
 Project: GNU Screen
Submitted by: None
Submitted on: Tue 31 Jan 2017 01:59:11 PM UTC
Category: Crash/Freeze/Infloop
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.4.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

Program received signal SIGSEGV, Segmentation fault.
0x080510da in MFixLine (p=p@entry=0x80cb2d8, y=y@entry=-1,
mc=mc@entry=0x80cd830) at ansi.c:2371
2371ansi.c: No such file or directory.
(gdb) bt
#0  0x080510da in MFixLine (p=p@entry=0x80cb2d8, y=y@entry=-1,
mc=mc@entry=0x80cd830) at ansi.c:2371
#1  0x08051a7a in MPutChar (p=0x80cb2d8, c=0x80cd830, x=-1, y=-1) at
ansi.c:2723
#2  0x08057e61 in WriteString (wp=0x0, buf=0xffb8c453 "\033[1;27H\r\n",
len=175) at ansi.c:869
#3  0x08067868 in win_readev_fn (ev=0x80cb2e4, data=0x80cb2d8 "") at
window.c:1942
#4  0x08090630 in sched () at sched.c:237
#5  0x0804c463 in main (ac=, av=) at
screen.c:1487
(gdb) frame 0
#0  0x080510da in MFixLine (p=p@entry=0x80cb2d8, y=y@entry=-1,
mc=mc@entry=0x80cd830) at ansi.c:2371
2371  if (mc->attr && ml->attr == null)
(gdb) up
#1  0x08051a7a in MPutChar (p=0x80cb2d8, c=0x80cd830, x=-1, y=-1) at
ansi.c:2723
2723  MFixLine(p, y, c);
(gdb) up
#2  0x08057e61 in WriteString (wp=0x0, buf=0xffb8c453 "\033[1;27H\r\n",
len=175) at ansi.c:869
869   MPutChar(curr, >w_rend, curr->w_x,
curr->w_y);
(gdb) l 
864   curr->w_x++;
865 }
866 }
867   else if (curr->w_x == cols - 1)
868 {
869   MPutChar(curr, >w_rend, curr->w_x,
curr->w_y);
870   LPutChar(>w_layer, >w_rend, curr->w_x,
curr->w_y);
871   if (curr->w_wrap)
872 curr->w_x++;
873 }
(gdb) p cols
$3 = 0
(gdb) p rows
$4 = 0

As one can see rows/cols are both 0 valued but are used for range index
computations. It seems when a screen is started in detached mode those
variables are never set to reasonable values (like 25, 80).
Above source code is actually from 4.2.1 as it was easier in Debian to
retrieve the source from that version, yet the error also occurs in 4.4.0.

Reproduce:
Terminal 1:
$ xxd bad_sequence 
: 1b5b 721b 5b6d 1b5b 324a 1b5b 481b 5b3f  .[r.[m.[2J.[H.[?
0010: 3768 1b5b 3f31 3b33 3b34 3b36 6c1b 5b3b  7h.[?1;3;4;6l.[;
0020: 481b 5b32 4a00       H.[2J...
0030:          
0040:          
0050:    001b 5b3b 481b 5b32 4a00  [;H.[2J.
0060:          
0070:          
0080:          
0090: 001b 5b3b 376d 1b28 301b 5b31 3b31 3048  ..[;7m.(0.[1;10H
00a0:   0078 1b5b 313b 3237 480a   .x.[1;27H.
$ screen -d -m bash -c 'sleep 10; cat bad_sequence; sleep 999'
Terminal 2 ("continue" in gdb and wait for the crash in less than 10 seconds)
$ gdb -p $(pgrep  screen)



___

File Attachments:


---
Date: Tue 31 Jan 2017 01:59:11 PM UTC  Name: bad_sequence  Size: 174B   By:
None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

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

[anonymous]

URL:
  

 Summary: Update lookup tables to support Unicode 9.0.0
 Project: GNU Screen
Submitted by: None
Submitted on: Thu 12 Jan 2017 10:53:36 PM UTC
Category: Feature Request
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.99.0
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

I use weechat inside a screen session inside mate-terminal for IRC and lately
emoji have begun showing up and my terminal gets corrupted.  I was able to
track this down to screen's wide character handling.  Because screen doesn't
correctly detect that new emoji (such as 



___

File Attachments:


---
Date: Thu 12 Jan 2017 10:53:36 PM UTC  Name:
screen-update-unicode-wide-tables.patch  Size: 3kB   By: None



___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #13249] pasting in nano crashes screen

[anonymous]

Follow-up Comment #4, bug #13249 (project screen):

Can confirm, this happens in a session with nano open pasting a large
selection. Freezes screen and session is not recoverable.

___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #48789] After lockscreen, the session is said to be detached bit it isnt

[anonymous]

URL:
  

 Summary: After lockscreen, the session is said to be detached
bit it isnt
 Project: GNU Screen
Submitted by: None
Submitted on: Mon 15 Aug 2016 04:58:35 PM UTC
Category: Program Logic
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.0.3
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

The documentation states that lockscreen puts the session in  a detached state
- screen -list even says as much. However when one does a reattach with prior
detach (screen -D -RR for example) one can connect with that session while it
stays in its locked state in its original tty. if one then unlocks the session
inside the original tty this actually works. If one takes the documentation
literally - it shouldnt. Compare for example tmux - after unlocking the
original session - it simply detaches. 




___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #48720] Cannot unlock screen running as a user without password

[anonymous]

URL:
  

 Summary: Cannot unlock screen running as a user without
password
 Project: GNU Screen
Submitted by: None
Submitted on: Mon 08 Aug 2016 02:35:05 AM UTC
Category: User Interface
Severity: 3 - Normal
Priority: 5 - Normal
  Status: None
 Privacy: Public
 Assigned to: None
 Open/Closed: Open
 Discussion Lock: Any
 Release: 4.0.3
   Fixed Release: None
 Planned Release: None
   Work Required: None

___

Details:

If a user with no password locks a screen session by pressing Ctrl + A and X,
there's no proper way to unlock the session.

Steps to reproduce.
1. Make a user for test.
2. Remove the password from the new user with command: passwd -d [user]
3. Change(login) to the user.
4. run: screen
5. Press Control + A and then X to lock the session.

What happens:
The session locks, seems okay. However, typing Enter doesn't unlock the
session despite the fact that there's no password for the user.

What should happen:
Pressing Enter key should just unlock the session. Or the session should not
lock at all.





___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/

[screen-devel] [bug #48691] segfault if a digraph is bound to some key combination

[anonymous]

Follow-up Comment #1, bug #48691 (project screen):

Actually not a digraph but a digraph præfix.

I regularily use it like this:

^Au20AC (inserts an Euro sign), for example


___

Reply to this item at:

  

___
  Message sent via/by Savannah
  http://savannah.gnu.org/