Subject: Re: i/o STOP + CONT (bash?) problem
From: Chris Faylor <[email-masked]>
To: [email-masked]
Cc: [email-masked]
Date: Wed, 6 Sep 2000 01:34:44 -0400

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 [email-masked]