> On Thu, 12 Mar 2020 19:01:41 -0700
> Wayne Davison wrote:
> > In recent Cygwin versions I've had gnu screen crash if the parent ssh
> > connection closes before an explicit disconnect is performed.
Thanks for reporting. I don't have any Cygwin hosts set up as ssh
On Thu, 12 Mar 2020 19:01:41 -0700
Wayne Davison wrote:
> In recent Cygwin versions I've had gnu screen crash if the parent ssh
> connection closes before an explicit disconnect is performed. If an
> orderly screen disconnect happens first, future closed connections
> (after re
In recent Cygwin versions I've had gnu screen crash if the parent ssh
connection closes before an explicit disconnect is performed. If an
orderly screen disconnect happens first, future closed connections
(after reconnecting to the screen session) no longer crash screen.
To reproduce:
I ssh
Hi Corinna,
On Sat, 16 Mar 2019 16:34:41 +0100 Corinna Vinschen wrote:
> Pushed and new release uploaded.
I confirmed that the issue has been fixed in login 1.13-1.
Thank you very much!
--
Takashi Yano
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cyg
0 Takashi Yano wrote:
> > > Hello,
> > >
> > > I would like to propose a patch attached for login package.
> > >
> > > This fixes the issue that GNU screen and tmux cannot read tty input
> > > if they are started in a telnet session.
> >
ropose a patch attached for login package.
> >
> > This fixes the issue that GNU screen and tmux cannot read tty input
> > if they are started in a telnet session.
> >
> > This issue is due to the ownership of tty. With login 1.12-1, tty
> > is owned by cyg_se
I try to clarify the title a little.
On Sat, 9 Mar 2019 10:35:13 +0900 Takashi Yano wrote:
> Hello,
>
> I would like to propose a patch attached for login package.
>
> This fixes the issue that GNU screen and tmux cannot read tty input
> if they are started in a telnet sessio
Hello,
I would like to propose a patch attached for login package.
This fixes the issue that GNU screen and tmux cannot read tty input
if they are started in a telnet session.
This issue is due to the ownership of tty. With login 1.12-1, tty
is owned by cyg_server after logging in via telnet
Greetings, Andrey Repin!
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
> # screen -S mc-server-session -Q windows
>
> If I SEGV the hung child, there's a stacktrace,
Greetings, Andrey Repin!
> Greetings, All!
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
> # screen -S mc-server-session -Q windows
>
Still same problem after today
Greetings, All!
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
> # screen -S mc-server-session -Q windows
>
> If I SEGV the hung child, there's a stacktrace, though I
> On Sat, May 27, 2017 at 4:27 AM, Andrey Repin wrote:
> > # uname -a; screen --version; screen -admS mc-server-session
> > CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> > Screen version 4.05.01 (GNU) 25-Feb-17
> >
> > # screen -S mc-server-session -Q windows
> >
>
> I
On Sat, May 27, 2017 at 4:27 AM, Andrey Repin wrote:
> # uname -a; screen --version; screen -admS mc-server-session
> CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
> Screen version 4.05.01 (GNU) 25-Feb-17
>
> # screen -S mc-server-session -Q windows
>
I see something simi
Greetings, All!
# uname -a; screen --version; screen -admS mc-server-session
CYGWIN_NT-6.1 daemon2 2.8.0(0.309/5/3) 2017-04-01 20:47 x86_64 Cygwin
Screen version 4.05.01 (GNU) 25-Feb-17
# screen -S mc-server-session -Q windows
If I SEGV the hung child, there's a stacktrace, though I don't know
> ht writes:
>
> > Andrew Schulman writes:
> >
> >> So I just uploaded a new test release, 4.3.1-2, that includes the patch.
> >> With
> >> the patch applied, yes I do have
> >>
> >> #define TERMINFO 1
> >>
> >> However in my testing the scrollbar is still missing. Please test the new
> >
ht writes:
> Andrew Schulman writes:
>
>> So I just uploaded a new test release, 4.3.1-2, that includes the patch.
>> With
>> the patch applied, yes I do have
>>
>> #define TERMINFO 1
>>
>> However in my testing the scrollbar is still missing. Please test the new
>> release yourself, and
Andrew Schulman writes:
> So I just uploaded a new test release, 4.3.1-2, that includes the patch. With
> the patch applied, yes I do have
>
> #define TERMINFO 1
>
> However in my testing the scrollbar is still missing. Please test the new
> release yourself, and let me know what you find.
> So I just uploaded a new test release, 4.3.1-2, that includes the patch.
BTW that patch and the test release are for x86_64 only. IIRC the bug didn't
occur in i686, but I'd have to look back at it to be sure.
--
Problem reports: http://cygwin.com/problems.html
FAQ: htt
> This is at least _suggestive_ that your compilation environment and mine
> are in some way different.
>
> Does
>
> #define TERMINFO 1
>
> occur in your build/config.h ?
Henry, thanks for working to track this down. I went back and looked and I did
find one problem: because of an error in
Andrew Schulman writes:
>> >> Otherwise someone will need to do some bisection to find the commit
>> >> that introduced it.
So, bizarrely, here's what I have found.
The distributed screen 4.3 binary has the problem (no scrollbar, etc.)
The distributed screen 4.2 binary does not have the problem
> >> Otherwise someone will need to do some bisection to find the commit
> >> that introduced it.
>
> Remind me what repo to look in for screen?
See https://savannah.gnu.org/git/?group=screen.
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq
ht writes:
> Andrew Schulman writes:
>
>> But if this is a bug, I have no idea what caused it. If it were changes in
>> termcap/terminfo entries in /etc/screenrc, someone would have to decode the
>> entries to figure it out - something I avoid.
>
> No changes in the termcap entry, except somethin
Andrew Schulman writes:
> But if this is a bug, I have no idea what caused it. If it were changes in
> termcap/terminfo entries in /etc/screenrc, someone would have to decode the
> entries to figure it out - something I avoid.
No changes in the termcap entry, except something commented out, but
> To reproduce:
> 1) Update screen package to current (4.03) version;
> 2) Run screen inside mintty;
> 3) Generate enough text to fill the screen and start scrolling
> 4) Click in the scrollbar, or use the mousewheel
> Desired effect
> Scrolling
> Observed effect
> Nothing, wrt scrollba
To reproduce:
1) Update screen package to current (4.03) version;
2) Run screen inside mintty;
3) Generate enough text to fill the screen and start scrolling
4) Click in the scrollbar, or use the mousewheel
Desired effect
Scrolling
Observed effect
Nothing, wrt scrollbar; history review,
xplicitly export
> > > it yourself if you want child processes to see it.
> >
> > OK. Thanks, good to know that.
> >
> > --
> > Still, not sure why I have to export the SHELL var to GNU screen
> > now since in the past several years I have not done this.
>
?
> > > SHELL: /bin/bash
> >
> > No. And in fact, bash does not export SHELL by default, but defaults to
> > defining SHELL as a shell-local variable. You have to explicitly export
> > it yourself if you want child processes to see it.
>
> OK. Thanks, go
does not export SHELL by default, but defaults to
> defining SHELL as a shell-local variable. You have to explicitly export
> it yourself if you want child processes to see it.
OK. Thanks, good to know that.
--
Still, not sure why I have to export the SHELL var to GNU screen
now since in the
On 06/20/2012 07:20 AM, Tom Rodman wrote:
> $ echo $SHELL
> /bin/bash
> $ bash -c 'echo SHELL: $SHELL' # does this prove SHELL is exported?
> SHELL: /bin/bash
No. And in fact, bash does not export SHELL by default, but defaults to
defining SHELL as a shell-local variable. You have to e
Not sure when this problem started. The issue:
GNU screen is starting w/an empty or undefined value for $SHELL, so
the login shell for all screen windows is incorrect:
$ uname -a; cygcheck -c cygwin
CYGWIN_NT-5.1 aqua 1.7.16s(0.261/5/3) 20120604 01:26:35 i686 Cygwin
Cygwin Package
> I just wanted to pass this along... I was having problems with screen
> a couple months ago. I would get an error saying "chown tty: No such
> file or directory" and then it would fail (see
> http://cygwin.com/ml/cygwin/2011-06/msg00222.html).
>
> Paul Hebble was kind enough to write me off-li
I just wanted to pass this along... I was having problems with screen
a couple months ago. I would get an error saying "chown tty: No such
file or directory" and then it would fail (see
http://cygwin.com/ml/cygwin/2011-06/msg00222.html).
Paul Hebble was kind enough to write me off-list with a fi
On Wed, Aug 03, 2011 at 06:45:31AM +0100, Andy Koppe wrote:
> This has nothing to do with mintty and everything to do with screen and its
> configuration, unless you can show that mintty displays
I didn't think it necessarily had anything to do with mintty as an
application, but the TERMCAP settin
On 3 August 2011 05:50, Eric Pruitt wrote:
> On Wed, Aug 03, 2011 at 12:35:10AM -0400, Charles Wilson wrote:
>> On 8/2/2011 11:10 PM, Eric Pruitt wrote:
>> > I want, albeit not with the formatting options I'll. Could you
>> > explain how and why that works?
>>
>> Nope, I flushed that Domain Specif
On Wed, Aug 03, 2011 at 12:35:10AM -0400, Charles Wilson wrote:
> On 8/2/2011 11:10 PM, Eric Pruitt wrote:
> > I want, albeit not with the formatting options I'll. Could you
> > explain how and why that works?
>
> Nope, I flushed that Domain Specific Language from my short term memory
> after ge
On 8/2/2011 11:10 PM, Eric Pruitt wrote:
> I want, albeit not with the formatting options I'll. Could you
> explain how and why that works?
Nope, I flushed that Domain Specific Language from my short term memory
after getting it to work as I wanted. I'd just be regurgitating the
Fine Manual for
On Tue, Aug 02, 2011 at 10:58:41PM -0400, Charles Wilson wrote:
> On 8/2/2011 9:30 PM, Eric Pruitt wrote:
> > When using mintty with GNU screen, all status messages (captions) are shown
> > in
> > the title bar instead of the interior of the terminal. I originally found
On 8/2/2011 9:30 PM, Eric Pruitt wrote:
> When using mintty with GNU screen, all status messages (captions) are shown
> in
> the title bar instead of the interior of the terminal. I originally found
> this
> feature quite nifty, but now that I use an always-on caption for scre
When using mintty with GNU screen, all status messages (captions) are shown in
the title bar instead of the interior of the terminal. I originally found this
feature quite nifty, but now that I use an always-on caption for screen, it
means that I end up losing visibility of the window title and
On 6/13/2011 9:03 PM, Larry Hall wrote:
>On 6/13/2011 1:28 AM, Jeff Schenck wrote:
>
>>Hello,
>>
>>When trying to run screen, I get the following errors:
>>"chown tty: No such file or directory" in the status bar,
>>followed by "Sorry, could not find a PTY". Then it exits.
>>I
> On 14 June 2011 13:12, Eric Pruitt wrote:
> > Outside of screen, TERM=xterm. Inside of screen, well here is the relevant
> > line from my bashrc; my screenrc doesn't have anything that would affect
> > colors:
> >
> > TERM=screen-256color GNU_SCREEN="active" screen -a -A -RR -T "$TERM" && \
>
On Tue, Jun 14, 2011 at 01:32:39PM +0100, Andy Koppe wrote:
> Ah, this invokes screen itself with TERM=screen-256color, which tells
> it to talk to the outside terminal as if that's another screen, which
> is wrong. You want to be invoking it with TERM=xterm-256color instead
> (which can be selecte
On 14 June 2011 13:12, Eric Pruitt wrote:
> Outside of screen, TERM=xterm. Inside of screen, well here is the relevant
> line from my bashrc; my screenrc doesn't have anything that would affect
> colors:
>
> TERM=screen-256color GNU_SCREEN="active" screen -a -A -RR -T "$TERM" && \
> scree
On 14 June 2011 00:44, Eric Pruitt wrote:
> On Mon, Jun 13, 2011 at 07:23:34PM -0400, Chris Sutcliffe wrote:
>> On 13 June 2011 17:53, Eric Pruitt wrote:
>> > When switching windows on GNU screen, the background on any unoccupied text
>> > cells fails to be redrawn f
On 6/13/2011 1:28 AM, Jeff Schenck wrote:
Hello,
When trying to run screen, I get the following errors: "chown
tty: No such file or directory" in the status bar, followed by
"Sorry, could not find a PTY". Then it exits. I get the same
error in all terminal types I've tried -- rxvt-native, xter
On Mon, Jun 13, 2011 at 07:23:34PM -0400, Chris Sutcliffe wrote:
> On 13 June 2011 17:53, Eric Pruitt wrote:
> > When switching windows on GNU screen, the background on any unoccupied text
> > cells fails to be redrawn for curses applications; see
> > <http://i.imgur.co
On 13 June 2011 17:53, Eric Pruitt wrote:
> When switching windows on GNU screen, the background on any unoccupied text
> cells fails to be redrawn for curses applications; see
> <http://i.imgur.com/veP9B.png>. I am using screen version 4.00.03, mutt
> version 1.5.20, Vim 7.3,
When switching windows on GNU screen, the background on any unoccupied text
cells fails to be redrawn for curses applications; see
<http://i.imgur.com/veP9B.png>. I am using screen version 4.00.03, mutt
version 1.5.20, Vim 7.3, and mintty 0.9.9-1 on a 32-bit Windows Vista
installatio
> Hi Andrew and Corinna,
>
> Yep, something about FAT32 appears to be the problem. As Corinna correctly
> notes, permissions are faked on FAT32. Doesn't matter what chmod I run, it's
> all 644 or 755. Apparently, GNU screen does not like this, but apparently it
>
Hi Andrew and Corinna,
Yep, something about FAT32 appears to be the problem. As Corinna correctly
notes, permissions are faked on FAT32. Doesn't matter what chmod I run, it's
all 644 or 755. Apparently, GNU screen does not like this, but apparently it
also doesn't give any err
On Wed, May 11, 2011 at 09:32:06PM +0200, Corinna Vinschen wrote:
>On May 11 13:08, Edward McGuire wrote:
>> On Wed, May 11, 2011 at 02:34, Corinna Vinschen wrote:
>> > And you know, what have the romans ever done for us?
>>
>> ... apart from better sanitation and medicine and education and
>> irr
On May 11 13:08, Edward McGuire wrote:
> On Wed, May 11, 2011 at 02:34, Corinna Vinschen wrote:
> > And you know, what have the romans ever done for us?
>
> ... apart from better sanitation and medicine and education and
> irrigation and public health and roads and a freshwater system and
> baths
On Wed, May 11, 2011 at 02:34, Corinna Vinschen wrote:
> And you know, what have the romans ever done for us?
... apart from better sanitation and medicine and education and
irrigation and public health and roads and a freshwater system and
baths and public order ...
--
Problem reports: htt
> On May 10 15:07, Andrew Schulman wrote:
> > > a session that I detached on the same tty just seconds before.
> > >
> > > 3. chmod 666 on the socket file did not work (its permissions were
> > > already 644, owned my 'morse', as shown in my original session long).
> >
> > No, I suggested that y
On May 11 09:34, Corinna Vinschen wrote:
> On May 10 15:07, Andrew Schulman wrote:
> > > a session that I detached on the same tty just seconds before.
> > >
> > > 3. chmod 666 on the socket file did not work (its permissions were
> > > already 644, owned my 'morse', as shown in my original sessi
On May 10 15:07, Andrew Schulman wrote:
> > a session that I detached on the same tty just seconds before.
> >
> > 3. chmod 666 on the socket file did not work (its permissions were
> > already 644, owned my 'morse', as shown in my original session long).
>
> No, I suggested that you try 0600, o
> 1. Output of 'cygcheck -svr' appended to the end of this message.
Thanks, looks okay.
> 2. I have the problem whether I run GNU screen from a cmd.exe prompt or
> under rxvt. I tried Peter Li's suggestion of trying to run screen under
> mintty -- still no jo
Hi,
Andrew: Thanks for the help, and for pointing me to this cygwin list!
1. Output of 'cygcheck -svr' appended to the end of this message.
2. I have the problem whether I run GNU screen from a cmd.exe prompt or
under rxvt. I tried Peter Li's suggestion of trying to run scree
On 11:59 AM, Andrew Schulman wrote:
* Read /usr/share/doc/screen/README.Cygwin - there are descriptions
there of known problems with reattachment. But mostly it has to do
with using screen in a DOS terminal.
Any suggestions from other screen users?
Based on my experience, I'd add mintt
Hi Doug.
> Thanks so much for your efforts to port and maintain the GNU screen
> program to Cygwin! I used to use screen all the in the pre-GUI days,
> and now I use ssh regularly for the occasions I need to run something on
> a real win32 or win64 platform. Being able to use
Hi,
Any assistance most appreciated (see below)!
Thanks,
Doug
- Forwarded message from Doug Morse -
Date: Sat, 07 May 2011 16:06:48 -0500
From: Doug Morse
To: Andrew Schulman
Subject: GNU screen on Cygwin: Cannot seem to reattach, no matter what I try
Hi Andrew,
Thanks so much
> Is the vertical split feature of screen already integrated or has it
> been abandoned? I found some discussion about it on the mailing list,
> but it was never mentioned if the patch was stable or applied. When I
> tried the key combination with | and V nothing happened. I would
> appreciate
On 11/17/2010 5:46 AM, Johannes Müller wrote:
Hi,
Is the vertical split feature of screen already integrated or has it been
abandoned? I found some discussion about it on the mailing list, but it was
never mentioned if the patch was stable or applied. When I tried the key
combination with | and
Hi,
Is the vertical split feature of screen already integrated or has it
been abandoned? I found some discussion about it on the mailing list,
but it was never mentioned if the patch was stable or applied. When I
tried the key combination with | and V nothing happened. I would
appreciate havi
Hi, i'm new with mailing-lists use!
>> i'd like to re-talk about a feature with cygwin screen! How can we add
>> the marvellous "Vertical split in GNU screen" with cygwin?
>> I know there were a talk about that between Jeenu V > dot com> and Andrew S
> Hi, i'm new with mailing-lists use!
> i'd like to re-talk about a feature with cygwin screen! How can we add
> the marvellous "Vertical split in GNU screen" with cygwin?
> I know there were a talk about that between Jeenu V dot com> and Andrew Schulman do
On Fri, Aug 06, 2010 at 03:50:28PM +0200, flo wrote:
>Hi, i'm new with mailing-lists use!
>i'd like to re-talk about a feature with cygwin screen! How can we add
>the marvellous "Vertical split in GNU screen" with cygwin?
>I know there were a talk about that bet
Hi, i'm new with mailing-lists use!
i'd like to re-talk about a feature with cygwin screen! How can we add
the marvellous "Vertical split in GNU screen" with cygwin?
I know there were a talk about that between Jeenu V and Andrew Schulman the 19 Apr 2010!
Thanks in advance for
> Though I'm not sure if vertical split is officially supported in GNU
> screen, I noticed what I installed in my Ubuntu (Karmic) supports it
> (C-a |). Does anyone know if it's going to be in Cygwin's port of
> screen any time soon?
Jeenu, I'm the screen main
Hi,
Though I'm not sure if vertical split is officially supported in GNU
screen, I noticed what I installed in my Ubuntu (Karmic) supports it
(C-a |). Does anyone know if it's going to be in Cygwin's port of
screen any time soon?
--
:J
--
Problem reports: http://cygwin.co
On 4/12/2010 8:36 AM, Al G. wrote:
It sounds as though no change is required in screen for this.
Correct.
screen is an ancient program from the dim mists of early terminal days, so I'm
not surprised that it has some problems of this kind.
Don't worry, screen isn't doing anything wrong here.
>> It sounds as though no change is required in screen for this.
>
>Correct.
>
>> screen is an ancient program from the dim mists of early terminal days, so
>> I'm
>> not surprised that it has some problems of this kind.
>
>Don't worry, screen isn't doing anything wrong here. Setting the
>VERASE k
Andrew Schulman wrote:
> It sounds as though no change is required in screen for this.
Correct.
> screen is an ancient program from the dim mists of early terminal days, so I'm
> not surprised that it has some problems of this kind.
Don't worry, screen isn't doing anything wrong here. Setting th
Corinna Vinschen:
> I think I see what you mean now. The c_cc[VERASE] value is the one
> which is expected for the VERASE functionality (unless it's set to
> 0 == _POSIX_VDISABLE), but it has nothing to do with the actual setting
> of the backspace key in the terminal. So, actually the key value
> So, what we really need to implement is what you proposed.
It sounds as though no change is required in screen for this. I trust someone
will let me know if it turns out otherwise.
screen is an ancient program from the dim mists of early terminal days, so I'm
not surprised that it has some pro
On Apr 11 11:33, Corinna Vinschen wrote:
> On Apr 10 22:09, Andy Koppe wrote:
> > Christopher Faylor wrote:
> > > The problem is that screen explicitly sets VERASE to 0. I believe that
> > > it does that to mean "there is really no erase character since I'm
> > > handling that".
> >
> > You're ri
On Apr 10 22:09, Andy Koppe wrote:
> Christopher Faylor wrote:
> > I'm not 100% sure that this is the right fix but the new snapshot at
> > least works around the problem.
>
> Thanks.
>
> > The problem is that screen explicitly sets VERASE to 0. I believe that
> > it does that to mean "there is
On Sat, Apr 10, 2010 at 10:09:32PM +0100, Andy Koppe wrote:
>Christopher Faylor wrote:
>> That should not cause Cygwin to send a null character.
>> I think it should probably just send the default \177 character.
>
>Makes sense given the botched design, but of course it does mean that
>the user's b
Christopher Faylor wrote:
> I'm not 100% sure that this is the right fix but the new snapshot at
> least works around the problem.
Thanks.
> The problem is that screen explicitly sets VERASE to 0. I believe that
> it does that to mean "there is really no erase character since I'm
> handling that
On Sat, Apr 10, 2010 at 01:36:07PM -0400, Christopher Faylor wrote:
>On Sat, Apr 10, 2010 at 12:16:26PM -0400, Christopher Faylor wrote:
>>On Sat, Apr 10, 2010 at 05:00:30PM +0100, Andy Koppe wrote:
>>>The issue only affects the specific case of 'screen' running in the
>>>console without 'tty' in t
On Sat, Apr 10, 2010 at 12:16:26PM -0400, Christopher Faylor wrote:
>On Sat, Apr 10, 2010 at 05:00:30PM +0100, Andy Koppe wrote:
>>The issue only affects the specific case of 'screen' running in the
>>console without 'tty' in the CYGWIN settings: the backspace key sends
>>^@ instead of what's set i
On Sat, Apr 10, 2010 at 05:00:30PM +0100, Andy Koppe wrote:
>Christopher Faylor:
>>>Workarounds: Add 'set CYGWIN=tty' to Cygwin.bat (or wherever you're
>>>starting your session from), or use one of the other terminals.
>>If setting CYGWIN=tty affects the setting of the backspace key for ptys
>>then
Christopher Faylor:
>>Workarounds: Add 'set CYGWIN=tty' to Cygwin.bat (or wherever you're
>>starting your session from), or use one of the other terminals.
>
> If setting CYGWIN=tty affects the setting of the backspace key for ptys
> then that's a bug in Cygwin. You really should *not* be setting
On Sat, Apr 10, 2010 at 10:31:36AM +0100, Andy Koppe wrote:
>Workarounds: Add 'set CYGWIN=tty' to Cygwin.bat (or wherever you're
>starting your session from), or use one of the other terminals.
If setting CYGWIN=tty affects the setting of the backspace key for ptys
then that's a bug in Cygwin. Yo
Al G.:
> using GNU screen (4.00.03) and trying to backspace by
> hitting the backspace key results in nothing happening. The cursor
> doesn't move, the character isn't erased and the command remains the
> same (if you hit Enter whatever your typo was gets the usual error)
3: Backspace key not working in GNU screen.
^^^
And there's really no need for this repeated header information. It's
largely content-free in the mail list thread.
On 4/8/2010 4:07 PM, Al G. wrote:
This started happening ar
> From: "Larry Hall (Cygwin)"
> To: cyg...@cygwin.com
> Date: Thu, 08 Apr 2010 16:41:25 -0400
> Subject: Re: 1.7.3: Backspace key not working in GNU screen.
> On 4/8/2010 4:07 PM, Al G. wrote:
>>
>> This started happening around March 23, no problems with sc
On 4/8/2010 4:07 PM, Al G. wrote:
This started happening around March 23, no problems with screen before
then. Since then using GNU screen (4.00.03) and trying to backspace by
hitting the backspace key results in nothing happening. The cursor
doesn't move, the character isn't eras
This started happening around March 23, no problems with screen before
then. Since then using GNU screen (4.00.03) and trying to backspace by
hitting the backspace key results in nothing happening. The cursor
doesn't move, the character isn't erased and the command remains the
same (
On Fri, Dec 18, 2009 at 2:36 PM, Game Fan wrote:
> Wanted to see if cygwin 1.7 is released or not and seen your letter. Don't
> need another source of spam so I'm not subscribing to cygwin ML.
> Are you sure it's problem with CygWin? I'm seeing such problems quite often
> on Linux. The story goes l
On Fri, Dec 18, 2009 at 6:23 AM, Jason Tishler wrote:
> If you only need the reattach feature of screen, then I recommend trying
> dtach:
>
> http://dtach.sourceforge.net/
Thanks for this, Jason. It's working very well for what I use screen
for, with no weird ssh problems either. I am still cur
Karim,
On Wed, Dec 16, 2009 at 07:05:49PM -0700, Karim Ali wrote:
> Sometimes, I get disconnected from my host computer. When this
> happens, I cannot reattach to the screen session when I can reconnect
> via ssh, and my screen session on the host computer is completely
> locked up. ctrl-q, ctrl-a
On Thu, Dec 17, 2009 at 1:06 PM, Andrew Schulman wrote:
> Karim, I'm afraid that I don't have much to offer here. A few thoughts:
>
> After you kill ssh, what does screen -list say?
After I kill ssh, screen -list doesn't do anything. It basically
becomes unresponsive as well.
> You probably know
> Hi,
>
> I have the latest version of screen (4.0.3-4) and using the cygwin 1.7
> beta. My host computer has an sshd server running, and it has a screen
> session open. I then ssh into my host computer from another computer
> and attach to this session with the command:
> screen -AOUxR
>
> Somet
The 1.7 beta works for me. Thank you.
--
Joel Eidsath
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
2009/9/14 Joel Eidsath:
> When I launch screen by typing 'screen' at the basic Cygwin bash prompt, a
> screen.exe cmd window launches and stays open for the entire screen session.
>
> I only see this behavior with Windows 7.
Cygwin 1.7 has a workaround for the Windows 7 bug that causes this. It
wo
When I launch screen by typing 'screen' at the basic Cygwin bash prompt,
a screen.exe cmd window launches and stays open for the entire screen
session.
I only see this behavior with Windows 7.
--
Joel Eidsath
--
Problem reports: http://cygwin.com/problems.html
FAQ: ht
On Thu, Sep 03, 2009 at 12:59:50AM -0400, Dave Steenburgh wrote:
>On Wed, Sep 2, 2009 at 8:26 PM, Christopher Faylor wrote:
>> On Wed, Sep 02, 2009 at 04:14:11PM -0400, Andrew Schulman wrote:
>>>screen is difficult to debug, because it uses two communicating
>>>processes, one in the foreground to t
On Wed, Sep 2, 2009 at 8:26 PM, Christopher Faylor wrote:
> On Wed, Sep 02, 2009 at 04:14:11PM -0400, Andrew Schulman wrote:
>>screen is difficult to debug, because it uses two communicating
>>processes, one in the foreground to talk to your terminal, and one in
>>the background to talk to the proc
On Wed, Sep 02, 2009 at 04:14:11PM -0400, Andrew Schulman wrote:
>screen is difficult to debug, because it uses two communicating
>processes, one in the foreground to talk to your terminal, and one in
>the background to talk to the processes in each window.
That's not that hard to debug. You just
1 - 100 of 170 matches
Mail list logo
