Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #136032 > unrolled thread

Counting lines of a file

Back to article view | Back to comp.lang.c

Contents

  Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:37 +0200
    Re: Counting lines of a file Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2018-10-02 16:45 -0400
      Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 09:51 +1300
        Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:55 +0200
          Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 14:31 -0700
            Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:39 +0200
              Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 16:39 -0700
                Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:49 +0200
                  Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 11:46 -0700
        Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-02 21:04 +0000
          Re: Counting lines of a file dave_thompson_2@comcast.net - 2018-12-14 17:52 -0500
            Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-15 08:14 +0000
        Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 21:24 +0000
          Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:32 +0200
            Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-03 10:44 +0000
              Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 13:17 +0200
            Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 14:35 +0200
        Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 14:25 -0700
      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 22:54 +0200
      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:43 +0200
        Re: Counting lines of a file Andreas Perstinger <andipersti@gmail.com> - 2018-10-05 11:35 +0000
    Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 20:56 +0000
      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:00 +0200
        Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-02 21:13 +0000
          Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-02 23:28 +0200
            Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-03 10:48 +0000
              Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 12:07 +0100
                Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 14:49 +0200
                  Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 14:25 +0100
                    Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-03 16:05 +0200
                      Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-03 14:17 +0000
                      Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 16:53 +0100
                        Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-03 16:07 +0000
                        Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:12 +0200
                    Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 11:23 -0700
                      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 20:42 +0200
                        Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 12:03 -0700
                          Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 21:45 +0200
                            Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 08:52 +1300
                            Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 13:26 -0700
                          Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:37 +0200
                            Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 15:06 +0100
                              Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 21:48 +0200
                      Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 15:28 +0200
                        Re: Counting lines of a file gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-04 14:16 +0000
                        Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-04 11:09 -0700
                          Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-04 22:00 +0200
                            Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 21:18 +0100
                              Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 20:28 +0000
                                Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 21:59 +0100
                                  Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 21:10 +0000
                              Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-04 15:53 -0700
                                Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-05 00:09 +0100
                                Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 02:06 +0100
                            Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 22:40 +0200
                              Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 21:13 +0000
                              Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 23:09 +0100
                                Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 07:47 +0200
                                  Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-05 09:44 +0200
                                    Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 12:41 +0200
                                      Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-05 16:01 +0200
                                        Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-10-22 13:58 +0000
                                          Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-10-22 16:44 +0200
                                      Re: Counting lines of a file jadill33@gmail.com - 2018-10-08 09:10 -0700
                                  Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 13:17 +0100
                  Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-03 11:34 -0700
              Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 13:14 +0200
                Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 00:59 +0100
                  Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 08:57 +0200
                    Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 20:05 +1300
                    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 10:58 +0100
                      Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-04 04:06 -0700
                        Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:35 +0100
                  Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 11:48 +0100
                    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:30 +0100
                Re: Counting lines of a file queequeg@trust.no1 (Queequeg) - 2018-10-04 21:35 +0000
                  Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 07:35 +0200
            Re: Counting lines of a file Ike Naar <ike@sdf.lonestar.org> - 2018-10-06 23:56 +0000
              Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-07 09:13 +0200
                Re: Counting lines of a file Ike Naar <ike@iceland.freeshell.org> - 2018-10-11 22:14 +0000
                  Re: Counting lines of a file Ralf Damaschke <rwspam@gmx.de> - 2018-10-11 23:14 +0000
                Re: Counting lines of a file antispam@math.uni.wroc.pl - 2018-12-17 20:17 +0000
    Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 13:59 -0700
      Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-02 23:07 +0100
        Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 00:08 +0100
        Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-02 16:51 -0700
    Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 17:47 -0400
      Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 11:57 +0300
        Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-03 06:30 -0400
          Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:37 +0300
        Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:20 -0700
          Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:33 -0700
            Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:55 -0700
            Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:33 +0100
              Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 17:43 -0400
                Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 02:49 +0100
                  Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 22:06 -0400
                    Re: Counting lines of a file gazelle@shell.xmission.com (Kenny McCormack) - 2018-10-04 05:20 +0000
                  Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-04 02:45 -0700
                    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 14:42 +0100
                  Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 11:27 +0100
                    Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-04 03:40 -0700
                    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:17 +0100
                      Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 18:13 +0100
                        Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 17:47 +0000
                          Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 20:49 +0100
                          Re: Counting lines of a file nobody@example.org (Scott) - 2018-10-05 16:52 +0000
                        Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-05 01:49 +0100
                          Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-05 12:08 +0100
                            Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 03:24 +0100
                              Re: Counting lines of a file Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 03:47 +0000
                                Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 14:41 +0100
                                  Re: Counting lines of a file Spiros Bousbouras <spibou@gmail.com> - 2018-10-06 15:05 +0000
                                    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 20:08 +0100
                              Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 13:02 +0100
                                Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 15:51 +0100
                                  Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 17:15 +0100
                                    Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-06 13:22 -0700
                                      Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-06 22:27 +0100
                                        Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-07 11:55 +1300
                                          Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-07 00:02 +0100
                                            Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-07 12:10 +1300
                                              Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-07 01:33 +0100
                                        Re: Counting lines of a file mark.bluemel@gmail.com - 2018-10-08 01:33 -0700
                                          Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-08 12:20 +0100
                                    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 21:51 +0100
                                  Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-06 12:52 -0700
                                    Re: Counting lines of a file already5chosen@yahoo.com - 2018-10-06 13:01 -0700
                                      Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-06 22:01 +0100
                                Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-06 13:17 -0700
                              Re: Counting lines of a file antispam@math.uni.wroc.pl - 2018-12-17 20:50 +0000
                          Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-05 23:09 +0300
                            Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-06 04:02 -0700
                              Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-07 00:29 +0300
                Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 13:22 +0000
                  Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 08:00 -0700
                    Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-10-04 15:30 +0000
                      Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 08:34 -0700
                    Re: Counting lines of a file Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2018-10-04 09:27 -0700
                      Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-04 11:04 -0700
              Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 22:50 +0100
                Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 11:30 +1300
                Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 15:41 -0700
                  Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 00:46 +0100
                    Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 13:01 +1300
                      Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-04 01:22 +0100
                        Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 13:39 +1300
                    Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 18:23 -0700
          Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 13:33 +0100
            Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:40 +0300
            Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:57 -0700
              Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:19 +0100
    Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 11:25 +1300
      Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-02 18:56 -0400
        Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 12:11 +0300
          Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-03 23:06 +1300
            Re: Counting lines of a file Anton Shepelev <ant0n.txt@gmai1.c0m> - 2018-10-03 14:58 +0300
              Re: Counting lines of a file Ian Collins <ian-news@hotmail.com> - 2018-10-04 08:08 +1300
          Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:06 -0700
            Re: Counting lines of a file Anton Shepelev <anton.txt@g{oogle}mail.com> - 2018-10-03 15:13 +0300
              Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 05:26 -0700
    Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 02:59 +0100
      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:57 +0200
      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 08:59 +0200
        Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 21:54 +0100
          Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 23:26 +0200
            Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 22:41 +0100
            Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 02:23 +0100
          Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 14:59 -0700
            Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 03:04 +0100
      Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 09:01 +0200
        Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-03 22:01 +0100
    Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-03 21:44 +0200
      Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-10-03 15:48 -0400
    Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-03 23:15 +0300
      Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-10-03 13:35 -0700
        Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-04 00:14 +0300
          Re: Counting lines of a file Bart <bc@freeuk.com> - 2018-10-03 23:15 +0100
            Re: Counting lines of a file Anton Shepelev <anton.txt@gmail.com> - 2018-10-04 23:28 +0300
          Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-10-03 19:39 -0400
            Re: Counting lines of a file Nick Bowler <nbowler@draconx.ca> - 2018-10-04 15:31 +0000
      Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 01:05 +0100
    Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-04 14:04 +0200
      Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-10-04 15:48 +0100
    Re: Counting lines of a file jacobnavia <jacob@jacob.remcomp.fr> - 2018-10-05 18:29 +0200
    Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 07:50 -1000
      Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 07:54 -1000
      Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 12:51 -0700
        Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-16 20:51 +0000
          Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 14:40 -0700
            Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-16 21:50 +0000
              Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-16 15:38 -0800
              Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 20:29 -0700
                Re: Counting lines of a file Jorgen Grahn <grahn+nntp@snipabacken.se> - 2018-12-18 21:03 +0000
        Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-16 21:17 +0000
        Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 17:13 -1000
          Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-16 23:11 -0700
            Re: Counting lines of a file Joey Pabalinas <joeypabalinas@gmail.com> - 2018-12-16 22:05 -1000
            Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-17 11:52 -0800
              Re: Counting lines of a file luser droog <luser.droog@gmail.com> - 2018-12-17 16:01 -0800
                Re: Counting lines of a file Keith Thompson <kst-u@mib.org> - 2018-12-17 17:35 -0800
                  Re: Counting lines of a file fir <profesor.fir@gmail.com> - 2018-12-19 15:54 -0800
                Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-17 20:01 -0700
                Re: Counting lines of a file Ike Naar <ike@iceland.freeshell.org> - 2018-12-18 07:44 +0000
                  Re: Counting lines of a file nobody@example.org (Scott) - 2018-12-18 09:29 +0000
                    Re: Counting lines of a file David Brown <david.brown@hesbynett.no> - 2018-12-18 13:18 +0100
                Re: Counting lines of a file James Kuyper <jameskuyper@alumni.caltech.edu> - 2018-12-18 06:10 -0800
                  Re: Counting lines of a file rbowman <bowman@montana.com> - 2018-12-18 08:12 -0700
              Re: Counting lines of a file "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2018-12-19 07:47 -0800
      Re: Counting lines of a file Ben Bacarisse <ben.usenet@bsb.me.uk> - 2018-12-16 20:41 +0000
      Re: Counting lines of a file scott@slp53.sl.home (Scott Lurndal) - 2018-12-17 15:18 +0000

Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11  Next page →

#136370

On 06/10/2018 23:55, Ian Collins wrote:
> On 07/10/18 10:27, Bart wrote:

>> And if a simple console app such as a compiler took input from stdin and
>> wrote it to stdout, I would regard it as an unfinished toy program.
> 
> So gcc is an unfinished toy program?

gcc takes input from a series of command line parameters. Most output 
(except for options like -E) go to files. It may or may not use pipes 
internally to communicate with its assembler. Or it may use temporary 
files (on Windows), as it does with its linker.

Actually if I run it like this:

    gcc

then it says no input; it does not attempt to read stdin. Not even if I say:

    gcc <hello.c

So it doesn't fit the category I described. I don't know why you would 
think so.

-- 
bart

[toc] | [prev] | [next] | [standalone]

#136371

On 07/10/18 12:02, Bart wrote:
> On 06/10/2018 23:55, Ian Collins wrote:
>> On 07/10/18 10:27, Bart wrote:
> 
>>> And if a simple console app such as a compiler took input from stdin and
>>> wrote it to stdout, I would regard it as an unfinished toy program.
>>
>> So gcc is an unfinished toy program?
> 
> gcc takes input from a series of command line parameters. Most output
> (except for options like -E) go to files. It may or may not use pipes
> internally to communicate with its assembler. Or it may use temporary
> files (on Windows), as it does with its linker.
> 
> Actually if I run it like this:
> 
>      gcc
> 
> then it says no input; it does not attempt to read stdin. Not even if I say:
> 
>      gcc <hello.c
> 
> So it doesn't fit the category I described. I don't know why you would
> think so.

$ cat x.c
#include <stdio.h>

int main(void)
{
   printf("hello\n");
}
$ cat x.c | gcc -o x -xc -
$ ./x
hello

-- 
Ian

[toc] | [prev] | [next] | [standalone]

#136373

On 07/10/2018 00:10, Ian Collins wrote:
> On 07/10/18 12:02, Bart wrote:
>> On 06/10/2018 23:55, Ian Collins wrote:
>>> On 07/10/18 10:27, Bart wrote:
>>
>>>> And if a simple console app such as a compiler took input from stdin 
>>>> and
>>>> wrote it to stdout, I would regard it as an unfinished toy program.
>>>
>>> So gcc is an unfinished toy program?
>>
>> gcc takes input from a series of command line parameters. Most output
>> (except for options like -E) go to files. It may or may not use pipes
>> internally to communicate with its assembler. Or it may use temporary
>> files (on Windows), as it does with its linker.
>>
>> Actually if I run it like this:
>>
>>      gcc
>>
>> then it says no input; it does not attempt to read stdin. Not even if 
>> I say:
>>
>>      gcc <hello.c
>>
>> So it doesn't fit the category I described. I don't know why you would
>> think so.
> 
> $ cat x.c
> #include <stdio.h>
> 
> int main(void)
> {
>    printf("hello\n");
> }
> $ cat x.c | gcc -o x -xc -
> $ ./x
> hello


But you had to specifically tell it to take input from standard input.

That doesn't make it what I had in mind which is a program that is 
designed to primarily take input from standard input.

More specifically, one of those that start, and then you wait for 
something to happen. Which it never does because it doesn't tell you 
it's waiting for you to type something.

And actually, I've just added a similar option to my C compiler to read 
from stdin. It's not hard, but it hardly turns it into an application 
that embraces pipes:

  C:\cx>cc dummy -stdin
  Reading from stdin. Finish with Ctrl-Z:
  #include <stdio.h>
  int main(void){puts("hi there");}
  ^Z

  C:\cx>ax dummy
  Assembling/linking dummy.asm... to dummy.exe

  C:\cx>dummy
  hi there

  C:\cx>

It needs a filename to specified (for its records, and to name the 
output), but it will not read from it.

It even seems to work with pipes:

  C:\cx>type hello.c
  #include <stdio.h>

  int main(void) {
      printf("Hello World! 01:30\n");
  }

  C:\cx>type hello.c | cc dummy -stdin
  Reading from stdin. Finish with Ctrl-Z:

  C:\cx>ax dummy
  Assembling/linking dummy.asm... to dummy.exe

  C:\cx>dummy
  Hello World! 01:30

  C:\cx>

As I said, when you need to do this stuff, you just do it. But primarily 
you will work from real files. Header files anyway have to come from a file.

-- 
bart

[toc] | [prev] | [next] | [standalone]

#136417

On Saturday, 6 October 2018 22:27:22 UTC+1, Bart  wrote:

> 'Its' input... I'm using to writing GUI apps don't have such simply 
> defined input. They did have command lines of their own, but if I needed 
> to control them from a script, that would be read from a file.

And I've worked in computing for 40 years without writing anything involving
GUIs. I don't assume that my experience means that others' experiences is
meaningless - why do you seem to do so?

[toc] | [prev] | [next] | [standalone]

#136421

On 08/10/2018 09:33, mark.bluemel@gmail.com wrote:
> On Saturday, 6 October 2018 22:27:22 UTC+1, Bart  wrote:
> 
>> 'Its' input... I'm using to writing GUI apps don't have such simply
>> defined input. They did have command lines of their own, but if I needed
>> to control them from a script, that would be read from a file.
> 
> And I've worked in computing for 40 years without writing anything involving
> GUIs. I don't assume that my experience means that others' experiences is
> meaningless - why do you seem to do so?
> 

Because it seems here that only those people's experience counts.

Programs /have/ to be written a certain way, because it suits how it's 
done in Linux and Unix, which do things the same way they were done in 
the 1970s.

Most people posting here use those OSes or similar ones.

I'm providing some balance. (At least for a little while longer before 
Linux-like systems take over the world. Apparently new OSes are not too 
difficult to write from scratch, so every new one is based on Linux.)

-- 
bart

[toc] | [prev] | [next] | [standalone]

#136364

Bart <bc@freeuk.com> writes:

> On 06/10/2018 15:51, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>>> I expect there is only one stdin per program. Functions such as this
>>> can be used multiple time and at ad hoc points in the code. Should
>>> they really hijack the stdin stream which another part of the program
>>> might be in the middle of reading?
>>
>> I have no idea what you mean here.
>
> There is just one global stdin resource per program? Does that allow
> only one EOF event, or can it be restarted? (I think Windows' "con"
> can be, because it's treated as an actual file that has to be opened).
>
> If there is just one stdin stream, and especially if it stops working
> as soon as EOF is encountered, it's hard to see how it be seriously
> considered as a likely general purpose file option.

One is enough.  If your implementation of awk reads it's data stream by
getting the size first, I can't pipe into it.

I don't know why you are so resistant to the idea that a function that
reads all the data from an FILE * should do so without having to know the
size first.

There is a secondary point, at least for Unix-like systems, that where
possible, programs should read and write data incrementally.  That's
because pipelines are so common in Unix.  But this is a separate issue
to whether the size needs to be know to read the whole stream.

> Also, if I wanted to use a function like readstrfile() in a C program,
> what filename do I give it to read from stdin?

That's a side issue.  I'd have read_str_file(FILE *) and a convenience
wrapper read_str_named_file(const char *).  Depending on the context, I
might have a convention whereby read_str_named_file("") means stdin.
Obviously there are many other possibilities for indicating stdin.

Linux has the very handy special file /dev/stdin.  This means one can
pipe to programs that have not been designed to support that.

> To me, stdin is what you might use to read interactively from the
> keyboard.

Oh!  OK.  To me it's whatever I want the program to see as its standard
input stream.

>>> Once stdin is finished [EOF detected] can it be used again in the same
>>> run as the program? It's just too undisciplined for me.
>>
>> I don't know where this comes from.  I'm talking about very ordinary
>> programs that read and process stream from start to finish, some of
>> which will need or want the whole input before doing anything with it
>> (like your reverse example).
>
> Yes, simple programs, like simple functions. I'm used (in the past
> anyway) to more elaborate applications that run for hours, reading
> scripts, commands, data etc from files, writing to files, listing
> files...

They might have been more flexible if they could take some or all of
that data from un-seekable streams.  But it's entirely possible that
your specific exposure to computing has meant that this has never been
an issue for you.

Small interconnected tools can be very handy, but you might be able to
do everything you want without them.

> Where would a crude stdin fit into that?

You don't give any specifics, but it can often be very handy for
commands to be supplied by other programs.

But if you only ever use programs that, for whatever reason, can't
benefit from streamed input, you won't have even seen this as a
problem.

> On Windows there's a function called _getc_nolock(). It's not in
> msvcrt.dll, but there is one in msvcr120.dll.
>
> (I had to use my C compiler as I didn't know how to link msvcr120.dll
> with gcc.

Does the library you use with gcc not provide getc_unlocked?

> With _getc_nolock(), my test data was read in 1.5 seconds instead of
> (now) 12.5 seconds with getc(). The docs do say that locks are used.

Ah.  So the vast majority of the time is taken up locking the FILE
object.  It's a reasonably costly operation on Linux, but nothing like
that.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#136357

On Saturday, October 6, 2018 at 5:51:50 PM UTC+3, Ben Bacarisse wrote:
> 
> Maybe the issue is with the way Windows shells connect tools together.
> If modern shells still fake pipes using files, then insisting that all
> inputs be seek-able (or stat-able) will not show up as an issue.  Maybe
> it is virtually impossible to give a Windows program a non-seekable
> input?  This would surprise me, because pipes give one a natural way to
> use multi-core processors.
> 

Out of curiosity I tested what type of object is used for pipe both on powershell and on cmd.exe. In both cases GetFileType() function returns FILE_TYPE_PIPE. Also in both cases GetFileInformationByHandleEx(FileNameInfo) fails. I get it as a hint that it is an anonymous pipe. 

[toc] | [prev] | [next] | [standalone]

#136359

On Saturday, October 6, 2018 at 10:52:40 PM UTC+3, already...@yahoo.com wrote:
> On Saturday, October 6, 2018 at 5:51:50 PM UTC+3, Ben Bacarisse wrote:
> > 
> > Maybe the issue is with the way Windows shells connect tools together.
> > If modern shells still fake pipes using files, then insisting that all
> > inputs be seek-able (or stat-able) will not show up as an issue.  Maybe
> > it is virtually impossible to give a Windows program a non-seekable
> > input?  This would surprise me, because pipes give one a natural way to
> > use multi-core processors.
> > 
> 
> Out of curiosity I tested what type of object is used for pipe both on powershell and on cmd.exe. In both cases GetFileType() function returns FILE_TYPE_PIPE. Also in both cases GetFileInformationByHandleEx(FileNameInfo) fails. I get it as a hint that it is an anonymous pipe.

Tried MSYS2 shell.
The result is confusing. GetFileType() returns FILE_TYPE_PIPE, but  GetFileInformationByHandleEx(FileNameInfo) succeeds and gives out a name that looks like temporary file.

[toc] | [prev] | [next] | [standalone]

#136365

already5chosen@yahoo.com writes:

> On Saturday, October 6, 2018 at 10:52:40 PM UTC+3, already...@yahoo.com wrote:
>> On Saturday, October 6, 2018 at 5:51:50 PM UTC+3, Ben Bacarisse wrote:
>> > 
>> > Maybe the issue is with the way Windows shells connect tools together.
>> > If modern shells still fake pipes using files, then insisting that all
>> > inputs be seek-able (or stat-able) will not show up as an issue.  Maybe
>> > it is virtually impossible to give a Windows program a non-seekable
>> > input?  This would surprise me, because pipes give one a natural way to
>> > use multi-core processors.
>> > 
>> 
>> Out of curiosity I tested what type of object is used for pipe both
>> on powershell and on cmd.exe. In both cases GetFileType() function
>> returns FILE_TYPE_PIPE. Also in both cases
>> GetFileInformationByHandleEx(FileNameInfo) fails. I get it as a hint
>> that it is an anonymous pipe.

Thanks for this.

The usual C trick is to do:

#include <stdio.h>

int main(int argc, char **argv)
{
     FILE *fp = argc > 1 ? fopen(argv[1], "rb") : stdin;
     printf("%s: ", fp == stdin ? "stdin" : argv[1]);
     if (fp) {
          long long sz;
          if (fseek(fp, 0, SEEK_END) == 0 && (sz = ftell(fp)) >= 0)
               printf("%lld bytes?\n", sz);
          else puts("can't seek to end.");
     }
     else puts("can't be opened.");
     if (fp && fp != stdin)
          fclose(fp);
}

It would be interesting, if you have access to a C compiler, to know
what various shells do with this program

> Tried MSYS2 shell.
> The result is confusing. GetFileType() returns FILE_TYPE_PIPE, but
> GetFileInformationByHandleEx(FileNameInfo) succeeds and gives out a
> name that looks like temporary file.

And presumably that file would be seekable.

-- 
Ben.

[toc] | [prev] | [next] | [standalone]

#136362

Bart <bc@freeuk.com> writes:
> On 06/10/2018 03:24, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>
>> I am surprised that you have not yet wanted to have "readstrfile" take
>> its date from stdin.  That's a common use in a lot of utilities.
>
> No, the usage pattern in a real program is different. I expect there is 
> only one stdin per program. Functions such as this can be used multiple 
> time and at ad hoc points in the code. Should they really hijack the 
> stdin stream which another part of the program might be in the middle of 
> reading?
>
> Once stdin is finished [EOF detected] can it be used again in the same 
> run as the program? It's just too undisciplined for me.
>
> If this was a real requirement, I can use (on Windows) 
> readstrfile("con"). This is not seekable so currently won't work, but it 
> would be trivial to detect that filename and switch to different 
> handling code:
>
>    if filename="con" then <fgetc loop> else <normal code> fi
>
> So it is not a big deal.

"con" is not at all the same thing as stdin.  It seems to correspond
roughly to "/dev/tty" on Unix/Linux.  It can't be redirected from a
file.

For example, on Windows
    type con < foo.txt
("type" is similar to the Unix "cat" program) doesn't read from foo.txt;
it waits for input from the keyboard.  "con" happens to be the default
source for stdin, but that's useless if you want to redirecct it.

-- 
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]

#138719

Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> Bart <bc@freeuk.com> writes:
> 
> > You, however, seem to like writing file-utilities with low-level file
> > functions (such as that fgetc which can be inefficient in Windows).
> 
> I would write wc with a byte at a time read loop because that's the
> natural way to do what wc does, and the OS I use most often does not get
> in the way of doing that.
> 
> But I don't particularly favour fgetc.  I favour writing utilities that
> can read streams.
> 
> Just how slow is fgetc?  In the days when I wrote C library code, it was
> a trivial function that advanced a pointer.  Every now and then, a block
> read was done.  That's many decades ago, and I know things have got more
> complicated, but the OS should not be hobbling C programmers like you
> describe.

man getc_unlocked

-- 
                              Waldek Hebisch

[toc] | [prev] | [next] | [standalone]

#136310

Ben Bacarisse:

> It's unfortunate that C does not a have a good mechanism
> to encapsulate this stream pattern.  In Haskell, and now
> in recent Python, open files can be viewed as sequences
> (I'm skipping some technical matter here) so anything that
> process a sequence can be applied to a stream.

Native support of such abstractions is beyond C's beautiful
simplicity.  Nothing, however, prevents the programmer from
implementing them in C via opaque types and function
pointers.

The type FILE itself is very abstract.  Can one write custom
drivers for FILE to let work with any desired storage?  I
have recently learned that FreePascal's type TEXT can be so
extended.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#136330

On Friday, October 5, 2018 at 9:09:14 PM UTC+1, Anton Shepelev wrote:
> Ben Bacarisse:
> 
> > It's unfortunate that C does not a have a good mechanism
> > to encapsulate this stream pattern.  In Haskell, and now
> > in recent Python, open files can be viewed as sequences
> > (I'm skipping some technical matter here) so anything that
> > process a sequence can be applied to a stream.
> 
> Native support of such abstractions is beyond C's beautiful
> simplicity.  Nothing, however, prevents the programmer from
> implementing them in C via opaque types and function
> pointers.
> 
> The type FILE itself is very abstract.  Can one write custom
> drivers for FILE to let work with any desired storage?  I
> have recently learned that FreePascal's type TEXT can be so
> extended.
> 
No you can't. This is one place where object-orientation would
be useful in C. The nearest you can get to it is tmpfile(), which
creates a temporary scratchfile, which on a decent implementation
will be in memory.

[toc] | [prev] | [next] | [standalone]

#136367

Malcolm McLean to Anton Shepelev:

> > The type FILE itself is very abstract.  Can one write
> > custom drivers for FILE to let work with any desired
> > storage?  I have recently learned that FreePascal's type
> > TEXT can be so extended.
>
> No you can't. This is one place where object-orientation
> would be useful in C. The nearest you can get to it is
> tmpfile(), which creates a temporary scratchfile, which on
> a decent implementation will be in memory.

OOP is unnecessary.  Below is FreePascal's definition of the
abstract TEXT type.  It has abstract data UserData and four
abstract functions (members of type codepointer):

const
{$ifdef CPUAVR}
  TextRecNameLength = 16;
  TextRecBufSize    = 16;
{$else CPUAVR}
  TextRecNameLength = 256;
  TextRecBufSize    = 256;
{$endif CPUAVR}
type
  TLineEndStr = string [3];
  TextBuf = array[0..TextRecBufSize-1] of ansichar;
  TTextBuf = TextBuf;

  { using packed makes the compiler to generate ugly code on some CPUs, further
    using packed causes the compiler to handle arrays of text wrongly, see  see tw0754 e.g. on arm  }
  TextRec = {$ifdef VER2_6} packed {$endif} Record
    Handle    : THandle;
    Mode      : longint;
    bufsize   : SizeInt;
    _private  : SizeInt;
    bufpos,
    bufend    : SizeInt;
    bufptr    : ^textbuf;
    openfunc,
    inoutfunc,
    flushfunc,
    closefunc : codepointer;
    UserData  : array[1..32] of byte;
    name      : array[0..textrecnamelength-1] of TFileTextRecChar;
    LineEnd   : TLineEndStr;
    buffer    : textbuf;
{$ifdef FPC_HAS_CPSTRING}
    CodePage  : TSystemCodePage;
{$endif}
  End;

A similar implementation is possible in C.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]

#136185

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On 10/3/2018 5:33 PM, Ben Bacarisse wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>>> I would also use a length determination for the
>>> file size rather than testing for something like EOF.  I did
>>> that here because of the OP's content.
>> 
>> They come thick and fast!  People learning C should know that it's
>> almost always better to simply read a stream until EOF is seen, just as
>> Jacob's code does.  Determining the file size is fiddly and in this
>> particular case, absolutely the wrong way to do it.  (If there *are* any
>> readers learning C, ask and I'll gladly explain why.)
>
>"fiddly," Ben?  Only if you're working with antiquated equipment
>that doesn't allow random access.

"Fiddly," RCH?   Given file A on a local disk, what is its size?

 - The amount of disk space consumed (e.g. the number of filesystem
   data blocks added to the file multiplied by the block size adjusted
   for the padding in the last block)?
 - The index to the final byte in the file (e.g. struct stat st_size?)

They're not the same for every disk file, and there are tools that care.

And of course, a file descriptor may refer to many things that aren't disk
resident files (for example, a line printer on parallel port (i.e. a character
special device),  or a network connection on a socket or system V stream).

[toc] | [prev] | [next] | [standalone]

#136197

On Thursday, October 4, 2018 at 9:22:48 AM UTC-4, Scott Lurndal wrote:
> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
> >On 10/3/2018 5:33 PM, Ben Bacarisse wrote:
> >"fiddly," Ben?  Only if you're working with antiquated equipment
> >that doesn't allow random access.
> 
> "Fiddly," RCH?   Given file A on a local disk, what is its size?

Unless I'm a friend of gparted, defrag.exe, or Windows Explorer,
I only care about the content.

>  - The amount of disk space consumed (e.g. the number of filesystem
>    data blocks added to the file multiplied by the block size adjusted
>    for the padding in the last block)?
>  - The index to the final byte in the file (e.g. struct stat st_size?)
> 
> They're not the same for every disk file, and there are tools that care.

You do know I'm developing an operating system, right?  I am
coding, from scratch, my own FAT16, FAT32, and JFS file systems?

> And of course, a file descriptor may refer to many things that aren't disk
> resident files (for example, a line printer on parallel port (i.e. a character
> special device),  or a network connection on a socket or system V stream).

Only on truly horrific systems ... and yes, I'm serious.

I can see the need for obtaining such information, accessing
such content, being able to easily write to such destinations,
but to present them as files ... I think that's a wrong design.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#136198

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>On Thursday, October 4, 2018 at 9:22:48 AM UTC-4, Scott Lurndal wrote:
>> "Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
>> >On 10/3/2018 5:33 PM, Ben Bacarisse wrote:
>> >"fiddly," Ben?  Only if you're working with antiquated equipment
>> >that doesn't allow random access.
>> 
>> "Fiddly," RCH?   Given file A on a local disk, what is its size?
>
>Unless I'm a friend of gparted, defrag.exe, or Windows Explorer,
>I only care about the content.

But, as it happens, nobody cares what _you_ care about.   What
a real, working programmer might care about is quite different.

>
>>  - The amount of disk space consumed (e.g. the number of filesystem
>>    data blocks added to the file multiplied by the block size adjusted
>>    for the padding in the last block)?
>>  - The index to the final byte in the file (e.g. struct stat st_size?)
>> 
>> They're not the same for every disk file, and there are tools that care.
>
>You do know I'm developing an operating system, right?  I am
>coding, from scratch, my own FAT16, FAT32, and JFS file systems?

No, I understand you claim to be doing so.  There's been no actual
evidence that you've ever written a complete, functional program
that would be of interest to anyone else, much less a usable operating
system.   FAT? really?  What a useless waste of time (and don't forget
to pay your royalties for it to MS).

And from your prior posting history, I have no doubt that you don't
understand what is actually required to write a modern operating system
that people would actually care to use (and I've written code for
four operating systems/hypervisors some of which have been widely used for
a quarter of a century - I understand the difficulties inherent
in developing and maintaining software for a large customer base).

Likewise your proposed processors.  You don't seem to be familiar with what's required
to design, verify and build a modern processor.   Hint: it's not a one-man job;
we have several hundred engineers between the architects, RTL designers,
Verification engineers, PD engineers (layout, place & route, netlist),
signal engineers (analog SERDES, SI), documentation writers, post-silicon testers,
firmware developers, driver developers, etc.  Then there is the require SG&A
and designing multilayer mainboards with acceptable signal integrity for said processors.

Sure, you can probably design, on paper, a 6502, but that's not particularly
useful anymore, nor is MS-DOS considered to be a real operating system.  OS/2
was closer, but unix was far superior especially in the day.

>
>> And of course, a file descriptor may refer to many things that aren't disk
>> resident files (for example, a line printer on parallel port (i.e. a character
>> special device),  or a network connection on a socket or system V stream).
>
>Only on truly horrific systems ... and yes, I'm serious.

As is well known, your opinions of things are far from the
mainstream and can clearly be considered irrelevent for all
intents and purposes.   You ignore or belittle things that don't fit into
your concept of reality (like your silly refusal to read AT&T style
intel assembler).

[toc] | [prev] | [next] | [standalone]

#136200

On Thursday, October 4, 2018 at 11:30:31 AM UTC-4, Scott Lurndal wrote:
> [snip]

I was wrong to reply to you, Scott.

Keep posting your hate toward me as you have been doing.
I'll say a prayer for you each time I come across it.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

#136202

On Thursday, October 4, 2018 at 4:00:38 PM UTC+1, Rick C. Hodgin wrote:
> 
> I can see the need for obtaining such information, accessing
> such content, being able to easily write to such destinations,
> but to present them as files ... I think that's a wrong design.
> 
Once I was given a colorimeter. I had to write a program, on MS Windows,
to read the colour it detected, then show that colour on a colourspace
map on screen.
Now it worked simply as a port. So you opened the port and read and
wrote the commands to make it work, in text, as to a file. That
meant that you didn't need special "device driver" software written in
assembly to use it.

[toc] | [prev] | [next] | [standalone]

#136211

On Thursday, October 4, 2018 at 12:27:56 PM UTC-4, Malcolm McLean wrote:
> On Thursday, October 4, 2018 at 4:00:38 PM UTC+1, Rick C. Hodgin wrote:
> > 
> > I can see the need for obtaining such information, accessing
> > such content, being able to easily write to such destinations,
> > but to present them as files ... I think that's a wrong design.
> > 
> Once I was given a colorimeter. I had to write a program, on MS Windows,
> to read the colour it detected, then show that colour on a colourspace
> map on screen.
> Now it worked simply as a port. So you opened the port and read and
> wrote the commands to make it work, in text, as to a file. That
> meant that you didn't need special "device driver" software written in
> assembly to use it.

That's fine.  Any app desiring it still has to know what port
to access.  In that knowing comes the ability to also use the
correct DLL and call a remote procedure which gathers the data
for you.

-- 
Rick C. Hodgin

[toc] | [prev] | [next] | [standalone]

Page 7 of 11 — ← Prev page 1 … 5 6 [7] 8 9 … 11  Next page →

Back to top | Article view | comp.lang.c

csiph-web