Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
From: Chris Faylor <cgf AT cygnus DOT com>
Date: Wed, 6 Sep 2000 01:34:44 -0400
To: cygwin AT sources DOT redhat DOT com
Cc: bdlow AT nortelnetworks DOT com
Subject: Re: i/o STOP + CONT (bash?) problem
Message-ID: <20000906013444.B7181@cygnus.com>
Reply-To: cygwin AT sources DOT redhat DOT com
Mail-Followup-To: cygwin AT sources DOT redhat DOT com, bdlow AT nortelnetworks DOT com
References: <968167382 DOT 14182 DOT ezmlm AT sources DOT redhat DOT com> <39B5B1FB DOT 14BDFF0D AT nortelnetworks DOT com> <20000905220710 DOT A6604 AT cygnus DOT com> <39B5DB5F DOT C05A7C09 AT nortelnetworks DOT com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.3.6i
In-Reply-To: <39B5DB5F.C05A7C09@nortelnetworks.com>; from bdlow@nortelnetworks.com on Wed, Sep 06, 2000 at 03:51:27PM +1000

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 AT sourceware DOT cygnus DOT com