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 5 of 11 — ← Prev page 1 … 3 4 [5] 6 7 … 11  Next page →

#136700

Ike Naar wrote:
> On 2018-10-07, jacobnavia <jacob@jacob.remcomp.fr> wrote:

>> Let's assume that it is 1 in 100 000, 
>> i.e. I should happen to see one SOON.
>>
>> So, (in percentage) my little program should work for 99.99999% of the 
>> cases.
>>
>> And that is an estimation since NOBODY here (you included) has said that 
>> it has SEEN a file with an embedded \n. Since at least 10 people are 
>> following this thread, you have to add a 9 to that figure.
> 
> In your original post you added two nines to that figure.
> I'll re-quote it here:
> 
>>>> So, my program will work in 99.9999999% of the cases.

To complete nitpicking, inverting 1 in 100,000 only gives 99.999%.

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

#138716

jacobnavia <jacob@jacob.remcomp.fr> wrote:
> 
> And that is an estimation since NOBODY here (you included) has said that 
> it has SEEN a file with an embedded \n. Since at least 10 people are 
> following this thread, you have to add a 9 to that figure.

I have seen files with embedded \n.  One was long time ago,
when I showed students what they can put into file names.  For
reasons unknown to me one student decided to keep such file for
long time.   Several times I created such files by accident.
I would not object if the tools I used made creation of such
files harder.  OTOH I am glad that it was reasonably easy to
recover.

Converning made up percentages, long time ago I looked at
160 MB file containing e-mails.  At that time e-mail was
supposed to be 7-bit ASCII.  I checked and there was only
one byte code which did not appear in this file.  Can you
guess which code this was?  And looking at size you see
that at percentages you give _any_ byte code is likely
to appear, unless there is some _very_ strong mechanizm
that bans it.

-- 
                              Waldek Hebisch

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

#136041

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Unix has the "wc" utility to count the lines of a file. It is a pity 
> that under linux that program is unusable to count lines in a hierarchy 
> of several directories. It requires ZERO terminated file names, and the 
> "find" utility produces \n terminated file names, so it is unusable for 
> that.
>
> So, I decided to rewrite "wc" as "lc" (for Line Count")
>
> It took me a few hours, and I wanted to post the result here, since it 
> is (maybe) a useful program, and the way I wrote it explain some 
> opinions I have about software design.
>
> Here it is:
> -----------------------------------------------cut here
[snip code]

On lines 130 and 136 you use "%d" formats for an arguments of types
int32_t and int64_t.  (gcc warns about the latter on my system.)

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

#136060

On 02/10/2018 21:59, Keith Thompson wrote:
> jacobnavia <jacob@jacob.remcomp.fr> writes:
>> Unix has the "wc" utility to count the lines of a file. It is a pity
>> that under linux that program is unusable to count lines in a hierarchy
>> of several directories. It requires ZERO terminated file names, and the
>> "find" utility produces \n terminated file names, so it is unusable for
>> that.
>>
>> So, I decided to rewrite "wc" as "lc" (for Line Count")
>>
>> It took me a few hours, and I wanted to post the result here, since it
>> is (maybe) a useful program, and the way I wrote it explain some
>> opinions I have about software design.
>>
>> Here it is:
>> -----------------------------------------------cut here
> [snip code]
> 
> On lines 130 and 136 you use "%d" formats for an arguments of types
> int32_t and int64_t.  (gcc warns about the latter on my system.)


On DMC this makes the reported linecount appear as 0.

'bytes' needs to use %9lld" on line 130.

Also on 136, but I haven't seen a problem for that as I've only tested 
with one file so far.

(DMC is a 32-bit compiler, and such format mismatches can cause it to go 
wrong. On 64-bits, all arguments will take a 64-bit slot, even 32-bit ones.)

Another couple of things:

* I'm not sure of the difference between totalLines and lines (or 
totalBytes and bytes) as lines and bytes are not re-set to 0 for each 
new file. (Actually, this might make the totals wrong too for multiple 
files.)

* This is presumably intended for Linux, as filenames containing 
wildcards (such *.c) are not expanded to all the matching files.


(I've compiled also with gcc, but that is now used in a mode that 
generates so many warnings, that I ignore most of them. Which is a 
little counter-productive. Most C code I use it on is test code, and 
there /will/ be unused variables, or variables that are set but not used.)

-- 
bart

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

#136064

On 02/10/2018 23:07, Bart wrote:

> Another couple of things:
> 
> * I'm not sure of the difference between totalLines and lines (or 
> totalBytes and bytes) as lines and bytes are not re-set to 0 for each 
> new file. (Actually, this might make the totals wrong too for multiple 
> files.)

That's the right; those variables /are/ reset, but at the end of a loop 
rather than before the start.

-- 
bart

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

#136069

Bart <bc@freeuk.com> writes:
> On 02/10/2018 21:59, Keith Thompson wrote:
[...]
>> On lines 130 and 136 you use "%d" formats for an arguments of types
>> int32_t and int64_t.  (gcc warns about the latter on my system.)
>
> On DMC this makes the reported linecount appear as 0.
>
> 'bytes' needs to use %9lld" on line 130.

You can use "%9lld" *and* cast the argument to long long, or you can use
the appropriate macro from <inttypes.h>:
    printf("%s:%9lld | %8lld \n",PaddedFileName,(long long)bytes,(long long)lines);
or
    printf("%s:%9" PRId64 " | %8" PRId32 "\n",PaddedFileName,bytes,lines);
(Personally I prefer the first.)

> Also on 136, but I haven't seen a problem for that as I've only tested 
> with one file so far.
>
> (DMC is a 32-bit compiler, and such format mismatches can cause it to go 
> wrong. On 64-bits, all arguments will take a 64-bit slot, even 32-bit ones.)

And the behavior is still undefined if the format specifiers don't match.

[snip]

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

#136058

On 10/02/2018 04:37 PM, jacobnavia wrote:
>          c = fgetc(infile);
>          while (c != EOF) {
>              bytes++;
>              if (c == '\n')
>                  lines++;
>              c = fgetc(infile);
>          }

You can use this syntax and have one call:

          while ((c = fgetc(infile)) != EOF)
          {
              bytes++;
              if (c == '\n')
                  lines++;
          }

You might also want to check there for \r because not all
line endings are the same on each data file you'll parse.
If you do that, you'll need to move forward for the op-
posite condition (find \n, skip forward for every \r,
find \r, skip forward until you pass \n).

-- 
Rick C. Hodgin

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

#136076

Rick C. Hodgin:

>You might also want to check there for \r because not all
>line endings are the same on each data file you'll parse.
>If you do that, you'll need to move forward for the
>opposite condition (find \n, skip forward for every \r,
>find \r, skip forward until you pass \n).

Sounds too complicated.  Since only three line endings are
possible: \r, \n, and \r\n, the program can work thus:

  a.  upon encountering an \r, skip a possible following \n
      and singnal a new line,

  b.  unpon encountering an \n, signal a new line.

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

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

#136083

On 10/03/2018 04:57 AM, Anton Shepelev wrote:
...
> ... only three line endings are
> possible: \r, \n, and \r\n, ...


If you had said "commonplace" rather than "possible", I would have no
objection to that statement. However, are you in fact unaware that
several other ways of marking line endings can be used, and have been
used? See <https://en.wikipedia.org/wiki/Line_endings#Representation>
for some of the real-world alternatives that have been used.

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

#136099

James Kuyper to Anton Shepelev:

>>...only three line endings are possible: \r, \n, and \r\n,
>>...
>
>If you had said "commonplace" rather than "possible", I
>would have no objection to that statement.  However, are
>you in fact unaware that several other ways of marking line
>endings can be used, and have been used?  See
><https://en.wikipedia.org/wiki/Line_endings#Representation>
>for some of the real-world alternatives that have been
>used.

I truly was unaware of those rare EOL convenstions and did
not bother to check it before the post.  My fault.

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

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

#136093

On Wednesday, October 3, 2018 at 4:57:46 AM UTC-4, Anton Shepelev wrote:
> Rick C. Hodgin:
> 
> >You might also want to check there for \r because not all
> >line endings are the same on each data file you'll parse.
> >If you do that, you'll need to move forward for the
> >opposite condition (find \n, skip forward for every \r,
> >find \r, skip forward until you pass \n).
> 
> Sounds too complicated.  Since only three line endings are
> possible: \r, \n, and \r\n, the program can work thus:
> 
>   a.  upon encountering an \r, skip a possible following \n
>       and singnal a new line,
> 
>   b.  unpon encountering an \n, signal a new line.

I use this algorithm:

    1)  Encounter \n, skip any contiguous \r
    2)  Encounter \r, skip any contiguous \n

This accounts for:

    1)  \n
    2)  \r
    3)  \n\r
    4)  \r\n

I have seen all four of those line endings over the course of
the past 30+ years.  It takes a simple algorithm to skip past
them.  Something like (initialized here for brevity, untested):

    int cr_found   = 0;
    int lf_found   = 0;
    int crlf_found = 0;
    int lfcr_found = 0;

    // Iterate through the file
    while ((c = get_next_char())
    {
        ++line;
        if (c == 13)
        {
            ++cr_found;
            while ((c = get_next_char()) == 10) { ++crlf_found }

        } else if (c == 10) {
            ++lf_found;
            while ((c = get_next_char()) == 13) { ++lfcr_found }

        } else {
            --line;
        }
    }

    // Report on line ending
    if (   (cr_found != crlf_found && crlf_found != 0)
        || (lf_found != lfcr_found && lfcr_found != 0)
        || cr_found != lf_found)
    {
        printf("Line endings inconsistent.\n");
        // ... possibly ask if they want that corrected
    }

-- 
Rick C. Hodgin

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

#136096

On Wednesday, October 3, 2018 at 8:21:02 AM UTC-4, Rick C. Hodgin wrote:
> I have seen all four of those line endings over the course of
> the past 30+ years.  It takes a simple algorithm to skip past
> them.  Something like (initialized here for brevity, untested):
> 
>     int cr_found   = 0;
>     int lf_found   = 0;
>     int crlf_found = 0;
>     int lfcr_found = 0;
> 
>     // Iterate through the file
>     while ((c = get_next_char())
>     {
>         ++line;
>         if (c == 13)
>         {
>             ++cr_found;
>             while ((c = get_next_char()) == 10) { ++crlf_found }
> 
>         } else if (c == 10) {
>             ++lf_found;
>             while ((c = get_next_char()) == 13) { ++lfcr_found }
> 
>         } else {
>             --line;
>         }
>     }

Actually the above would be like this:

    int skip;

    // Iterate through the file
    for (c = get_next_char(); c != EOF; )
    {
        ++line;
        if (c == 13)
        {
            ++cr_found;
            if ((c = get_next_char() == 10))
            {
                ++crlf_found;
                skip = 0;

            } else {
                skip = 1;
            }

        } else if (c == 10) {
            ++lf_found;
            if ((c = get_next_char()) == 13)
            {
                ++lfcr_found;
                skip = 0;

            } else {
                skip = 1;
            }

        } else {
            --line;
            skip = 0;
        }

        if (skip == 0)
            c = get_next_char();

    }

Except I would write the above code in a C++ compiler and use
bool. :-)  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.

-- 
Rick C. Hodgin

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

#136103

On Wednesday, October 3, 2018 at 8:33:16 AM UTC-4, Rick C. Hodgin wrote:
> On Wednesday, October 3, 2018 at 8:21:02 AM UTC-4, Rick C. Hodgin wrote:
> > I have seen all four of those line endings over the course of
> > the past 30+ years.  It takes a simple algorithm to skip past
> > them.  Something like (initialized here for brevity, untested):

Here is the actual code I use.  I only use Windows, so I've
written a simple line-ending parsing algorithm, as each are
expected to be exactly two characters long:

    Line 344:
    http://www.libsf.org:8990/projects/LIB/repos/libsf/browse/source/vjr/source/sem/sem.cpp

That SEM code there is a nice little editor I wrote.  It has
syntax highlighting and is able to do a lot of common things.
It needs more development, but it's gotten to a point where
it works sufficiently, so I've been using it as is for now.

If you want to see it in use, download this:

    http://www.libsf.org/software/vjr_0.58.zip

Unzip, and then run one of the .BAT files for MSVC++ version,
or the GCC++ version, and either 32-bit or 64-bit.

To exit, click the 'X' or type "QUIT" on a blank line and
press Enter if it's the last line, or F6 if it's not.

To get rid of the hyper-text in the lower-right-hand window,
clone the repository, open the VS2015 project in the folder:
c:\libsf\source\vjr\projects\vs2015\vjr.sln, and then un-
comment the code on lines 2118-2119.

SEM stands for Sammy Edward Mitchell, the author of The
SemWare Editor, which used to be QEdit back in the DOS days.
His editor has an amazing macro language and I've used it
since that time.  I've also been given permission to repli-
cate that macro language inside of SEM, so all of my old
macros will work as they used to.  That part is not yet
coded.

    https://www.semware.com/html/tsepro44fl.php

It's customizable through the interface, and also through
a file of settings that can be baked in to the .EXE through
the SemWare Compiler.  It has programmatic hooks available
on most everything, and you can request a two-book printed
manual.  I highly recommend it.  And, I am unaffiliated with
it, save being a user and having received permission to use
the same language and syntax it has.  I receive no money
from the product.

-- 
Rick C. Hodgin

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

#136143

"Rick C. Hodgin" <rick.c.hodgin@gmail.com> writes:
<snip>
> Except I would write the above code in a C++ compiler and use
> bool. :-)

Or you could use a C compiler and use bool.  You may be joking, but
someone learning C might get the idea that C does not have a Boolean
type.  It has had one for very nearly two decades.

> 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.)

-- 
Ben.

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

#136145

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.

If you're writing a command-line utility, then you want to read
from a stream.  But if your app's purpose is to take input file-
names, and then parse them one-by-one, then you use a different
model.

The right tool, for the right job.

-- 
Rick C. Hodgin

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

#136161

"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.

Like network connections?  So last century.  Where is the random access
TCP API?  I want to start using it right away.

> If you're writing a command-line utility, then you want to read
> from a stream.

Er, that's what we are doing here, so you appear to be agreeing with me
now.  I said "in this particular case" which refers to the command-line
utility that Jacob is writing.  Mind you, I disagree that the issue is
whether the program is a command-line utility or not, but since this
program is one, I wonder what your position is now.

> But if your app's purpose is to take input file-
> names, and then parse them one-by-one, then you use a different
> model.

You can choose to design a program that reads a set of names that refer
to objects with sizes -- sizes that can be determined by some
random-access API.  That will, presumably, work for you.  And since you
appear to limit your work to Windows, I am unlikely to come across it so
I don't really have any reason to complain.

Unfortunately, there is more and more code being written for Unix
systems by people who have no fully grasped the value of making
inter-working general-purpose tools.  Please don't make it worse by
pushing the idea that all named readable objects are seekable (or
however it is you choose to determine the size).  It may be true on
Windows (though I doubt it) but it's not true everywhere.

> The right tool, for the right job.

Absolutely.  I want tools like wc to be able work with named pipes, for
example.  I don't want to have to special-case some uses.

-- 
Ben.

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

#136163

On 10/03/2018 09:49 PM, Ben Bacarisse wrote:
 > [snip]

You are argumentative in your reply, Ben.  I want no part
of your hateful, passive aggressive responses.

-- 
Rick C. Hodgin

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

#136168

In article <pp3sjm$jqj$1@dont-email.me>,
Rick C. Hodgin <rick.c.hodgin@gmail.com> wrote:
>On 10/03/2018 09:49 PM, Ben Bacarisse wrote:
> > [snip]
>
>You are argumentative in your reply, Ben.  I want no part
>of your hateful, passive aggressive responses.

Aw.  Another happy couple who just couldn't make it past the bumps in their
relationship.

-- 
The randomly chosen signature file that would have appeared here is more than 4
lines long.  As such, it violates one or more Usenet RFCs.  In order to remain
in compliance with said RFCs, the actual sig can be found at the following URL:
	http://user.xmission.com/~gazelle/Sigs/WeekendAwayFromHome

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

#136171

On Thursday, October 4, 2018 at 4:49:36 AM UTC+3, Ben Bacarisse wrote:
> "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.
> 
> Like network connections?  So last century. 

CIFS/SMB/SAMBA and NFS are last century? Technically, yes, they are. But they still are used very widely in this century, are not they?

> Where is the random access
> TCP API?  I want to start using it right away.
> 

Come on, wc program, coded in the way that you suggest wouldn't work over "plain" TCP socket anyway, because it wouldn't be able to connect or to accept connection.

> > If you're writing a command-line utility, then you want to read
> > from a stream.
> 
> Er, that's what we are doing here, so you appear to be agreeing with me
> now.  I said "in this particular case" which refers to the command-line
> utility that Jacob is writing.  Mind you, I disagree that the issue is
> whether the program is a command-line utility or not, but since this
> program is one, I wonder what your position is now.
> 
> > But if your app's purpose is to take input file-
> > names, and then parse them one-by-one, then you use a different
> > model.
> 
> You can choose to design a program that reads a set of names that refer
> to objects with sizes -- sizes that can be determined by some
> random-access API.

Do you consider POSIX stat() to be "random-access API" ?

> That will, presumably, work for you.  And since you
> appear to limit your work to Windows, I am unlikely to come across it so
> I don't really have any reason to complain.
> 
> Unfortunately, there is more and more code being written for Unix
> systems by people who have no fully grasped the value of making
> inter-working general-purpose tools.  

I tend to consider McIlroy's variant of Unix philosophy "last century".
IMHO, it causes way more troubles that it solves.
The larger part of it is because textual input and output of utilities is rarely specified with sufficient level of details.

> Please don't make it worse by
> pushing the idea that all named readable objects are seekable (or
> however it is you choose to determine the size).  It may be true on
> Windows (though I doubt it) but it's not true everywhere.
> 
> > The right tool, for the right job.
> 
> Absolutely.  I want tools like wc to be able work with named pipes, for
> example.  I don't want to have to special-case some uses.
> 

It's not obvious what user wants when wc is applied to named pipe.
May be, as you suggest, he wants wc to wait until producer closes his end of the pipe.
But it's equally possible that he wants to count characters/words/lines of current content of the pipe as it is at point of invocation.

> -- 
> Ben.

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

#136188

already5chosen@yahoo.com writes:

> On Thursday, October 4, 2018 at 4:49:36 AM UTC+3, Ben Bacarisse wrote:
>> "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.
>> 
>> Like network connections?  So last century. 
>
> CIFS/SMB/SAMBA and NFS are last century? Technically, yes, they
> are. But they still are used very widely in this century, are not
> they?

First, you do realise, I hope, that I was being sarcastic?  Rick was
gently mocking what he seems to think of as my fuddy-duddy antiquated
obsession with streams that are not seekable.  I was mocking that
characterisation in my reply.

Yes, NFS et. al. are widely used, but they fit Rick's view of modern (at
least no antiquated) equipment -- they support random-access seeking.  I
was referring to raw network streams.

>> Where is the random access
>> TCP API?  I want to start using it right away. 
>
> Come on, wc program, coded in the way that you suggest wouldn't work
> over "plain" TCP socket anyway, because it wouldn't be able to connect
> or to accept connection.

Unix has named pipes, and some Unixes (and variations like Plan 9) have
named TCP connections.  Linux lacks fattach (or at least my Ubuntu
kernel does) but that's an OS restriction.

>> > If you're writing a command-line utility, then you want to read
>> > from a stream.
>> 
>> Er, that's what we are doing here, so you appear to be agreeing with me
>> now.  I said "in this particular case" which refers to the command-line
>> utility that Jacob is writing.  Mind you, I disagree that the issue is
>> whether the program is a command-line utility or not, but since this
>> program is one, I wonder what your position is now.
>> 
>> > But if your app's purpose is to take input file-
>> > names, and then parse them one-by-one, then you use a different
>> > model.
>> 
>> You can choose to design a program that reads a set of names that refer
>> to objects with sizes -- sizes that can be determined by some
>> random-access API.
>
> Do you consider POSIX stat() to be "random-access API" ?

No, I don't.  Rick brought up random-access (by which he means seeking,
I think) and I did not want to complicate the discussion with other ways
in which the size of a subset of the things you might like to read can
be determined.

>> That will, presumably, work for you.  And since you
>> appear to limit your work to Windows, I am unlikely to come across it so
>> I don't really have any reason to complain.
>> 
>> Unfortunately, there is more and more code being written for Unix
>> systems by people who have no fully grasped the value of making
>> inter-working general-purpose tools.  
>
> I tend to consider McIlroy's variant of Unix philosophy "last century".
> IMHO, it causes way more troubles that it solves.

I agree.  The wide-spread adoption of Linux has frozen a lot of OS
design in the 70s and 80s.  That's not terrible, but I'd much rather see
a richer OS ecosystem.

> The larger part of it is because textual input and output of utilities
> is rarely specified with sufficient level of details.

Absolutely.  Plan 9 addressed this decades ago.  But that's a separate
issue.  Solving this problem would mean that stream become obsolete.  On
the contrary, I image they would become even more useful.

>> Please don't make it worse by
>> pushing the idea that all named readable objects are seekable (or
>> however it is you choose to determine the size).  It may be true on
>> Windows (though I doubt it) but it's not true everywhere.
>> 
>> > The right tool, for the right job.
>> 
>> Absolutely.  I want tools like wc to be able work with named pipes, for
>> example.  I don't want to have to special-case some uses. 
>
> It's not obvious what user wants when wc is applied to named pipe.
> May be, as you suggest, he wants wc to wait until producer closes his
> end of the pipe.  But it's equally possible that he wants to count
> characters/words/lines of current content of the pipe as it is at
> point of invocation.

That would special-case wc -c.  With all the other forms, wc needs to
read the stream to see the word and line boundaries.  If you supposed
usage were ever common, wc might acquire a -n flag that prevents reading
(and so imples -c) and which would instruct wc to use any other means
possible to determine the number of characters.  I would not remove the
stream-based reading behaviour though.

-- 
Ben.

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

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

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

csiph-web