i/o STOP + CONT (bash?) problem

i/o STOP + CONT (bash?) problem

[Benjamin Low]

Does anyone have trouble with START and STOP signals w/ cygwin? (cygwin
1.1.3 distribution, on a W2k box) - in particular with bash?

Details:

If I issue a Ctrl-S (STOP) directly to bash within a terminal (W32 rxvt
or X11R6 xterm), it's game over - there seems to be nothing I can do to
restore output, even signalling the process externally doesn't help. If
I send a STOP signal from another process (i.e. kill -STOP <bashpid>,
not via Ctrl-S) and then CONT, it works as expected for W32 rxvt's but
not for xterms (output pauses whilst STOPped, then CONTinues). Note that
the process continues to run, just all tty output halts.

When I kill the terminal window via the Windows task manager, it notes
"the program is not responding". Screen updates and such (even the
window title bar) do not occur.

The problem occurs both under the native windows rxvt terminal emulator
(v2.7.2, from http://www.io.com/~bub/rxvt.html ), plus xterm from the
X11R6 4.0 cygwin binary package, running under Exceed. I've not fiddled
with my stty config.

For example (reproducible exactly as shown):

within a W32 rxvt (PID of bash shell is 19071):

19071 $ rxvt -e bash &
[19574]

(PID of new rxvt is 19574, bash is 19575)
19575 $ while [ 1 ]; do echo $RANDOM; sleep 1; done
31196
6885
...   (and so on, with bash starting a new sleep process every second)

(from my original shell:)
19071 $ kill -STOP 19574    (i.e. STOP rxvt)
(output stops, my original shell returns  [1]+  Stopped  rxvt -e bash)
19071 $ kill -CONT 19574    (i.e. CONT rxvt)
(output flushes and continues)

19071 $ kill -STOP 19575    (i.e. STOP bash)
(output stops)
19071 $ kill -CONT 19575    (i.e. CONT bash)
(output flushes and continues)

So, signalling externally seems to work fine for the W32 rxvt, both for
the terminal and shell. If I try the above with an xterm, the signalling
of the xterm works, but signalling bash causes a lockup (i.e. the kill
-CONT <bashpid> does not restore output).

If I send STOP directly to bash via ctrl-S (in either a W32 rxvt or
xterm), it locks up forevermore. The processes seem to continue to run
for a while, in the above example the while loop continues to fire up
new sleep processes every second, and presumably the shell continues to
echo output (until it fills the output buffer). After a ctrl-S, ps -l
shows an "I" next to the PID of the rxvt containing the mute bash
process:

$ ps -l
...
I 21959 21376 21959     1416 11707  12 12:39:38 /usr/local/bin/rxvt.exe
  21960 21959 21960     2768 11707   0 12:39:38 /usr/bin/bash.exe

After about a minute:
$ ps -l
...
I 21959 21376 21959     1416 11707  12 12:39:38 /usr/local/bin/rxvt.exe
O 21960 21959 21960     2768 11707   0 12:39:38 /usr/bin/bash.exe
(and no new sleep processes are started - i.e. the shell has halted, I
assume the O means "waiting for Output"?).

On a possibly related note, INTR (ctrl-C) sometimes stops working in
bash. For example, right now I have two W32 rxvt's up running bash, one
is still accepting ctrl-C to cancel the current input line, the other is
ignoring me. Other input seems to work, including ctrl-U (kill line),
ctrl-H (erase).

I have played with strace but can't see how to follow forks, plus it
doesn't work with the native W32 rxvt, so it's a bit hard to see what's
going on. Does strace have a -p (attach to PID) or -f (follow forks)
option?

I've searched the mail archives without seeing any similar problem.

Please find my cygcheck output attached.

> From: Chris Faylor <cgf@cygnus.com>
...
> 1) If it isn't clear, cygwin is currently in use by thousands of people.
>    AFAIK, none of them have reported problems where "echo seems to be
>    turned off".  That means that we need a lot more details.  The first
>    thing would be the output of 'cygcheck -r -s -v'.


-- 
Benjamin D Low                         bdlow@nortelnetworks.com
Nortel Networks Technology Centre      +61 2 4254 7473
Wollongong NSW Australia               ESN 639 7473

Cygnus Win95/NT Configuration Diagnostics
Current System Time: Wed Sep  6 12:23:32 2000

WinNT Ver 5.0 build 2195 

Path:	/home/bdlow/bin
	/usr/local/bin
	/usr/bin
	/usr/bin
	/c/WINNT/system32
	/c/WINNT
	/c/WINNT/System32/Wbem
	/usr/bin
	/usr/X11R6/bin

SysDir: C:\WINNT\System32
WinDir: C:\WINNT

CYGWIN = `ntea ntsec'
HOME = `/home/bdlow'
MAKE_MODE = `unix'
PWD = `/home/bdlow'
USER = `bdlow'

!C: = `C:\cygwin\bat'
!D: = `D:\Nortel\Ben Low'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
APPDATA = `C:\Documents and Settings\lowb\Application Data'
CLASSPATH = `C:\Program Files\Exceed.nt'
COLORFGBG = `0;default;15'
COLORTERM = `rxvt-xpm'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
COMPUTERNAME = `LOWB-1'
COMSPEC = `C:\WINNT\system32\cmd.exe'
DEVMGR_SHOW_NONPRESENT_DEVICES = `1'
DISPLAY = `localhost:0'
EDITOR = `vi'
ENV = `/home/bdlow/.bash_profile'
HOMEDRIVE = `C:'
HOMEPATH = `\'
HOSTNAME = `LOWB-1'
HOSTTYPE = `i586'
IGNOREEOF = `2'
LC_ALL = `en_AU'
LESS = `-Plines %lt-%lb (%pt-%pb\% of bytes) %f$'
LOGONSERVER = `\\ZNOTC002'
MACHTYPE = `i586-pc-cygwin'
MANPATH = `:'
MXBIN = `C:\program files\Formida\Fire3\mx\i386\win32\bin'
MXHOME = `C:\program files\Formida\Fire3'
NNTPSERVER = `wolnews'
NUMBER_OF_PROCESSORS = `1'
OS2LIBPATH = `C:\WINNT\system32\os2\dll;'
OS = `Windows_NT'
OSTYPE = `cygwin'
PAGER = `less'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
PRINTER = `hp'
PROCESSOR_ARCHITECTURE = `x86'
PROCESSOR_IDENTIFIER = `x86 Family 6 Model 7 Stepping 3, GenuineIntel'
PROCESSOR_LEVEL = `6'
PROCESSOR_REVISION = `0703'
PROGRAMFILES = `C:\Program Files'
PROMPT = `$P$G'
PROMPT_COMMAND = `echo -ne "\033]0;${HOSTNAME}:${PWD}\007"'
RSYNC_RSH = `ssh'
SHELL = `/bin/bash'
SHLVL = `1'
SYSTEMDRIVE = `C:'
SYSTEMROOT = `C:\WINNT'
TEMP = `/tmp'
TERM = `xterm'
TMP = `/tmp'
TMPDIR = `/tmp'
USERDOMAIN = `ASIAPACIFIC'
USERNAME = `bdlow'
USERPROFILE = `C:\Documents and Settings\lowb'
WINDIR = `C:\WINNT'
WINDOWID = `168100008'
_ = `/usr/bin/cygcheck'
ftp_proxy = ` http://zwolh008:8080/ '
http_proxy = ` http://zwolh008:8080/ '
TZ = `AUSEST-10AUSEDT-11,M10.5.0/2,M3.5.0/2'

HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
  (default) = `/cygdrive'
  cygdrive flags = 0x00000020
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/
  (default) = `C:/cygwin'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/c
  (default) = `c:'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/d
  (default) = `d:'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/h
  (default) = `\\zwoln001\bdlow'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/home/bdlow
  (default) = `D:\Nortel\Ben Low'
  flags = 0x00000000
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/tmp
  (default) = `C:\tmp'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
  (default) = `C:/cygwin/bin'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
  (default) = `C:/cygwin/lib'
  flags = 0x00000002
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\MenuOrder\Start Menu\Programs\Cygnus Solutions
  (default) = (unsupported type)

a:  fd           N/A    N/A                    
c:  hd  NTFS    5592Mb  33% CP CS UN PA FC     
d:  hd  NTFS    8997Mb  37% CP CS UN PA FC     NORTEL
e:  cd           N/A    N/A                    
h:  net FAT    82520Mb  98% CP CS UN           CIFS.HOMEDIR

D:\Nortel\Ben Low  /home/bdlow  user    textmode
\\zwoln001\bdlow  /h       user    textmode
C:\cygwin\bin  /usr/bin  user    binmode
C:\cygwin\lib  /usr/lib  user    binmode
C:\cygwin  /        user    binmode
C:\tmp  /tmp     user    binmode
c:    /c       user    textmode
d:    /d       user    textmode

Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cpp.exe
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\sh.exe

   83k 2000/06/11 C:\cygwin\bin\cygitcl30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitcl30.dll" v0.0 ts=2000/6/11 13:34
   35k 2000/06/11 C:\cygwin\bin\cygitk30.dll - os=4.0 img=1.0 sys=4.0
                  "cygitk30.dll" v0.0 ts=2000/6/11 13:34
  402k 2000/06/11 C:\cygwin\bin\cygtcl80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtcl80.dll" v0.0 ts=2000/6/11 13:30
    5k 2000/06/11 C:\cygwin\bin\cygtclpip80.dll - os=4.0 img=1.0 sys=4.0
   10k 2000/06/11 C:\cygwin\bin\cygtclreg80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtclreg80.dll" v0.0 ts=2000/6/11 13:30
  639k 2000/06/11 C:\cygwin\bin\cygtk80.dll - os=4.0 img=1.0 sys=4.0
                  "cygtk80.dll" v0.0 ts=2000/6/11 13:34
  568k 2000/07/27 C:\cygwin\bin\cygwin1.dll - os=4.0 img=1.0 sys=4.0
                  "cygwin1.dll" v0.0 ts=2000/7/28 0:59
    Cygwin DLL version info:
        dll major: 1001
        dll minor: 3
        dll epoch: 19
        dll bad signal mask: 19005
        dll old termios: 5
        api major: 0
        api minor: 24
        shared data: 3
        dll identifier: cygwin1
        mount registry: 2
        cygnus registry name: Cygnus Solutions
        cygwin registry name: Cygwin
        program options name: Program Options
        cygwin mount registry name: mounts v2
        build date: Thu Jul 27 10:59:35 EDT 2000
        shared id: cygwin1S3

Use -h to see help about each section

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Wed, Sep 06, 2000 at 12:54:51PM +1000, Benjamin Low wrote:
>Does anyone have trouble with START and STOP signals w/ cygwin? (cygwin
>1.1.3 distribution, on a W2k box) - in particular with bash?
>
>Details:
>
>If I issue a Ctrl-S (STOP) directly to bash within a terminal (W32 rxvt
>or X11R6 xterm), it's game over - there seems to be nothing I can do to
>restore output, even signalling the process externally doesn't help. If
>I send a STOP signal from another process (i.e. kill -STOP <bashpid>,
>not via Ctrl-S) and then CONT, it works as expected for W32 rxvt's but
>not for xterms (output pauses whilst STOPped, then CONTinues). Note that
>the process continues to run, just all tty output halts.

Um.  CTRL-S has nothing to do with the STOP signal.  Hitting CTRL-S
pauses any output.  CTRL-Q restarts it.  This is pretty standard
behavior for both Windows and UNIX.

So, hit CTRL-Q if you want stuff to start up again.

If you are referring to SIGSTOP (or more precisely SIGTSTP), then this is
usually invoked by hitting CTRL-Z.  This causes any running foreground
process to be stopped and usually causes the invoking shell to issue a
prompt.

In most shells that support this you start the program up again by
typing 'fg'.

This is typical behavior for both UNIX and Cygwin, however, under Cygwin,
for this to work reliably you need to use "tty" mode, i.e., the CYGWIN
environment variable needs to contain "tty" (without the quotes).

You should set this prior to starting any cygwin program, e.g.,

c:\>set CYGWIN=tty
c:\>bash

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Benjamin Low]

Chris,

Thanks for the prompt reply.

Chris Faylor wrote:
...
> Um.  CTRL-S has nothing to do with the STOP signal.  

As I understand (understood :-) it, the terminal driver issues various
signals to the current process in response to predetermined input
sequences (set via stty). Thus with the "standard" stty config, ctrl-C
sends an SIGINT, ctrl-S sends SIGSTOP, etc. This gels with my practical
experience in that kill -STOP|-CONT <pid> works the same as
ctrl-S|ctrl-Q (on every unix I've worked on (linux, solaris,
cywgin-sometimes).

...
> So, hit CTRL-Q if you want stuff to start up again.

Oh, if it were that easy :-)

> usually invoked by hitting CTRL-Z.  This causes any running foreground
> process to be stopped and usually causes the invoking shell to issue a

I believe ctrl-Z is normally associated with SIGSUSP (suspend), which
behaves much as you have described - pausing execution of the process
(not just it's i/o).

> for this to work reliably you need to use "tty" mode, i.e., the CYGWIN
> environment variable needs to contain "tty" (without the quotes).

Tried that, without success. My (system wide) CYGWIN environment
variable is now "ntsec ntea tty", the problem still occurs as before.

What happens when you try ctrl-S/Q within bash?

-- 
Benjamin D Low                         bdlow@nortelnetworks.com
Nortel Networks Technology Centre      +61 2 4254 7473
Wollongong NSW Australia               ESN 639 7473
begin:vcard 
n:Low;Benjamin
tel;work:ESN 639 7473, +61 2 4254 7473
x-mozilla-html:FALSE
org:Nortel Networks
version:2.1
email;internet:bdlow@nortelnetworks.com
adr;quoted-printable:;;Nortel Networks Technology Centre=0D=0ANorthfields Avenue;Wollongong;NSW;2500;Australia
note;quoted-printable:Not to be confused with benlow@nortelnetworks.com, who works =0D=0Ain Richardson, Texas, U.S.A.
fn:Benjamin Low
end:vcard

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Wed, Sep 06, 2000 at 03:51:27PM +1000, Benjamin Low wrote:
>Thanks for the prompt reply.
>
>Chris Faylor wrote:
>...
>> Um.  CTRL-S has nothing to do with the STOP signal.  
>
>As I understand (understood :-) it, the terminal driver issues various
>signals to the current process in response to predetermined input
>sequences (set via stty). Thus with the "standard" stty config, ctrl-C
>sends an SIGINT, ctrl-S sends SIGSTOP, etc. This gels with my practical
>experience in that kill -STOP|-CONT <pid> works the same as
>ctrl-S|ctrl-Q (on every unix I've worked on (linux, solaris,
>cywgin-sometimes).

Sorry, you are understanding wrong.  CTRL-S (aka XOFF) does not send
SIGSTOP.

At a gross level, I guess you could say that sending a SIGSTOP to
a signal stops a process similarly to the way that typing CTRL-S
stops output but the two are really very different.

You can verify this on linux by doing a 'ps' on a test process.  It will
be in the 'T' state if you've do a 'kill -STOP' to the process.  It
will also be in a 'T' state if you type CTRL-Z.

It will be in some other state ('S', probably) when you've stopped the
output with CTRL-S.

For fun, once you've done this, try doing a 'kill -CONT' on the
process where you just typed CTRL-Q.  You won't see any change.

>...
>> So, hit CTRL-Q if you want stuff to start up again.
>
>Oh, if it were that easy :-)

It is that easy.

>> usually invoked by hitting CTRL-Z.  This causes any running foreground
>> process to be stopped and usually causes the invoking shell to issue a
>
>I believe ctrl-Z is normally associated with SIGSUSP (suspend), which
>behaves much as you have described - pausing execution of the process
>(not just it's i/o).

There is no such thing as SIGSUSP.  On UNIX systems, when you press the
CTRL-Z, a SIGTSTP signal is sent to every process in the terminal's
process group.

The CTRL-Z key is the default key for this behavior but you can change
it by using the command 'stty susp x'.  This is accomplished at the
programming level by setting VSUSP element in the c_cc array located in
the termios structure.  It's manipulated by the tcsetattr call.

Or, at least, this is how it works on Cygwin and Linux.  Older systems
used different methods for accomplishing the same goal.

>>for this to work reliably you need to use "tty" mode, i.e., the CYGWIN
>>environment variable needs to contain "tty" (without the quotes).
>
>Tried that, without success.  My (system wide) CYGWIN environment
>variable is now "ntsec ntea tty", the problem still occurs as before.
>
>What happens when you try ctrl-S/Q within bash?

CTRL-S (XOFF) stops the output.  CTRL-Q (aka XON) starts it.  I
tried this, of course, before responding the first time even though
I knew how this worked.

When I said "for this to work reliably", I was referring to CTRL-Z.
I was not suggesting that this was a catch-all fix for whatever
CTRL-Q/CTRL-S problems you are having.

Is it safe to assume that you have now tried to type CTRL-Q after
suspending output with CTRL-S and you are still experiencing problems?

Anyway, do you now understand that there are no signals involved in this
operation?  The behavior of CTRL-S and CTRL-Q is actually controlled by
Windows, not Cygwin.  It shouldn't matter if you type 'ls' or 'dir' both
should be started and stopped with CTRL-S and CTRL-Q.

I'm assuming that you're not telneted into your Windows system or
something like that.  If you are, then I don't know if CTRL-S/CTRL-Q
work correctly with Cygwin in that scenario.  I've seen some complaints
about that (but surprisingly no patches to fix the problem) here.

So, I'm no closer to understanding your problem except that if you think
that CTRL-S and CTRL-Q are related to signals you're really far afield.
These characters are used to provide flow control in communications
streams.  They are implemented in modems, terminals, the linux console,
etc. all without the benefit of a "signal".

Or, at least without a signal in the UNIX sense of things.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Wed, Sep 06, 2000 at 01:34:44AM -0400, Chris Faylor wrote:
>On Wed, Sep 06, 2000 at 03:51:27PM +1000, Benjamin Low wrote:
>>Thanks for the prompt reply.
>>
>>Chris Faylor wrote:
>>...
>>> Um.  CTRL-S has nothing to do with the STOP signal.  
>>
>>As I understand (understood :-) it, the terminal driver issues various
>>signals to the current process in response to predetermined input
>>sequences (set via stty). Thus with the "standard" stty config, ctrl-C
>>sends an SIGINT, ctrl-S sends SIGSTOP, etc. This gels with my practical
>>experience in that kill -STOP|-CONT <pid> works the same as
>>ctrl-S|ctrl-Q (on every unix I've worked on (linux, solaris,
>>cywgin-sometimes).
>
>Sorry, you are understanding wrong.  CTRL-S (aka XOFF) does not send
>SIGSTOP.
>
>At a gross level, I guess you could say that sending a SIGSTOP to
>a signal stops a process similarly to the way that typing CTRL-S
>stops output but the two are really very different.
>
>You can verify this on linux by doing a 'ps' on a test process.  It will
>be in the 'T' state if you've do a 'kill -STOP' to the process.  It
>will also be in a 'T' state if you type CTRL-Z.
>
>It will be in some other state ('S', probably) when you've stopped the
>output with CTRL-S.
>
>For fun, once you've done this, try doing a 'kill -CONT' on the
>process where you just typed CTRL-Q.  You won't see any change.
			      CTRL-S

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Wed, Sep 06, 2000 at 08:23:47PM -0400, Chris Faylor wrote:
>On Thu, Sep 07, 2000 at 10:41:50AM +1000, Benjamin Low wrote:
>>Earnie Boyd wrote:
>>> --- Chris Faylor <cgf@cygnus.com> wrote:
>>>>I need someone to figure out why this is happening.
>>>>
>>>I'll get to it eventually.  I'm leaning toward a bug in rxvt.
>>
>>Note I see the same behaviour under xterm (from XFree86 4.0.1(139)).
>
>I looked into this a little.  It's a cygwin pty bug.

I checked in a fix for this.  It should be in the next snapshot.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Thu, Sep 07, 2000 at 10:41:50AM +1000, Benjamin Low wrote:
>
>Earnie Boyd wrote:
>> --- Chris Faylor <cgf@cygnus.com> wrote:
>> > 
>> > I need someone to figure out why this is happening.
>> > 
>> I'll get to it eventually.  I'm leaning toward a bug in rxvt.
>
>Note I see the same behaviour under xterm (from XFree86 4.0.1(139)).

I looked into this a little.  It's a cygwin pty bug.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Benjamin Low]

Earnie Boyd wrote:
> --- Chris Faylor <cgf@cygnus.com> wrote:
> > 
> > I need someone to figure out why this is happening.
> > 
> I'll get to it eventually.  I'm leaning toward a bug in rxvt.

Note I see the same behaviour under xterm (from XFree86 4.0.1(139)).

-- 
Benjamin D Low                         bdlow@nortelnetworks.com
Nortel Networks Technology Centre      +61 2 4254 7473
Wollongong NSW Australia               ESN 639 7473
begin:vcard 
n:Low;Benjamin
tel;work:ESN 639 7473, +61 2 4254 7473
x-mozilla-html:FALSE
org:Nortel Networks
version:2.1
email;internet:bdlow@nortelnetworks.com
adr;quoted-printable:;;Nortel Networks Technology Centre=0D=0ANorthfields Avenue;Wollongong;NSW;2500;Australia
note;quoted-printable:Not to be confused with benlow@nortelnetworks.com, who works =0D=0Ain Richardson, Texas, U.S.A.
fn:Benjamin Low
end:vcard

Re: i/o STOP + CONT (bash?) problem

[Earnie Boyd]

--- Chris Faylor <cgf@cygnus.com> wrote:
> 
> I need someone to figure out why this is happening.
> 

I'll get to it eventually.  I'm leaning toward a bug in rxvt.

Cheers,

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Wed, Sep 06, 2000 at 09:46:41AM -0700, Rick Rankin wrote:
>I see this same behavior also. I've been assuming, perhaps incorrectly, that
>it's a pty bug, because rxvt doesn't exhibit this behavior on Unix.
>
>FWIW, I'm using rxvt 2.6.2 that I compiled myself using X. My X-Server is
>Exceed.

"Me too" posts are not going to be very useful.

I need someone to figure out why this is happening.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Rick Rankin]

I see this same behavior also. I've been assuming, perhaps incorrectly, that
it's a pty bug, because rxvt doesn't exhibit this behavior on Unix.

FWIW, I'm using rxvt 2.6.2 that I compiled myself using X. My X-Server is
Exceed.

Rick
--
Rick Rankin
rick_rankin@yahoo.com

--- Earnie Boyd <earnie_boyd@yahoo.com> wrote:
> --- Benjamin Low <bdlow@nortelnetworks.com> wrote:
> > 
> > What happens when you try ctrl-S/Q within bash?
> > 
> 
> When using bash in rxvt C-s hangs the i/o if there is any i/o in process.  If
> I
> C-s before keyboard i/o it will hang upon the first keystroke.  If I'm output
> to the terminal and C-s it will hang.  This is regardless of the `tty'
> setting.
> 
> When using bash in a DOS console window C-s and C-q work properly regardless
> of
> the `tty' setting.  Now the question is, who is at fault, Cygwin or rxvt?
> 
> Cheers,
> 
> =====
> --- < http://earniesystems.safeshopper.com > ---
>    Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
>             __Cygwin: POSIX on Windows__
> Cygwin Newbies: < http://gw32.freeyellow.com/ >
>            __Minimalist GNU for Windows__
>   Mingw32 List: < http://www.egroups.com/group/mingw32/ >
>     Mingw Home: < http://www.mingw.org/ >
> 
> __________________________________________________
> Do You Yahoo!?
> Yahoo! Mail - Free email you can access from anywhere!
> http://mail.yahoo.com/
> 
> --
> Want to unsubscribe from this list?
> Send a message to cygwin-unsubscribe@sourceware.cygnus.com
> 


__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Chris Faylor]

On Wed, Sep 06, 2000 at 05:18:15AM -0700, Earnie Boyd wrote:
>--- Benjamin Low <bdlow@nortelnetworks.com> wrote:
>>What happens when you try ctrl-S/Q within bash?
>>
>
>When using bash in rxvt C-s hangs the i/o if there is any i/o in
>process.  If I C-s before keyboard i/o it will hang upon the first
>keystroke.  If I'm output to the terminal and C-s it will hang.  This
>is regardless of the `tty' setting.
>
>When using bash in a DOS console window C-s and C-q work properly
>regardless of the `tty' setting.  Now the question is, who is at fault,
>Cygwin or rxvt?

I don't know.  I've seen this bug report circulating for years.

It's a shame that no one is motivated enough to actually debug the
problem.

cgf

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com

Re: i/o STOP + CONT (bash?) problem

[Earnie Boyd]

--- Benjamin Low <bdlow@nortelnetworks.com> wrote:
> 
> What happens when you try ctrl-S/Q within bash?
> 

When using bash in rxvt C-s hangs the i/o if there is any i/o in process.  If I
C-s before keyboard i/o it will hang upon the first keystroke.  If I'm output
to the terminal and C-s it will hang.  This is regardless of the `tty' setting.

When using bash in a DOS console window C-s and C-q work properly regardless of
the `tty' setting.  Now the question is, who is at fault, Cygwin or rxvt?

Cheers,

=====
--- < http://earniesystems.safeshopper.com > ---
   Earnie Boyd: < mailto:earnie_boyd@yahoo.com >
            __Cygwin: POSIX on Windows__
Cygwin Newbies: < http://gw32.freeyellow.com/ >
           __Minimalist GNU for Windows__
  Mingw32 List: < http://www.egroups.com/group/mingw32/ >
    Mingw Home: < http://www.mingw.org/ >

__________________________________________________
Do You Yahoo!?
Yahoo! Mail - Free email you can access from anywhere!
http://mail.yahoo.com/

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe@sourceware.cygnus.com