bob wrote: I wonder if there is a way to get a ^S from xboard, ever? That would certainly stop all output to it until a ^Q is sent (flow control). However, I don't see anything like that internally in xboard.
To check that, I made an "od -t c" of the timeseal log file. It doesn't see anything like ^S flying by. ('\a' is the Bell caharcter received from FICS). It receives a board +prompt, sends the reply move, sends a kibitz, both with CR and LF as only control characters, and then FICS goes dumb. So I suppose we can exclude this possibility.
1603720 - > ' \a \n \r ' \n F I C S - >
1603740 ' < 1 2 > r n b q k b n r
1603760 p p p p p p p p - - - - - - -
1604000 - - - - - - - - - - - - - -
1604020 - - - - - - - - N - - P P P
1604040 P P P P P R N B Q K B - R B
1604060 - 1 1 1 1 1 1 6 0
1604100 F a i r y M a x W B t e s t
1604120 e r 1 1 0 3 9 3 9 6
1604140 0 0 0 0 6 0 0 0 0 1 N / g
1604160 1 - f 3 ( 0 : 0 0 . 0 0 0 )
1604200 N f 3 1 0 0 \n \r ' \n F I C
1604220 S - > ' f i c s % ' \n F I
1604240 C S < - ' f 7 f 5 \n k i b i
1604260 t z ! ! ! + 0 . 1 0 / 6 (
1604300 0 . 5 6 s e c , 8 9 3 6 8
1604320 n o d e s , 1 5 9 k n p s )
1604340 P V = f 7 f 5 c 2 c 4 b 8
1604360 c 6 d 2 d 4 g 8 f 6 b 1 c
1604400 3 \n ' \n F I C S < - ' w h o
1604420 \n ' \n F I C S < - ' t e l l
1604440 f a i r y I a m s t u c
1604460 k ! \n ' \n
1604465
bob wrote: I wonder if there is a way to get a ^S from xboard, ever? That would certainly stop all output to it until a ^Q is sent (flow control). However, I don't see anything like that internally in xboard.
To check that, I made an "od -t c" of the timeseal log file. It doesn't see anything like ^S flying by. ('\a' is the Bell caharcter received from FICS). It receives a board +prompt, sends the reply move, sends a kibitz, both with CR and LF as only control characters, and then FICS goes dumb. So I suppose we can exclude this possibility.
1603720 - > ' \a \n \r ' \n F I C S - >
1603740 ' < 1 2 > r n b q k b n r
1603760 p p p p p p p p - - - - - - -
1604000 - - - - - - - - - - - - - -
1604020 - - - - - - - - N - - P P P
1604040 P P P P P R N B Q K B - R B
1604060 - 1 1 1 1 1 1 6 0
1604100 F a i r y M a x W B t e s t
1604120 e r 1 1 0 3 9 3 9 6
1604140 0 0 0 0 6 0 0 0 0 1 N / g
1604160 1 - f 3 ( 0 : 0 0 . 0 0 0 )
1604200 N f 3 1 0 0 \n \r ' \n F I C
1604220 S - > ' f i c s % ' \n F I
1604240 C S < - ' f 7 f 5 \n k i b i
1604260 t z ! ! ! + 0 . 1 0 / 6 (
1604300 0 . 5 6 s e c , 8 9 3 6 8
1604320 n o d e s , 1 5 9 k n p s )
1604340 P V = f 7 f 5 c 2 c 4 b 8
1604360 c 6 d 2 d 4 g 8 f 6 b 1 c
1604400 3 \n ' \n F I C S < - ' w h o
1604420 \n ' \n F I C S < - ' t e l l
1604440 f a i r y I a m s t u c
1604460 k ! \n ' \n
1604465
Ctrl-S (Stop) and Ctrl-Q (Continue) will not be sent as characters via standard I/O, so you should never see these in a log file. Flow control handling is a special thing.
For the same reason I am not sure whether receiving a Ctrl-S character from xboard would have the effect of stopping any output to it until Ctrl-Q is received. Programs can read from standard input and continue to work normally even if they read a "Ctrl-S" character.
bob wrote: I wonder if there is a way to get a ^S from xboard, ever? That would certainly stop all output to it until a ^Q is sent (flow control). However, I don't see anything like that internally in xboard.
To check that, I made an "od -t c" of the timeseal log file. It doesn't see anything like ^S flying by. ('\a' is the Bell caharcter received from FICS). It receives a board +prompt, sends the reply move, sends a kibitz, both with CR and LF as only control characters, and then FICS goes dumb. So I suppose we can exclude this possibility.
1603720 - > ' \a \n \r ' \n F I C S - >
1603740 ' < 1 2 > r n b q k b n r
1603760 p p p p p p p p - - - - - - -
1604000 - - - - - - - - - - - - - -
1604020 - - - - - - - - N - - P P P
1604040 P P P P P R N B Q K B - R B
1604060 - 1 1 1 1 1 1 6 0
1604100 F a i r y M a x W B t e s t
1604120 e r 1 1 0 3 9 3 9 6
1604140 0 0 0 0 6 0 0 0 0 1 N / g
1604160 1 - f 3 ( 0 : 0 0 . 0 0 0 )
1604200 N f 3 1 0 0 \n \r ' \n F I C
1604220 S - > ' f i c s % ' \n F I
1604240 C S < - ' f 7 f 5 \n k i b i
1604260 t z ! ! ! + 0 . 1 0 / 6 (
1604300 0 . 5 6 s e c , 8 9 3 6 8
1604320 n o d e s , 1 5 9 k n p s )
1604340 P V = f 7 f 5 c 2 c 4 b 8
1604360 c 6 d 2 d 4 g 8 f 6 b 1 c
1604400 3 \n ' \n F I C S < - ' w h o
1604420 \n ' \n F I C S < - ' t e l l
1604440 f a i r y I a m s t u c
1604460 k ! \n ' \n
1604465
Ctrl-S (Stop) and Ctrl-Q (Continue) will not be sent as characters via standard I/O, so you should never see these in a log file. Flow control handling is a special thing.
For the same reason I am not sure whether receiving a Ctrl-S character from xboard would have the effect of stopping any output to it until Ctrl-Q is received. Programs can read from standard input and continue to work normally even if they read a "Ctrl-S" character.
Sven
I think it depends on several things. For example, "raw mode" setting. In unix, when two processes are talking, they can send anything they want thru a pipe, which seems to be the way HGM is "snooping" in the data. In any case, for it to make FICS stop sending something, FICS would have to see it to do anything with it, so it would have to go out thru the TCP/IP connection. I can telnet to a remote machine, and use ^S to stop output coming my way, which is the normal way it is used. Should FICS somehow receive a ^S, it would certainly stop sending anything back. But that might not be the explanation...
Sven Schüle wrote:Ctrl-S (Stop) and Ctrl-Q (Continue) will not be sent as characters via standard I/O, so you should never see these in a log file. Flow control handling is a special thing.
That is not true for files, isn't it? Just for character-type devices like terminals. Files can be binaries, and I am pretty sure that binaries will contain many bytes that represent ^S. In Unix-type systems there should be no difference between text output ("w" mode ) and binary output ("wb" mode). That is just a Windows thing, where "wb" has to substitute CR for LF. And even in that case, no other control characters will be messed with.
Programs just send the data to the output destination. It is the device drivers for terminals or com ports that might interpret certain control codes as special function. But never ordinary files. They are not character-type devices, but block type..
Sven Schüle wrote:Ctrl-S (Stop) and Ctrl-Q (Continue) will not be sent as characters via standard I/O, so you should never see these in a log file. Flow control handling is a special thing.
That is not true for files, isn't it? Just for character-type devices like terminals. Files can be binaries, and I am pretty sure that binaries will contain many bytes that represent ^S. In Unix-type systems there should be no difference between text output ("w" mode ) and binary output ("wb" mode). That is just a Windows thing, where "wb" has to substitute CR for LF. And even in that case, no other control characters will be messed with.
Programs just send the data to the output destination. It is the device drivers for terminals or com ports that might interpret certain control codes as special function. But never ordinary files. They are not character-type devices, but block type..
Correct. And you can set a TTY to raw mode because you may well want to send the hex character ^S or whatever to a graphics device to move the cursor (vector graphics terminal) among other things. Not to mention the need to be able to send binary data of any type...
