Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #77859 > unrolled thread
| Started by | "Rick C. Hodgin" <rick.c.hodgin@gmail.com> |
|---|---|
| First post | 2015-12-04 16:06 -0800 |
| Last post | 2015-12-10 10:00 -0800 |
| Articles | 20 on this page of 400 — 31 participants |
Back to article view | Back to comp.lang.c
Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-04 16:06 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-05 13:15 +1300
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-04 16:19 -0800
Re: Prefix and postfix Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-12-05 01:18 +0000
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-04 20:33 -0500
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-05 07:55 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-05 09:09 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-05 11:40 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-06 23:33 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-06 23:10 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-06 15:34 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 10:14 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-06 16:11 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 00:27 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 01:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 00:13 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 01:26 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-07 14:51 +1300
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 02:25 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-07 15:55 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 11:13 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 11:32 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 12:55 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 12:14 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 12:29 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:49 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:47 +0100
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 14:11 +0000
Re: Prefix and postfix Waldek Hebisch <hebisch@antispam.uni.wroc.pl> - 2015-12-13 00:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 01:17 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-12 18:21 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-13 08:31 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-13 15:12 +0530
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 03:40 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 11:41 +0000
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 12:55 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 11:46 -0800
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-08 01:07 +0000
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 09:11 -0500
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 15:26 +0100
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 08:25 -0500
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 13:59 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 09:06 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 14:12 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 08:36 -0800
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-07 21:01 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-07 15:16 -0800
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-08 13:58 -0500
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 12:11 -0500
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 11:06 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:02 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 14:37 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 15:17 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 21:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 23:04 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:19 +0000
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-08 01:12 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:11 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 17:19 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 22:50 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 01:26 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:27 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-09 17:22 +0530
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-09 13:15 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-09 13:07 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-08 07:54 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 23:41 +0100
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 17:50 -0500
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-07 19:43 -0500
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 23:14 +0000
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-07 12:00 -0500
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:59 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 12:14 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 12:45 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:56 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 01:58 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 11:48 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 19:09 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 19:41 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 23:26 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 11:38 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 02:52 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:04 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 05:10 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 13:57 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:20 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:42 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 17:19 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:27 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 17:41 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:46 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 09:50 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-07 18:09 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 10:17 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-07 10:21 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 15:33 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 08:50 -0800
Re: Prefix and postfix Richard Damon <Richard@Damon-Family.org> - 2015-12-07 13:43 -0500
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-07 10:54 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 11:00 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:07 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-07 04:19 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-07 13:58 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 12:32 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-07 20:57 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 00:10 +0100
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-07 15:40 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-08 12:55 +1300
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 00:43 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 01:28 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 01:53 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-08 16:44 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 17:47 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 10:46 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 19:27 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 12:30 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-08 12:37 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-08 21:47 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-08 23:20 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 01:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 02:07 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 13:24 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 14:54 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-09 15:20 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-09 07:59 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-09 21:43 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-09 08:45 -0800
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-22 06:45 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-08 19:20 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-10 21:01 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-10 16:31 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-10 14:03 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:16 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:20 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:24 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:39 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 03:20 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 12:02 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 13:06 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-10 21:46 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-11 10:57 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-10 22:09 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-11 11:22 +1300
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-10 17:27 -0500
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-10 23:07 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 00:11 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 00:25 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 01:42 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 02:36 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 02:55 +0000
Re: Prefix and postfix Udyant Wig <udyantw@gmail.com> - 2015-12-11 20:04 +0530
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 02:22 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 10:33 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 13:28 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 12:30 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 11:23 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 12:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 14:21 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 14:55 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 15:19 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-11 15:28 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-11 08:46 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 12:18 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 12:27 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-11 17:30 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-11 08:51 -0800
Re: Prefix and postfix Philip Lantz <prl@canterey.us> - 2015-12-17 10:55 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-17 11:24 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-11 18:04 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 08:58 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 22:08 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 11:32 +1300
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 22:48 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-12 11:57 +1300
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-11 15:33 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-11 23:43 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-11 20:37 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-11 23:23 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-12 00:01 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-12 02:15 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-12 11:15 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-13 00:52 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 02:05 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-12 18:35 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 13:35 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-13 11:48 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-13 20:36 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 13:14 -0800
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-13 21:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 22:35 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-13 14:48 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-13 23:05 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-13 18:08 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 15:44 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 00:42 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 19:48 -0800
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-14 06:58 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 00:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 12:12 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 08:07 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 17:23 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 10:58 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 12:29 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 14:52 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 19:37 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 20:33 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-15 09:45 +1300
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 13:16 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 21:34 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 21:45 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 22:00 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-14 22:23 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 14:41 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-14 23:38 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 00:50 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 17:00 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-15 01:20 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 11:41 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 04:03 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 12:47 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 05:42 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 14:11 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 06:24 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-15 17:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 08:57 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-15 11:05 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 03:52 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 05:38 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-15 22:30 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 11:17 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 05:38 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 15:02 +0100
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 06:10 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 14:47 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 07:09 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:11 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 09:04 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 09:21 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:19 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:33 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 15:34 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:54 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 21:11 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 22:36 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 15:33 -0800
Re: Prefix and postfix ais523 <ais523@nethack4.org> - 2015-12-24 09:02 +0000
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-25 09:12 -0800
Re: Prefix and postfix ais523 <ais523@nethack4.org> - 2015-12-28 07:15 +0000
Re: Prefix and postfix Philip Lantz <prl@canterey.us> - 2015-12-27 18:40 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-17 00:39 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 02:22 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 11:00 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 16:06 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:52 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 21:24 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 16:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-17 00:55 +0000
Re: Prefix and postfix Gareth Owen <gwowen@gmail.com> - 2015-12-17 19:45 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 01:54 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 22:43 -0500
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-17 04:34 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-17 08:46 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 23:45 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 16:14 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 14:12 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-17 22:42 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 18:21 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 18:43 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 00:21 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-17 17:01 -0800
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-16 22:38 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 06:25 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 17:10 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-17 15:04 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-17 17:24 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 12:26 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 14:46 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:14 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-16 07:28 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 15:28 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 07:40 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-16 16:58 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-16 09:02 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-17 13:58 +0100
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 09:38 -0800
Re: Prefix and postfix Les Cargill <lcargill99@comcast.com> - 2015-12-17 12:31 -0600
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-17 21:07 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-18 11:35 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-18 11:12 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 15:08 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-19 19:36 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 21:08 +0100
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-20 00:48 +0000
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:51 +0100
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 12:09 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 23:13 +0100
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 14:50 -0800
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-19 17:18 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 14:56 -0800
Re: Prefix and postfix James Kuyper <jameskuyper@verizon.net> - 2015-12-19 18:04 -0500
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-28 05:12 -0500
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-19 21:42 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:42 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 08:54 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-21 17:04 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-21 18:34 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-22 15:47 +1300
Re: Prefix and postfix Sjouke Burry <burrynulnulfour@ppllaanneett.nnll> - 2015-12-22 07:09 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-22 21:56 +1300
Re: Prefix and postfix Melzzzzz <mel@zzzzz.com> - 2015-12-22 12:12 +0100
Re: Prefix and postfix Paul <nospam@needed.com> - 2015-12-22 06:49 -0500
Re: Prefix and postfix Melzzzzz <mel@zzzzz.com> - 2015-12-22 14:44 +0100
Re: Prefix and postfix David Thompson <dave.thompson2@verizon.net> - 2015-12-28 05:13 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-20 21:45 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 19:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-21 10:51 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-21 12:22 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-20 21:49 +1300
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 06:36 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 18:42 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-20 15:28 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-20 09:17 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-21 08:10 +1300
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-21 08:06 +1300
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-20 19:58 +0000
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:16 +0000
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:22 +0000
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-20 16:39 -0500
Re: Prefix and postfix "D. Lowe" <d.lowe@openmailbox.org> - 2015-12-20 21:57 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 11:18 +0000
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-18 11:50 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-18 04:04 -0800
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-18 22:56 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-18 20:28 -0800
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-19 22:13 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-18 09:31 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-18 08:44 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-19 12:44 -0800
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-19 11:59 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-19 15:18 +0100
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-20 11:32 +1300
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-20 09:58 +0100
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 17:05 +0000
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-16 21:27 +0000
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-17 02:39 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:20 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 15:52 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 18:51 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-16 08:19 -0800
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-17 00:16 +0000
Re: Prefix and postfix Ian Collins <ian-news@hotmail.com> - 2015-12-15 11:07 +1300
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-14 19:53 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 01:14 +0000
Re: Prefix and postfix Eric Sosman <esosman@comcast-dot-net.invalid> - 2015-12-14 20:42 -0500
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-14 20:50 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 02:00 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-14 21:27 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 10:45 +0000
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-15 03:20 -0800
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-15 08:25 -0500
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 14:38 +0000
Re: Prefix and postfix Jerry Stuckle <jstucklex@attglobal.net> - 2015-12-15 11:12 -0500
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 08:53 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 18:10 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 11:50 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 20:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 13:21 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-15 22:13 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 16:40 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 01:48 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-15 23:56 -0800
Re: Prefix and postfix BartC <bc@freeuk.com> - 2015-12-16 11:38 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 14:11 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-15 17:23 +0000
Re: Prefix and postfix Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-12-16 02:51 +0000
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 08:18 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:10 -0800
Re: Prefix and postfix Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-12-14 09:22 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-14 12:28 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:41 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-14 11:13 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-14 12:42 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-14 09:05 -0800
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-13 12:24 -0800
Re: Prefix and postfix Keith Thompson <kst-u@mib.org> - 2015-12-13 13:17 -0800
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 19:56 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 20:09 -0500
Re: Prefix and postfix Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-12-11 12:44 -0500
Re: Prefix and postfix glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-12-11 21:52 +0000
Re: Prefix and postfix raltbos@xs4all.nl (Richard Bos) - 2015-12-13 20:25 +0000
Re: Prefix and postfix Ken Brody <kenbrody@spamcop.net> - 2015-12-11 12:58 -0500
Re: Prefix and postfix supercat@casperkitty.com - 2015-12-08 11:54 -0800
Re: Prefix and postfix Tim Rentsch <txr@alumni.caltech.edu> - 2015-12-09 11:59 -0800
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:41 +0100
Re: Prefix and postfix David Brown <david.brown@hesbynett.no> - 2015-12-08 09:45 +0100
Re: Prefix and postfix Richard Heathfield <rjh@cpax.org.uk> - 2015-12-07 00:31 +0000
Re: Prefix and postfix John Bode <jfbode1029@gmail.com> - 2015-12-10 08:56 -0800
Re: Prefix and postfix "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-12-10 10:00 -0800
Page 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2015-12-11 13:06 -0500 |
| Message-ID | <n4f35n$o12$1@dont-email.me> |
| In reply to | #78402 |
On 12/11/2015 5:16 AM, Malcolm McLean wrote: > On Thursday, December 10, 2015 at 10:03:15 PM UTC, supe...@casperkitty.com wrote: >> On Thursday, December 10, 2015 at 3:31:59 PM UTC-6, Eric Sosman wrote: >>> That's if the program has a way to discover whether an input is >>> predictable. If it doesn't, then >> >> Do you see any problem with a 3-state indicator of "More input is definitely >> available", "More input will never be available", or "More input is not >> available yet, but might (or might not) become available in future"? >> > More input is definitely available - if your next call if fgetc() that means at least > one character is available. If it's gets() I'd expect a whole line to be available. > > More input will never be available - is that because of normal termination (came to > end of file) abnormal termination (disk was unplugged), or a condition we can't > distinguish - if input just runs out, it could have ended or been broken off, > and only a high-level parser would know and maybe not even then . Eg St Mark's > gospel. > More input not available now but might be in future - that one is fair enough. In the Posix world, you can use select() for something like this. It can tell you if there's input currently available, if there's no input currently available, or (IIRC) the handle has been closed. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-10 21:46 +0000 |
| Message-ID | <n4cro5$6ds$1@dont-email.me> |
| In reply to | #78371 |
On 10/12/2015 21:01, Richard Bos wrote: > BartC <bc@freeuk.com> wrote: > >> On 08/12/2015 18:46, Keith Thompson wrote: > >>> But the only way to know that there are no more characters to be read is >>> to attempt to read the next character. You don't know whether the user >>> is *just about to* type Ctrl-D (or Ctrl-Z, or ...). >>> >>> If you're reading from a disk file this isn't (necessarily) a problem. >> >> Well, I wouldn't bother using the eof idiom for interactive input which >> doesn't a well-defined end-of-file. (There might be Ctrl D, Ctrl Z or >> Ctrl C keys, but these are ways to break out of a program, and don't >> need any help.) > > Ah, so you arbitrarily limit the useability of your precognitive eof(). > Well, that's certainly a choice, but IYAM it's one which showcases the > weakness, not the strength, of your approach. The whole world isn't Unix where everything is all mixed up. (So you can't treat interactive input like interactive input because it might really come from a file. And you can't treat a file like a file because it might really be interactive input! Or maybe it's one of those special /dev/ sources which is different yet again from anything else.) Interactive input to me is line-based. So you read a line at a time, indefinitely until some terminating condition. For example, until the command "quit". That's for text consoles. Interactive input in graphic apps tends to be more elaborate with event loops and such. Then the concept of testing eof seems even less relevant. (Does a mouse have an EOF event associated with it?) EOF would be used for inputs that I would class as files. (And actually, writing little C programs using a getchar loop that exits on EOF, that's a bit awkward to test - how to do I stop it? I can never remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates EOF. Awkward for users too. Another problem is that while you try and write a character-at-a-time input loop in C, terminated by EOF, input tends to be line-buffered to confuse matters further. But you can't write line-buffered input loops because they're either too crude (with arbitrary buffer limits) or too elaborate.) -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-12-11 10:57 +1300 |
| Message-ID | <dcuaqeFo5q0U5@mid.individual.net> |
| In reply to | #78375 |
BartC wrote: > On 10/12/2015 21:01, Richard Bos wrote: >> BartC <bc@freeuk.com> wrote: >> >>> On 08/12/2015 18:46, Keith Thompson wrote: >> >>>> But the only way to know that there are no more characters to be read is >>>> to attempt to read the next character. You don't know whether the user >>>> is *just about to* type Ctrl-D (or Ctrl-Z, or ...). >>>> >>>> If you're reading from a disk file this isn't (necessarily) a problem. >>> >>> Well, I wouldn't bother using the eof idiom for interactive input which >>> doesn't a well-defined end-of-file. (There might be Ctrl D, Ctrl Z or >>> Ctrl C keys, but these are ways to break out of a program, and don't >>> need any help.) >> >> Ah, so you arbitrarily limit the useability of your precognitive eof(). >> Well, that's certainly a choice, but IYAM it's one which showcases the >> weakness, not the strength, of your approach. > > The whole world isn't Unix where everything is all mixed up. (So you > can't treat interactive input like interactive input because it might > really come from a file. And you can't treat a file like a file because > it might really be interactive input! Or maybe it's one of those special > /dev/ sources which is different yet again from anything else.) > > Interactive input to me is line-based. So you read a line at a time, > indefinitely until some terminating condition. For example, until the > command "quit". So the console getting disconnected isn't a terminating condition? > That's for text consoles. Interactive input in graphic apps tends to be > more elaborate with event loops and such. Then the concept of testing > eof seems even less relevant. (Does a mouse have an EOF event associated > with it?) > > EOF would be used for inputs that I would class as files. > > (And actually, writing little C programs using a getchar loop that exits > on EOF, that's a bit awkward to test - how to do I stop it? I can never > remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates > EOF. Awkward for users too. RTFM. -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-10 22:09 +0000 |
| Message-ID | <n4ct24$bja$1@dont-email.me> |
| In reply to | #78376 |
On 10/12/2015 21:57, Ian Collins wrote: > BartC wrote: >> Interactive input to me is line-based. So you read a line at a time, >> indefinitely until some terminating condition. For example, until the >> command "quit". > > So the console getting disconnected isn't a terminating condition? What does that even mean? Or are you still thinking of dumb terminals linked up via RS232? If a dog chewed through the cable, then the software may have a beautiful error message lined up but the user would never see it! >> (And actually, writing little C programs using a getchar loop that exits >> on EOF, that's a bit awkward to test - how to do I stop it? I can never >> remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates >> EOF. Awkward for users too. > > RTFM. It shouldn't be necessary. I consider those keys for use only in emergencies when there is no other way to break out of the program (and then you just try all of them, or press reset, or turn off the power). There should be a more graceful exit from console program. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2015-12-11 11:22 +1300 |
| Message-ID | <dcuc9dFo5q0U8@mid.individual.net> |
| In reply to | #78378 |
BartC wrote: > On 10/12/2015 21:57, Ian Collins wrote: >> BartC wrote: > >>> Interactive input to me is line-based. So you read a line at a time, >>> indefinitely until some terminating condition. For example, until the >>> command "quit". >> >> So the console getting disconnected isn't a terminating condition? > > What does that even mean? > > Or are you still thinking of dumb terminals linked up via RS232? If a > dog chewed through the cable, then the software may have a beautiful > error message lined up but the user would never see it! How is a serial console different from a user connecting remotely and the link going down? What about a local user closing the terminal window? Anyway, serial terminals aren't uncommon even today which is why if you look in just about any server room you will find an old laptop with a serial port! >>> (And actually, writing little C programs using a getchar loop that exits >>> on EOF, that's a bit awkward to test - how to do I stop it? I can never >>> remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates >>> EOF. Awkward for users too. >> >> RTFM. > > It shouldn't be necessary. I consider those keys for use only in > emergencies when there is no other way to break out of the program (and > then you just try all of them, or press reset, or turn off the power). > > There should be a more graceful exit from console program. ^D is graceful... -- Ian Collins
[toc] | [prev] | [next] | [standalone]
| From | Eric Sosman <esosman@comcast-dot-net.invalid> |
|---|---|
| Date | 2015-12-10 17:27 -0500 |
| Message-ID | <n4cu4f$f8f$1@dont-email.me> |
| In reply to | #78380 |
On 12/10/2015 5:22 PM, Ian Collins wrote:
> BartC wrote:
>> On 10/12/2015 21:57, Ian Collins wrote:
>>> BartC wrote:
>>
>>>> Interactive input to me is line-based. So you read a line at a time,
>>>> indefinitely until some terminating condition. For example, until the
>>>> command "quit".
>>>
>>> So the console getting disconnected isn't a terminating condition?
>>
>> What does that even mean?
>>
>> Or are you still thinking of dumb terminals linked up via RS232? If a
>> dog chewed through the cable, then the software may have a beautiful
>> error message lined up but the user would never see it!
>
> How is a serial console different from a user connecting remotely and
> the link going down? What about a local user closing the terminal window?
>
> Anyway, serial terminals aren't uncommon even today which is why if you
> look in just about any server room you will find an old laptop with a
> serial port!
> [...]
Anybody using a USB keyboard? Anybody know what the "S" means?
--
esosman@comcast-dot-net.invalid
"Don't be afraid of work. Make work afraid of you." -- TLM
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-10 23:07 +0000 |
| Message-ID | <n4d0fl$sj9$1@dont-email.me> |
| In reply to | #78375 |
On 10/12/15 21:46, BartC wrote: > On 10/12/2015 21:01, Richard Bos wrote: <snip> >> Ah, so you arbitrarily limit the useability of your precognitive eof(). >> Well, that's certainly a choice, but IYAM it's one which showcases the >> weakness, not the strength, of your approach. > > The whole world isn't Unix where everything is all mixed up. (So you > can't treat interactive input like interactive input because it might > really come from a file. And you can't treat a file like a file because > it might really be interactive input! Or maybe it's one of those special > /dev/ sources which is different yet again from anything else.) <shrug> I cut my teeth on mainframes and the Atari ST. Then I moved to DOS and Windows (while still never quite being able to get away from mainframes). I didn't even /see/ a Unix box until 1990, and I didn't get my own Linux system until about 1996, after I'd already been programming for 15 years. I did not have to change my programming habits even one little bit for Linux, and that certainly includes EOF processing. You make a mountain out of a molehill. > Interactive input to me is line-based. So you read a line at a time, > indefinitely until some terminating condition. For example, until the > command "quit". You can use that model, and that's fine - but what will your program do if your user generates the key sequence that signals EOF? > That's for text consoles. Interactive input in graphic apps tends to be > more elaborate with event loops and such. Then the concept of testing > eof seems even less relevant. (Does a mouse have an EOF event associated > with it?) Not as far as I'm aware, but that's a GUI issue rather than a C issue. > EOF would be used for inputs that I would class as files. The distinction seems arbitrary and pointless. > > (And actually, writing little C programs using a getchar loop that exits > on EOF, that's a bit awkward to test - how to do I stop it? I can never > remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates > EOF. Awkward for users too. It's not awkward for /this/ user, and I can remember just fine how to stop it. Perhaps you could write it down on a Post-It note and stick it on your screen? (I don't do this myself, but then I don't have trouble remembering simple keyboard shortcuts that I use a lot.) > Another problem is that while you try and write a character-at-a-time > input loop in C, terminated by EOF, input tends to be line-buffered to > confuse matters further. But you can't write line-buffered input loops > because they're either too crude (with arbitrary buffer limits) or too > elaborate.) I would agree that arbitrary buffer limits /can/ be too crude, although for quick-and-dirty throwaway programs they work just fine. But a dynamically adjusting buffer isn't all /that/ elaborate. Just a few lines of C that you put in your library and never have to write again. Easy. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-11 00:11 +0000 |
| Message-ID | <n4d481$9kk$1@dont-email.me> |
| In reply to | #78386 |
On 10/12/2015 23:07, Richard Heathfield wrote: > On 10/12/15 21:46, BartC wrote: >> The whole world isn't Unix where everything is all mixed up. (So you >> can't treat interactive input like interactive input because it might >> really come from a file. And you can't treat a file like a file because >> it might really be interactive input! Or maybe it's one of those special >> /dev/ sources which is different yet again from anything else.) > > <shrug> I cut my teeth on mainframes and the Atari ST. Then I moved to > DOS and Windows (while still never quite being able to get away from > mainframes). I didn't even /see/ a Unix box until 1990, and I didn't get > my own Linux system until about 1996, after I'd already been programming > for 15 years. I did not have to change my programming habits even one > little bit for Linux, and that certainly includes EOF processing. You > make a mountain out of a molehill. I started learning on Dec computers (with serial terminals) but didn't really start getting into this stuff until using microprocessor hardware of my own design. While at some point point we had to use a disk operating system, most of my work was graphics applications that did their own thing (CP/M or MSDOS certainly was not much help there). I'm used to the hardware doing what I want rather than having to bend my software. (Then after a number of years I want to do something as simple as fetch the next key press unbuffered, and suddenly it's become next to impossible! It used to be a single 8-bit read from a port.) >> Interactive input to me is line-based. So you read a line at a time, >> indefinitely until some terminating condition. For example, until the >> command "quit". > > You can use that model, and that's fine - but what will your program do > if your user generates the key sequence that signals EOF? I did some experiments using Windows console and a C program in a getchar loop: Ctrl Z returns code 26 Crtl D returns code 4 Ctrl C returns code -1 (EOF). Except that in my console applications, break with Ctrl C is disabled. Anyway a typical input loop in one of my console apps, which needs to use non-portable means to get unbuffered character input (needed in text editors for example), is more elaborate than the standard input loops you see in the C exercises here. >> That's for text consoles. Interactive input in graphic apps tends to be >> more elaborate with event loops and such. Then the concept of testing >> eof seems even less relevant. (Does a mouse have an EOF event associated >> with it?) > > Not as far as I'm aware, but that's a GUI issue rather than a C issue. Yes, that's my point. You don't need to ramp the complexity up that much to make EOF meaningless. >> EOF would be used for inputs that I would class as files. > > The distinction seems arbitrary and pointless. Why is it pointless? Most of the entities on my hard drive, memory stick, DVD etc are files. Why shouldn't I then treat them as files? I don't know how it would work on some file located at some arbitrary URL, but I understand fopen() wouldn't directly work on such a file anyway. >> (And actually, writing little C programs using a getchar loop that exits >> on EOF, that's a bit awkward to test - how to do I stop it? I can never >> remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates >> EOF. Awkward for users too. > > It's not awkward for /this/ user, and I can remember just fine how to > stop it. Perhaps you could write it down on a Post-It note and stick it > on your screen? (I don't do this myself, but then I don't have trouble > remembering simple keyboard shortcuts that I use a lot.) Most of my console apps have their own means of exit. Either a special command, or just Escape. As I explained above, it's difficult to think of the highly interactive commands in a text editor, as coming from a file. Many sequences that use function keys, ctrl, alt shifys etc are difficult to represent in a file anyway. (For macro processing, that is its own handling.) All this boils down to is that using or not using an eof() function, doing secondary checks on fgetc, fread etc, is only relevant in a tiny part of a program. Anything of the slightest complexity won't just have a simple fgetc/EOF loop as the primary user interface. Maybe Unix is full of tiny apps that do something that is piped in and then is piped out again after some per-character processing. That's why I excluded Unix a few posts back. -- Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-11 00:25 +0000 |
| Message-ID | <n4d50l$c1n$1@dont-email.me> |
| In reply to | #78387 |
On 11/12/15 00:11, BartC wrote: <snip> > I'm used to the hardware doing what I want rather than having to bend my > software. I don't have to bend my software to be able to handle EOF in a simple and untaxing way. I'm puzzled that you seem to have to. Are we talking about the same C? > (Then after a number of years I want to do something as simple as fetch > the next key press unbuffered, and suddenly it's become next to > impossible! It used to be a single 8-bit read from a port.) That's a platform issue, not a C issue. >>> Interactive input to me is line-based. So you read a line at a time, >>> indefinitely until some terminating condition. For example, until the >>> command "quit". >> >> You can use that model, and that's fine - but what will your program do >> if your user generates the key sequence that signals EOF? > > I did some experiments using Windows console and a C program in a > getchar loop: > > Ctrl Z returns code 26 > Crtl D returns code 4 > Ctrl C returns code -1 (EOF). > > Except that in my console applications, break with Ctrl C is disabled. Odd. On my Windows machine, ctrl-Z makes getchar() return EOF. Are you sure you used getchar(), not something like the Microsoft version of the (non-standard) getch() function? > Anyway a typical input loop in one of my console apps, which needs to > use non-portable means to get unbuffered character input (needed in text > editors for example), is more elaborate than the standard input loops > you see in the C exercises here. That's not surprising, since the C exercises are designed to exploit the simplicity of the teletype model. >>> That's for text consoles. Interactive input in graphic apps tends to be >>> more elaborate with event loops and such. Then the concept of testing >>> eof seems even less relevant. (Does a mouse have an EOF event associated >>> with it?) >> >> Not as far as I'm aware, but that's a GUI issue rather than a C issue. > > Yes, that's my point. You don't need to ramp the complexity up that much > to make EOF meaningless. <shrug> EOF is useful in situations where you're reading streamed input. GUIs typically hand you input via event notifications rather than through a stream, so a streamed input model solution is not going to apply. >>> EOF would be used for inputs that I would class as files. >> >> The distinction seems arbitrary and pointless. > > Why is it pointless? Most of the entities on my hard drive, memory > stick, DVD etc are files. Right, and so is user input (in the teletype model). That's why I'm puzzled that you are making any distinction. *Everything*'s a file. > > Why shouldn't I then treat them as files? I'm not suggesting you shouldn't. > I don't know how it would work > on some file located at some arbitrary URL, but I understand fopen() > wouldn't directly work on such a file anyway. If you can get a stream connection to it, why not? But if you can't, well, okay, you can't. > >>> (And actually, writing little C programs using a getchar loop that exits >>> on EOF, that's a bit awkward to test - how to do I stop it? I can never >>> remember which of Ctrl D, Ctrl Z or Ctrl C to press so that it generates >>> EOF. Awkward for users too. >> >> It's not awkward for /this/ user, and I can remember just fine how to >> stop it. Perhaps you could write it down on a Post-It note and stick it >> on your screen? (I don't do this myself, but then I don't have trouble >> remembering simple keyboard shortcuts that I use a lot.) > > Most of my console apps have their own means of exit. Either a special > command, or just Escape. As I explained above, it's difficult to think > of the highly interactive commands in a text editor, as coming from a > file. Many sequences that use function keys, ctrl, alt shifys etc are > difficult to represent in a file anyway. (For macro processing, that is > its own handling.) You're talking about console input now, rather than stream-oriented input. I'm puzzled as to why you think EOF would be relevant in that context. > All this boils down to is that using or not using an eof() function, > doing secondary checks on fgetc, fread etc, is only relevant in a tiny > part of a program. Anything of the slightest complexity won't just have > a simple fgetc/EOF loop as the primary user interface. There are more things in heaven and earth, Horatio, than are dreamt of in your philosophy. > Maybe Unix is full of tiny apps that do something that is piped in and > then is piped out again after some per-character processing. That's why > I excluded Unix a few posts back. Just about every Unix program I write will also work just fine on Windows, so I see the distinction as arbitrary and pointless. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-11 01:42 +0000 |
| Message-ID | <n4d9hv$ona$1@dont-email.me> |
| In reply to | #78388 |
On 11/12/2015 00:25, Richard Heathfield wrote:
> On 11/12/15 00:11, BartC wrote:
>> (Then after a number of years I want to do something as simple as fetch
>> the next key press unbuffered, and suddenly it's become next to
>> impossible! It used to be a single 8-bit read from a port.)
>
> That's a platform issue, not a C issue.
OK, well we all have to use one platform or another. And whatever the
platform, at some point you will want unbuffered keyboard input (with
all the shift key info, which is rather sparse in Unix), if you are not
doing full-blown GUI.
>> Ctrl Z returns code 26
>> Crtl D returns code 4
>> Ctrl C returns code -1 (EOF).
>>
>> Except that in my console applications, break with Ctrl C is disabled.
>
> Odd. On my Windows machine, ctrl-Z makes getchar() return EOF. Are you
> sure you used getchar(), not something like the Microsoft version of the
> (non-standard) getch() function?
This is the code:
int c;
do {
c=getchar();
printf("%d\n",c);
} while (c!=EOF);
This is the full set of results on Windows (^Z means Ctrl Z etc, <Enter>
means Enter had to be pressed to get output):
Input: Output sequence:
AB^Z <Enter> (65 66 26)
AB^ZCD <Enter> (65 66 26)
^Z (-1)
AB^D <Enter> (65 66 4 10)
AB^DCD <Enter> (65 66 4 67 68 10)
^D <Enter> (4 10)
AB^C (-1) (program terminates immediately on ^C)
^C (-1) ( " )
It looks a mess. ^Z skips remaining characters on the line including \n.
But ^Z at start of a line is interpreted as ^C.
^D behaves like a normal character.
^C exits immediately, but you lose what you've typed on the line so far.
None of these seem well-behaved enough that you'd want to use them.
Trying to explain the behaviour to a user would be tricky too.
It works much better behaved on an actual file though!
BTW here are the results under Ubuntu:
AB^Z () (program terminates immediately)
^Z ()
AB^D (65,65) (output follows on same line)
^D (-1) (terminates immediately)
AB^C () terminates immediately, no 'stopped'
message)
^C () terminates immediately.
All different again from Windows. I thought you said this was all
straightforward? Here, sometimes the break key works immediately,
somestimes it needs Enter, sometimes it works only the start of a line,
sometimes the -1 (EOF) is seen and printed by the program, sometimes it
never gets there...
It's even more of a mess than I suspected. And this is what I mean about
bending behaviour to suit my software. I want a particular model of how
I expect this to work, and I will arrange for it to work that way.
>> Anyway a typical input loop in one of my console apps, which needs to
>> use non-portable means to get unbuffered character input (needed in text
>> editors for example), is more elaborate than the standard input loops
>> you see in the C exercises here.
>
> That's not surprising, since the C exercises are designed to exploit the
> simplicity of the teletype model.
That's the model that involves RXD and TXD, DTR and DTX, and a dozen
more signals for good measure, that requires thinking about Simplex and
Duplex, that needs extra NULs sent to allow for carriage return, and to
worry about running out of paper, and that only works in capitals? I
can't even remember what you had to do to fix a typo. Oh, and that to be
set to the exact combinations of baudrate, data bits, parity bits and
stop bits?
I think I'll pass on that simplicity, thanks!
>> Why is it pointless? Most of the entities on my hard drive, memory
>> stick, DVD etc are files.
>
> Right, and so is user input (in the teletype model). That's why I'm
> puzzled that you are making any distinction. *Everything*'s a file.
I've just showed above what a nightmare it can be when you try and
pretend a TTY is a file. In an actual file, then ABC<newline> in a field
will yield (65 66 67 \n -1). ABC in a file will yield (65 66 67 -1).
Much more reliable behaviour.
Tell me again what I have to type to emulate that last example?
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-11 02:36 +0000 |
| Message-ID | <n4dclu$v6h$1@dont-email.me> |
| In reply to | #78390 |
On 11/12/15 01:42, BartC wrote:
> On 11/12/2015 00:25, Richard Heathfield wrote:
>> On 11/12/15 00:11, BartC wrote:
>
>>> (Then after a number of years I want to do something as simple as fetch
>>> the next key press unbuffered, and suddenly it's become next to
>>> impossible! It used to be a single 8-bit read from a port.)
>>
>> That's a platform issue, not a C issue.
>
> OK, well we all have to use one platform or another.
Yes, but we can write the code so that it works on a number of platforms.
> And whatever the
> platform, at some point you will want unbuffered keyboard input (with
> all the shift key info, which is rather sparse in Unix), if you are not
> doing full-blown GUI.
Yes, there are times when you specifically want console I/O as opposed
to stream I/O. But, at those times, why would you look for a
stream-oriented EOF indicator? It doesn't make any sense.
>>> Ctrl Z returns code 26
>>> Crtl D returns code 4
>>> Ctrl C returns code -1 (EOF).
>>>
>>> Except that in my console applications, break with Ctrl C is disabled.
>>
>> Odd. On my Windows machine, ctrl-Z makes getchar() return EOF. Are you
>> sure you used getchar(), not something like the Microsoft version of the
>> (non-standard) getch() function?
>
> This is the code:
>
> int c;
> do {
> c=getchar();
> printf("%d\n",c);
> } while (c!=EOF);
Hmmm, odd. Let me try that...
Well, okay, I just tried it. I got -1 for ^Z, which is what I expected
to get. Given that ^Z is the way to signal the end of stream on Windows,
I'd say your implementation is broken. Microsoft, at a guess.
> None of these seem well-behaved enough that you'd want to use them.
They work just fine for me.
> Trying to explain the behaviour to a user would be tricky too.
Trying to explain to a user *how to switch on the computer* is tricky.
Trying to explain to them how to start a program is almost impossible.
Trying to explain to them how to /use/ a program is pointless, because
they won't listen, they won't understand, and they won't remember. It's
a complete waste of time.
Choose your users carefully. If they don't know how to signal the end of
stream input, find brighter users.
> It works much better behaved on an actual file though!
Stream input /is/, in effect, a file. A correctly-written standard C
program (a) doesn't care about the difference and (b) cannot in any case
tell that there /is/ a difference.
>
> BTW here are the results under Ubuntu:
>
> AB^Z () (program terminates immediately)
It shouldn't do. It should suspend. Check your jobs.
> ^Z ()
>
> AB^D (65,65) (output follows on same line)
> ^D (-1) (terminates immediately)
>
> AB^C () terminates immediately, no 'stopped'
> message)
> ^C () terminates immediately.
>
> All different again from Windows.
Microsoft had the chance to be Unix-compatible and decided to be
compatible with CP/M instead. <shrug> No big deal.
> I thought you said this was all
> straightforward?
Yeah.
Windows: ^Z (unless your implementation is broken, in which case get a
better implementation).
Linux: ^D
Looks pretty straightforward to me.
> Here, sometimes the break key works immediately,
> somestimes it needs Enter, sometimes it works only the start of a line,
> sometimes the -1 (EOF) is seen and printed by the program, sometimes it
> never gets there...
I don't have these problems. I can see why you're upset, but it's just
your computer. My computers are all working just fine.
> It's even more of a mess than I suspected. And this is what I mean about
> bending behaviour to suit my software. I want a particular model of how
> I expect this to work, and I will arrange for it to work that way.
Good luck fighting that battle. I try to deal with what's actually
there, not what I'd like to be there, and what's actually there (for me)
is a stream model that works on Unix, Linux, Windows, and MS-DOS (if
anyone is still using genuine DOS nowadays) - and my C programs will
work on all those platforms and many others besides. Stream I/O programs
can even (with a little light necromancy in the JCL department) be
persuaded to work on mainframes!
>>> Anyway a typical input loop in one of my console apps, which needs to
>>> use non-portable means to get unbuffered character input (needed in text
>>> editors for example), is more elaborate than the standard input loops
>>> you see in the C exercises here.
>>
>> That's not surprising, since the C exercises are designed to exploit the
>> simplicity of the teletype model.
>
> That's the model that involves RXD and TXD, DTR and DTX, and a dozen
> more signals for good measure, that requires thinking about Simplex and
> Duplex, that needs extra NULs sent to allow for carriage return, and to
> worry about running out of paper, and that only works in capitals?
That isn't what I meant. By "the teletype model" I mean "the program
types some stuff, and then you type some stuff, and then the program
types some stuff, etc" - in contrast to a GUI, where you click stuff and
callbacks happen.
> I
> can't even remember what you had to do to fix a typo. Oh, and that to be
> set to the exact combinations of baudrate, data bits, parity bits and
> stop bits?
>
> I think I'll pass on that simplicity, thanks!
Strawman. Possibly an accidental one in this case, but still a strawman.
>>> Why is it pointless? Most of the entities on my hard drive, memory
>>> stick, DVD etc are files.
>>
>> Right, and so is user input (in the teletype model). That's why I'm
>> puzzled that you are making any distinction. *Everything*'s a file.
>
> I've just showed above what a nightmare it can be when you try and
> pretend a TTY is a file.
I think I'm right in saying that every programmer I've ever met in
person knows how to use a console. Does anyone else have problems with
this stuff, or is it just BartC?
> In an actual file, then ABC<newline> in a field
> will yield (65 66 67 \n -1). ABC in a file will yield (65 66 67 -1).
> Much more reliable behaviour.
>
> Tell me again what I have to type to emulate that last example?
ABC (with no newline) isn't a text stream format, so you're not going to
be able to emulate it by typing (because standard input is a text
stream). This is obvious, surely?
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-11 02:55 +0000 |
| Message-ID | <n4ddr0$2bb$1@dont-email.me> |
| In reply to | #78393 |
On 11/12/15 02:45, Stefan Ram wrote: > Richard Heathfield <rjh@cpax.org.uk> writes: >> Trying to explain to a user *how to switch on the computer* is tricky. > > I don't explain it. It's the first exercise in my programming courses. > It takes about 2 minutes until everyone has found the power-on switch. I once spent twenty-five minutes on the phone, trying to explain to a user how to switch on a computer - desperately trying to think up new ways to explain the blindingly obvious in words of one syllable. He never did manage to do it, though. (Despite which, he is allowed to vote, which bothers me somewhat.) -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Udyant Wig <udyantw@gmail.com> |
|---|---|
| Date | 2015-12-11 20:04 +0530 |
| Message-ID | <87d1udjbp2.fsf@rudiments.goosenet.in> |
| In reply to | #78395 |
Richard Heathfield <rjh@cpax.org.uk> writes: > I once spent twenty-five minutes on the phone, trying to explain to a > user how to switch on a computer - desperately trying to think up new > ways to explain the blindingly obvious in words of one syllable. He > never did manage to do it, though. (Despite which, he is allowed to > vote, which bothers me somewhat.) Is there a switch to turn on the Critical Thinking Unit during election time? -- Udyant Wig
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-12-11 02:22 -0800 |
| Message-ID | <457fdd7d-30b5-4836-a977-12c1c26a3d7a@googlegroups.com> |
| In reply to | #78393 |
On Friday, December 11, 2015 at 2:36:13 AM UTC, Richard Heathfield wrote:
>
> Stream input /is/, in effect, a file. A correctly-written standard C
> program (a) doesn't care about the difference and (b) cannot in any case
> tell that there /is/ a difference.
>
You're not a twirling cursor man I take it.
(You printf("\b/") and printf("\b\\") alternately to indicate that the program
is thinking and hasn't crashed).
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-11 10:33 +0000 |
| Message-ID | <n4e8l0$ddi$1@dont-email.me> |
| In reply to | #78405 |
On 11/12/15 10:22, Malcolm McLean wrote:
> On Friday, December 11, 2015 at 2:36:13 AM UTC, Richard Heathfield wrote:
>>
>> Stream input /is/, in effect, a file. A correctly-written standard C
>> program (a) doesn't care about the difference and (b) cannot in any case
>> tell that there /is/ a difference.
>>
> You're not a twirling cursor man I take it.
Once, I think, when converting a dictionary into a relatively
complicated cryptanalytical data structure. (I don't mean it was hard to
understand, just a bit tricky to do right.) I thought it was going to
take a *long* time.
I just looked back at that program now. I needn't have bothered with the
twirly thing - the loading takes less than half a second.
But I didn't fool myself that the twirly thing was somehow part of a
stream (output, in this case, but of course with pipes they are two
sides of the same coin). As a matter of fact, that program would have
been quite a good candidate for ncurses, now that I think about it.
> (You printf("\b/") and printf("\b\\") alternately to indicate that the program
> is thinking and hasn't crashed).
I used \|/- because it looks better. But, when writing that program, I
realised that I was to some extent limiting the platforms on which it
could run. For example, that cursor would most certainly not twirl under
TSO.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ken Brody <kenbrody@spamcop.net> |
|---|---|
| Date | 2015-12-11 13:28 -0500 |
| Message-ID | <n4f4fe$tic$1@dont-email.me> |
| In reply to | #78407 |
On 12/11/2015 5:33 AM, Richard Heathfield wrote: > On 11/12/15 10:22, Malcolm McLean wrote: >> On Friday, December 11, 2015 at 2:36:13 AM UTC, Richard Heathfield wrote: >>> >>> Stream input /is/, in effect, a file. A correctly-written standard C >>> program (a) doesn't care about the difference and (b) cannot in any case >>> tell that there /is/ a difference. >>> >> You're not a twirling cursor man I take it. > > Once, I think, when converting a dictionary into a relatively complicated > cryptanalytical data structure. (I don't mean it was hard to understand, > just a bit tricky to do right.) I thought it was going to take a *long* time. > > I just looked back at that program now. I needn't have bothered with the > twirly thing - the loading takes less than half a second. [...] Back in "ye good olde days", I would do something like update the "twirling cursor" every 100 times through the main loop. Eventually, the computers got fast enough that it was "spinning" faster than the 9600bps terminals could display, so I upped it to every 1000, which eventually became "too fast" again. That's when I learned to use clock() to update once a second rather than N times through a loop. -- Kenneth Brody
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-12-11 12:30 -0800 |
| Message-ID | <lnr3ishgo7.fsf@kst-u.example.com> |
| In reply to | #78452 |
Ken Brody <kenbrody@spamcop.net> writes:
[...]
> Back in "ye good olde days", I would do something like update the "twirling
> cursor" every 100 times through the main loop. Eventually, the computers
> got fast enough that it was "spinning" faster than the 9600bps terminals
> could display, so I upped it to every 1000, which eventually became "too
> fast" again. That's when I learned to use clock() to update once a second
> rather than N times through a loop.
clock() reports CPU time, not real time. Which means that the speed at
which the cursor twirls probably tells you something about what the
program is doing. It would spin more slowly, or not at all, if the
program is waiting on an I/O operation.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-11 11:23 +0000 |
| Message-ID | <n4ebjn$noc$1@dont-email.me> |
| In reply to | #78393 |
On 11/12/2015 02:36, Richard Heathfield wrote:
> On 11/12/15 01:42, BartC wrote:
>> OK, well we all have to use one platform or another.
>
> Yes, but we can write the code so that it works on a number of platforms.
One feature I like using all the the time is the ability to wait for a
single key press. (Less often, the ability to test is a key has been
pressed.)
It appears to be incredibly straightforward but I don't think you can do
it in a portable manner. Would it have killed anyone to have simply made
available getch() and kbhit() on all platforms that support a keyboard?
Or is it not possible because, for some reason, it is essential that
some obsolete terminal protocol still has to be supported?
>> int c;
>> do {
>> c=getchar();
>> printf("%d\n",c);
>> } while (c!=EOF);
>
> Hmmm, odd. Let me try that...
>
> Well, okay, I just tried it. I got -1 for ^Z, which is what I expected
> to get.
Did you try it at the start of a line, or also in the middle of a line?
> I'd say your implementation is broken. Microsoft, at a guess.
>> Trying to explain the behaviour to a user would be tricky too.
>
> Trying to explain to a user *how to switch on the computer* is tricky.
OK, let's have a go:
(1) Keep typing stuff
(2) To indicate the end of the 'stuff' and proceed to the next bit, you
have to type Ctrl Z in Windows, or Ctrl D in Unix.
(3) NOTE: you have type Ctrl Z or Ctrl D when you're at start of a line.
For example, immediately after pressing Enter.
(4) WARNING: Don't press Ctrl C either in Windows or Unix, because that
will just quit the program and you will lose that hours' work you've
just spent typing in stuff
(5) WARNING: Don't press Ctrl Z in Unix, as it might do the same as Ctrl C.
Sound's good, yes? Well, I would beg to differ. I'd rather write
something like:
(1) Keep typing stuff
(2) To indicate the end the 'stuff', and proceed to the next bit, press
<special key>
Why is this better? Clearly I need to spell it out:
* There is no distinction made between Windows and Unix; they use the
same 'end of data' key
* It didn't have to explain about being at the start of the line,
because /it doesn't matter/
* I didn't have give the warnings about Ctrl C or Ctrl Z, because /they
don't force a break/ and therefore cannot accidentally ruin the session.
This is what I mean about bending things to conform to the model I have
in mind. Instead of everyone, programmers and millions of users, having
to bend themselves to some warped and broken implementation.
> Choose your users carefully. If they don't know how to signal the end of
> stream input, find brighter users.
That's a ridiculous idea. How long would it take to fix a program so
that it works in a user-friendly way that doesn't generate so many
support calls?
>> It works much better behaved on an actual file though!
>
> Stream input /is/, in effect, a file. A correctly-written standard C
> program (a) doesn't care about the difference and (b) cannot in any case
> tell that there /is/ a difference.
You keep saying that. And you want programs to tie themselves up in
knots pretending that they are the same, when it would often be much
easier, and make things much clearer, to keep them separate.
>>
>> BTW here are the results under Ubuntu:
>>
>> AB^Z () (program terminates immediately)
>
> It shouldn't do. It should suspend. Check your jobs.
OK, both my Windows system and my Ubuntu are broken! Because they do
something different to your machines. This is *exactly* the problem.
Each user's machine might also be 'broken'. This is why it is better to
impose a more consistent, higher level model.
This what I get from running that example:
...$ ./a.out
AB^Z
[1]+ Stopped ./a.out
I don't know what you mean about checking jobs. But it's something I'd
rather not have to add to that first list of instructions.
> I don't have these problems. I can see why you're upset, but it's just
> your computer. My computers are all working just fine.
Of course. It's not just my ideas that are wrong, but both my OSes are
broken too!
>> I've just showed above what a nightmare it can be when you try and
>> pretend a TTY is a file.
>
> I think I'm right in saying that every programmer I've ever met in
> person knows how to use a console. Does anyone else have problems with
> this stuff, or is it just BartC?
What do you mean by having problems? BartC has listed the behaviours
he's found, and he doesn't like it. He would rather not have to write a
set of instructions like the first lot.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2015-12-11 12:38 +0000 |
| Message-ID | <n4efvb$763$1@dont-email.me> |
| In reply to | #78415 |
On 11/12/15 11:23, BartC wrote:
> On 11/12/2015 02:36, Richard Heathfield wrote:
>> On 11/12/15 01:42, BartC wrote:
>
>>> OK, well we all have to use one platform or another.
>>
>> Yes, but we can write the code so that it works on a number of platforms.
>
> One feature I like using all the the time is the ability to wait for a
> single key press. (Less often, the ability to test is a key has been
> pressed.)
Yes, I used to do that a lot on the Atari ST and in MS-DOS. I remember
being appalled to discover that there was no standard way to do it.
> It appears to be incredibly straightforward but I don't think you can do
> it in a portable manner. Would it have killed anyone to have simply made
> available getch() and kbhit() on all platforms that support a keyboard?
Pretty much what I thought. But we don't get to control computer
designers. You won't find a getch() function on TSO, for example. And I
think I'm right in saying you won't find a kbhit() function in
Microsoft's C library. And getch() doesn't do what you'd expect in MSVC
(or at least, it doesn't do what I'd expect).
Unfortunately, not all computer systems support interaction in quite
that way. Even those with a keyboard are very often designed around the
idea that the user types a complete line (or even a complete screen) and
then presses ENTER.
Maybe you'd rather it wasn't that way. Well, okay, I can understand
that. But the world /is/ that way, and the question is how we deal with it.
> Or is it not possible because, for some reason, it is essential that
> some obsolete terminal protocol still has to be supported?
By "obsolete terminal protocol" I am guessing you mean "a kind of
computer system that BartC doesn't use". But other people /do/ use those
systems.
>
>>> int c;
>>> do {
>>> c=getchar();
>>> printf("%d\n",c);
>>> } while (c!=EOF);
>>
>> Hmmm, odd. Let me try that...
>>
>> Well, okay, I just tried it. I got -1 for ^Z, which is what I expected
>> to get.
>
> Did you try it at the start of a line, or also in the middle of a line?
Neither. I typed ^Z *after* a line.
Standard input is line-oriented. A line is terminated by a newline
character. After I'd typed the newline character, I was at the end of a
line, not the start of one. At this point I used ^Z to indicate that
there would be no more standard input for this program. That's a
sensible point at which to do it - when the line is complete.
You seem to be suggesting that I should tell my program that input is
complete, when it cannot possibly be complete because I'm only partway
through a line. I'm sorry, but that's just plain daft.
> (1) Keep typing stuff
>
> (2) To indicate the end of the 'stuff' and proceed to the next bit, you
> have to type Ctrl Z in Windows, or Ctrl D in Unix.
>
> (3) NOTE: you have type Ctrl Z or Ctrl D when you're at start of a line.
> For example, immediately after pressing Enter.
>
> (4) WARNING: Don't press Ctrl C either in Windows or Unix, because that
> will just quit the program and you will lose that hours' work you've
> just spent typing in stuff
>
> (5) WARNING: Don't press Ctrl Z in Unix, as it might do the same as Ctrl C.
>
> Sound's good, yes?
Other than the fact that it's badly conceived, badly written, and
factually incorrect, I don't see any other major problems with it.
> Well, I would beg to differ. I'd rather write
> something like:
>
> (1) Keep typing stuff
>
> (2) To indicate the end the 'stuff', and proceed to the next bit, press
> <special key>
That's badly written too.
> Why is this better?
Well, it's slightly less wrong (mostly because it's shorter).
> Clearly I need to spell it out:
>
> * There is no distinction made between Windows and Unix; they use the
> same 'end of data' key
Well, that's not true, is it?
> * It didn't have to explain about being at the start of the line,
After the end of the line, actually.
> because /it doesn't matter/
You don't like text streams, obviously. That's your problem, though,
isn't it?
> * I didn't have give the warnings about Ctrl C or Ctrl Z, because /they
> don't force a break/ and therefore cannot accidentally ruin the session.
In any computer system, keystrokes are context-sensitive. Ctrl-C is
"copy to clipboard". No, wait, it's "interrupt a console program". No,
wait, it's "fire the laser beam at the big monster". No, wait, it's...
And that's just on Windows, let alone minicomputers or big iron.
It is advantageous to have a keystroke that can interrupt a program and
terminate it, and this is especially true for neophyte programmers, who
are the most likely (although by no means the only ones) to get the loop
condition wrong and have the damn thing going round and round forever.
They are really glad to have Ctrl-C, but you would take it away from them.
As for Ctrl-Z, it doesn't force a break. On Windows (in a console), if
you use it correctly it indicates the end of a text-oriented stream.
Under Linux (in a console), it suspends the task.
> This is what I mean about bending things to conform to the model I have
> in mind.
I don't like your model and I don't want your model and I have no desire
to conform to your model. Neither, it seems, does the computing world.
Otherwise, it would surely have done so by now.
> Instead of everyone, programmers and millions of users, having
> to bend themselves to some warped and broken implementation.
It's not warped, it's not broken, and it's not even singular. You just
have to learn how to use it. Computers are complicated beasts, and we
can make them a certain amount of simple, but there comes a point where,
if we put in too much simple, we don't get enough useful out the other end.
>> Choose your users carefully. If they don't know how to signal the end of
>> stream input, find brighter users.
>
> That's a ridiculous idea. How long would it take to fix a program so
> that it works in a user-friendly way that doesn't generate so many
> support calls?
And that's a ridiculous question. Seriously, if you cannot trust your
users to operate console programs, you should not be writing console
programs. If your users are too stupid to use the console, write GUI
programs. If your users are merely too /ignorant/ to use the console, a
very different situation indeed, then educate them.
>>> It works much better behaved on an actual file though!
>>
>> Stream input /is/, in effect, a file. A correctly-written standard C
>> program (a) doesn't care about the difference and (b) cannot in any case
>> tell that there /is/ a difference.
>
> You keep saying that. And you want programs to tie themselves up in
> knots pretending that they are the same, when it would often be much
> easier, and make things much clearer, to keep them separate.
We already make some distinctions:
1) stream-based console programs - typically filters, translators, and
the like;
2) full-screen console programs - ncurses, MS Console API, that sort of
thing;
3) fully-fledged GUI programs - OpenOffice, Excel, etc.
You clearly like 2) and 3), but not 1). Fine, so don't write 1)
programs. Some of us, however, /do/ like 1), and we'd like to carry on
writing those programs (as well as the other two kinds, and any other
kinds that I've overlooked), if that's all right.
>>> BTW here are the results under Ubuntu:
>>>
>>> AB^Z () (program terminates immediately)
>>
>> It shouldn't do. It should suspend. Check your jobs.
>
> OK, both my Windows system and my Ubuntu are broken! Because they do
> something different to your machines. This is *exactly* the problem.
I think it's more likely that you don't understand your machines. The
reason our results differ on Windows is that I know where the end of a
line is. On Linux, ^Z doesn't terminate a program, but suspends it. Type
'jobs' and you should see it in the list.
> Each user's machine might also be 'broken'. This is why it is better to
> impose a more consistent, higher level model.
Or you could just learn how to use your computer. That might work too.
> This what I get from running that example:
>
> ...$ ./a.out
> AB^Z
> [1]+ Stopped ./a.out
>
> I don't know what you mean about checking jobs.
I realise that. Nevertheless, if you check jobs, you'll find your
process listed there.
> But it's something I'd
> rather not have to add to that first list of instructions.
That list was already too long.
>> I don't have these problems. I can see why you're upset, but it's just
>> your computer. My computers are all working just fine.
>
> Of course. It's not just my ideas that are wrong, but both my OSes are
> broken too!
Well, one of them is, but that's a different argument. No, in this case
they are both working correctly, but you don't know what they're
designed to do and you haven't taken the trouble to try to find out.
Instead, you assume that your mental model is correct and then attempt
to bend the world around that model. That's understandable up to a point
(we all do it to some degree), but there comes a time when you need to
realise that there may be more yet to learn about computers, and that
your mental model might just not be giving the whole picture.
>
>>> I've just showed above what a nightmare it can be when you try and
>>> pretend a TTY is a file.
>>
>> I think I'm right in saying that every programmer I've ever met in
>> person knows how to use a console. Does anyone else have problems with
>> this stuff, or is it just BartC?
>
> What do you mean by having problems?
I don't know. You seem to be the one that's having them, not me.
> BartC has listed the behaviours
> he's found, and he doesn't like it. He would rather not have to write a
> set of instructions like the first lot.
Okay, so you don't like standard I/O. No problem. There are lots of
alternatives. Use one of those.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | BartC <bc@freeuk.com> |
|---|---|
| Date | 2015-12-11 14:21 +0000 |
| Message-ID | <n4em16$vd9$1@dont-email.me> |
| In reply to | #78421 |
On 11/12/2015 12:38, Richard Heathfield wrote:
> On 11/12/15 11:23, BartC wrote:
>> Did you try it at the start of a line, or also in the middle of a line?
>
> Neither. I typed ^Z *after* a line.
Clearly you're keen on making it extra confusing to users by making a
distinction between the end of one line, and the beginning of another!
Suppose a user wants to enter one, two, three then quit. He types
one Enter
two Enter
three Enter
at this point, the program is waiting for further input. Line 3 has
already been entered, and completed by pressing Enter /after/ that
line's contents have been typed, and when the cursor was actually at the
end of the line.
It's now positioned at the start of the line, and the program is waiting
at what might be the start of the fourth line of input.
It is at this point that the user then presses whatever break key is
needed to quit.
To me, that sounds very much as though the key is pressed at the start
of this current line. Not at the end of the previous line, which
wouldn't actually work, not without losing that line's data:
three^Z
> Standard input is line-oriented. A line is terminated by a newline
> character.
My experiments show that that isn't always the case. If you've already
typed AB, then ^Z will abort the program (Unix), ^D will complete the
line, without the newline (Unix), ^C will also abort (Unix), ^D will
appear as character 4 (Windows), ^C will lose the abort the line and
return EOF (Windows).
> After I'd typed the newline character, I was at the end of a
> line, not the start of one.
No. See the above. You are physically at the start of the next line.
Logically you can be at the end of one, *and* at the start of the next.
So 'Start of the line' wins.
> You seem to be suggesting that I should tell my program that input is
> complete, when it cannot possibly be complete because I'm only partway
> through a line. I'm sorry, but that's just plain daft.
In a line-oriented file, the last line need not end with a newline. You
were saying about files and keyboard input being exactly the same ... ?
>> Sound's good, yes?
>
> Other than the fact that it's badly conceived, badly written, and
> factually incorrect, I don't see any other major problems with it.
Which facts aren't correct? That I referred to the start of the line
rather than the end?
The above would be for an app where lots of data is typed in then it
does something else (like entering a bunch of words then displaying a
histogram). On something like interactive Python on Ubuntu and Windows:
ABC^DDEF The ^D is ignored
^D Quits
ABC^Z Unix: Quits; Windows: same as backspace!
^Z Quits
ABC^C Aborts the line with 'KeyboardInterrupt'
^C 'Keyboardinterrupt'
So a slightly different set of behaviours again. But notice that ^Z can
be used to quit /in the middle of a line/ (or rather, at the end as you
can't type anything following!).
It's hard to tell whether Python sees those Quit events, so that it can
do some finalising, or whether the OS just pulls the plug. This is the
sort of info I would need.
>> * There is no distinction made between Windows and Unix; they use the
>> same 'end of data' key
>
> Well, that's not true, is it?
Well it is true because I can make it so. Like I can say, press "exit"
followed by Enter to finish. That's not OS-specific.
> You don't like text streams, obviously. That's your problem, though,
> isn't it?
Text streams are fine. But they're not a file. They don't need to have a
concept of an EOF just because you're trying to make them like files.
There's all this stuff with Ctrl Z, Ctrl D and Ctrl C which really have
little to do with emulating EOF, which they do badly, and more to do
with process control.
A console is interactive, so you can give instructions at the start.
This makes it more flexible.
And actually I would further separate text streams from live,
interactive input. So:
* Files
* Open-ended streams
* Classic, interactive keyboard input ('kill dwarf with axe').
I find keeping these separate makes things a lot simpler than trying to
unify them.
>> Of course. It's not just my ideas that are wrong, but both my OSes are
>> broken too!
>
> Well, one of them is, but that's a different argument. No, in this case
> they are both working correctly, but you don't know what they're
> designed to do and you haven't taken the trouble to try to find out.
> Instead, you assume that your mental model is correct and then attempt
> to bend the world around that model. That's understandable up to a point
> (we all do it to some degree),
We should all do it a lot more.
I tend to do it from habit: from building my own gear, writing my own
languages, writing my own drivers for everything etc etc, but also being
self-employed for many years and not having to answer to anybody (only
clients).
--
Bartc
[toc] | [prev] | [next] | [standalone]
Page 8 of 20 — ← Prev page 1 … 6 7 [8] 9 10 … 20 Next page →
Back to top | Article view | comp.lang.c
csiph-web