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

#136250

On 2018-10-02, jacobnavia <jacob@jacob.remcomp.fr> wrote:
> The output is garbled. If I do
> wc *.c
>
> I get:
>
>      118     323    2540 alloc.c
>      924    3423   25951 analysis.c
> ...
>
> With your solution I get:
> 2526 6610 60865 /home/jacob/binut/binutils-2.27/gas/dw2gencfi.c
> 207 735 4683 /home/jacob/binut/binutils-2.27/gas/depend.c
> ...
> It is quite difficult to read, the formatting is gone.

Try
find . -type f -print0 | wc --files0=- | column -t

or something like
find . -type f -print0 | wc --files0=- | xargs -L1 printf "%6d%6d%6d  %s\n"

Bye, Andreas

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

#136040

On Tue, 02 Oct 2018 22:37:15 +0200, jacobnavia wrote:
> 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.

Since filenames on unix-like systems may contain newline characters,
writing programs which accept a list of filenames using newlines as
separators is fraught with peril.  That's why GNU wc (optionally)
takes filenames separated with 0 bytes: such bytes never appear in
filenames.  GNU find can produce such a list.  Both these features
are nonstandard, however; a portable method is to use the -exec
option to find.

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

#136042

Le 02/10/2018 à 22:56, Nick Bowler a écrit :

> Since filenames on unix-like systems may contain newline characters,
> writing programs which accept a list of filenames using newlines as
> separators is fraught with peril.  That's why GNU wc (optionally)
> takes filenames separated with 0 bytes: such bytes never appear in
> filenames.  GNU find can produce such a list.  Both these features
> are nonstandard, however; a portable method is to use the -exec
> option to find.
> 

sure, but that wasn't the topic, the topic was the C program I sent. But 
OK, C is off topic in this newsgroup.

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

#136047

On Tue, 02 Oct 2018 23:00:32 +0200, jacobnavia wrote:

> Le 02/10/2018 à 22:56, Nick Bowler a écrit :
> 
>> Since filenames on unix-like systems may contain newline characters,
>> writing programs which accept a list of filenames using newlines as
>> separators is fraught with peril.  That's why GNU wc (optionally)
>> takes filenames separated with 0 bytes: such bytes never appear in
>> filenames.  GNU find can produce such a list.  Both these features
>> are nonstandard, however; a portable method is to use the -exec
>> option to find.
>> 
> 
> sure, but that wasn't the topic, the topic was the C program I sent. But 
> OK, C is off topic in this newsgroup.

I am talking about your program.  You said your program was intended for
unix-like systems.  Your program accepts a list of filenames with newlines
as delimiters.  This is a bad design decision for the reason mentioned.

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

#136051

Le 02/10/2018 à 23:13, Nick Bowler a écrit :
> On Tue, 02 Oct 2018 23:00:32 +0200, jacobnavia wrote:
> 
>> Le 02/10/2018 à 22:56, Nick Bowler a écrit :
>>
>>> Since filenames on unix-like systems may contain newline characters,
>>> writing programs which accept a list of filenames using newlines as
>>> separators is fraught with peril.  That's why GNU wc (optionally)
>>> takes filenames separated with 0 bytes: such bytes never appear in
>>> filenames.  GNU find can produce such a list.  Both these features
>>> are nonstandard, however; a portable method is to use the -exec
>>> option to find.
>>>
>>
>> sure, but that wasn't the topic, the topic was the C program I sent. But
>> OK, C is off topic in this newsgroup.
> 
> I am talking about your program.  You said your program was intended for
> unix-like systems.  Your program accepts a list of filenames with newlines
> as delimiters.  This is a bad design decision for the reason mentioned.
> 

In that case it is OK.
I am using Unix since 25 maybe 30 years, I do not remember exactly. And 
I have never seen a file with a newline in its name.

So, my program will work in 99.9999999% of the cases.

I remember a text by Ritchie, where he spoke about the two approaches to 
software. The "MIT" approach that wanted to have 100% of the cases 
right, and his approach, where in some very rare cases the system just 
did not work as expected and returned "EAGAIN" , i.e. try again...

This is a case where a program will work for 100% of the files in my 
terabyte disk, but will fail for some files in some situations I have 
never (in 25 years!) seen.

And all the program I presented was like that.

For instance I malloced memory without ever freeing it, assuming the 
system will do it when the program exits.

Software that is not OVER ENGINEERED, like find, that accepts an obscure 
"print0" option, so that wc can also use it...

A print0 option that will be completely unknown to most users like me, 
that just use UNIX and do not want to fill their minds with computer trivia.

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

#136085

jacobnavia <jacob@jacob.remcomp.fr> wrote:

> In that case it is OK.
> I am using Unix since 25 maybe 30 years, I do not remember exactly. And 
> I have never seen a file with a newline in its name.
> 
> So, my program will work in 99.9999999% of the cases.

And malicious attacker will use one of these 10e-8% cases.

> I remember a text by Ritchie, where he spoke about the two approaches to 
> software.

Your approach should be:

1. Thank you, I didn't know about newlines, I'll change my program.
2. Thank you, I wasn't aware of -print0, I just learned something.

Arrogance won't get you far.

> The "MIT" approach that wanted to have 100% of the cases right, and his 
> approach, where in some very rare cases the system just did not work as 
> expected and returned "EAGAIN" , i.e. try again...

Returned an error, not misbehaved.

> For instance I malloced memory without ever freeing it, assuming the 
> system will do it when the program exits.

Unless someone takes your code, puts it into a function or a library and 
experiences non-obvious memory leaks.

> A print0 option that will be completely unknown to most users like me, 
> that just use UNIX and do not want to fill their minds with computer trivia.

Just read the manual for utilities you're deciding to use, it's not 
hidden.

-- 
https://www.youtube.com/watch?v=9lSzL1DqQn0

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

#136086

On 03/10/2018 11:48, Queequeg wrote:
> jacobnavia <jacob@jacob.remcomp.fr> wrote:
> 
>> In that case it is OK.
>> I am using Unix since 25 maybe 30 years, I do not remember exactly. And
>> I have never seen a file with a newline in its name.
>>
>> So, my program will work in 99.9999999% of the cases.
> 
> And malicious attacker will use one of these 10e-8% cases.
> 
>> I remember a text by Ritchie, where he spoke about the two approaches to
>> software.
> 
> Your approach should be:
> 
> 1. Thank you, I didn't know about newlines, I'll change my program.
> 2. Thank you, I wasn't aware of -print0, I just learned something.

My approach would be:

1. Fix the newline problem in Linux

That way you close a loophole so that it becomes impossible to exploit 
it, and your don't require thousands of applications to each code their 
way around it, or to support a 'feature' that few know about, and nobody 
uses.

I think if enough applications took the same attitude as this 
line-counting program, maybe they might have to do something about it.

Just pandering to such things is not going to do it.

-- 
bart

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

#136101

On 03/10/18 13:07, Bart wrote:
> On 03/10/2018 11:48, Queequeg wrote:
>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>
>>> In that case it is OK.
>>> I am using Unix since 25 maybe 30 years, I do not remember exactly. And
>>> I have never seen a file with a newline in its name.
>>>
>>> So, my program will work in 99.9999999% of the cases.
>>
>> And malicious attacker will use one of these 10e-8% cases.
>>
>>> I remember a text by Ritchie, where he spoke about the two approaches to
>>> software.
>>
>> Your approach should be:
>>
>> 1. Thank you, I didn't know about newlines, I'll change my program.
>> 2. Thank you, I wasn't aware of -print0, I just learned something.
> 
> My approach would be:
> 
> 1. Fix the newline problem in Linux
> 

1. There is no "newline problem" in Linux.

2. Newlines can be useful in filenames, from a user's viewpoint.  People
sometimes like to have long names with spaces, newlines, and other
things that look nice on their desktop.

3. Newlines (and carriage returns) are valid in Windows too, AFAIK.

4. The best way to handle these things is to have the minimum possible
assumptions, rather than to make multiple assumptions and hope you stay
ahead of new use-cases and security issues.  So assume that filenames
can have any character except a NULL character.  (In *nix, they can't
have a / character either.)  Get your filenames from the command line or
system calls, pass them out to system calls, and avoid any assumptions
in the middle.

5. The entire Linux world, its history and its installed base is not
going to change details of its valid file names to suit /your/ needs.

> That way you close a loophole so that it becomes impossible to exploit
> it, and your don't require thousands of applications to each code their
> way around it, or to support a 'feature' that few know about, and nobody
> uses.
> 
> I think if enough applications took the same attitude as this
> line-counting program, maybe they might have to do something about it.
> 
> Just pandering to such things is not going to do it.
> 

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

#136106

On 03/10/2018 13:49, David Brown wrote:
> On 03/10/18 13:07, Bart wrote:
>> On 03/10/2018 11:48, Queequeg wrote:
>>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>>
>>>> In that case it is OK.
>>>> I am using Unix since 25 maybe 30 years, I do not remember exactly. And
>>>> I have never seen a file with a newline in its name.
>>>>
>>>> So, my program will work in 99.9999999% of the cases.
>>>
>>> And malicious attacker will use one of these 10e-8% cases.
>>>
>>>> I remember a text by Ritchie, where he spoke about the two approaches to
>>>> software.
>>>
>>> Your approach should be:
>>>
>>> 1. Thank you, I didn't know about newlines, I'll change my program.
>>> 2. Thank you, I wasn't aware of -print0, I just learned something.
>>
>> My approach would be:
>>
>> 1. Fix the newline problem in Linux
>>
> 
> 1. There is no "newline problem" in Linux.
> 
> 2. Newlines can be useful in filenames, from a user's viewpoint.  People
> sometimes like to have long names with spaces, newlines, and other
> things that look nice on their desktop.

It doesn't seem to be a problem with Windows. File names can be made to 
flow like paragraphs if needed, with newlines inserted at word breaks.

I mean, I'd quite like to embedded a movie clip in my filename [which 
means a few hundred MB of binary data], or change my name by deed poll 
to include newlines, tabs, and leading spaces, but it's not going to happen.

We are talking about names, and names can reasonably be expected to have 
some restrictions.

Just having spaces is a big enough problem. But at least a space just 
about counts as printable character.

> 3. Newlines (and carriage returns) are valid in Windows too, AFAIK.

I don't think so. Creating a new file via fopen() will fail if the 
filename has an embedded newline character.

The same program works under Linux. Which also displays the newline as 
'?' so there doesn't seem much point. (A GUI will show the newline, but 
it will do that anyway when the name is too long and it needs to split it.)

IMO such things belong in the file itself. If the mere title of a file 
can have exactly the same content that you normally find in the file, 
then why bother with having actual files? Just have filenames!

> 4. The best way to handle these things is to have the minimum possible
> assumptions,

I think the best way is not to be pander to unreasonable or too 
open-ended specifications.

How long can a filename be? Could it conceivably exceed available RAM? 
If so, do you need to write a program so that it can deal with that 
possibility?

> 5. The entire Linux world, its history and its installed base is not
> going to change details of its valid file names to suit /your/ needs.

This is what comes from not speaking up.

(BTW, the file I created on Linux using the filename "abc\ndef" as 
written in the source. How do refer to that file on the Linux command 
line? Because:

    cat abc\ndef

Doesn't work. Nor does 'cat "abc\ndef"'. Nor does 'cat abc?def' when 
other files match that filespec.

And neither does:

    cat abc
    def

(Well, this tries to open "abc", which might work, then tries to run "def")

See why an actual newline is a bad idea here?)

-- 
bart

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

#136110

On 03/10/18 15:25, Bart wrote:
> On 03/10/2018 13:49, David Brown wrote:
>> On 03/10/18 13:07, Bart wrote:
>>> On 03/10/2018 11:48, Queequeg wrote:
>>>> jacobnavia <jacob@jacob.remcomp.fr> wrote:
>>>>
>>>>> In that case it is OK.
>>>>> I am using Unix since 25 maybe 30 years, I do not remember exactly.
>>>>> And
>>>>> I have never seen a file with a newline in its name.
>>>>>
>>>>> So, my program will work in 99.9999999% of the cases.
>>>>
>>>> And malicious attacker will use one of these 10e-8% cases.
>>>>
>>>>> I remember a text by Ritchie, where he spoke about the two
>>>>> approaches to
>>>>> software.
>>>>
>>>> Your approach should be:
>>>>
>>>> 1. Thank you, I didn't know about newlines, I'll change my program.
>>>> 2. Thank you, I wasn't aware of -print0, I just learned something.
>>>
>>> My approach would be:
>>>
>>> 1. Fix the newline problem in Linux
>>>
>>
>> 1. There is no "newline problem" in Linux.
>>
>> 2. Newlines can be useful in filenames, from a user's viewpoint.  People
>> sometimes like to have long names with spaces, newlines, and other
>> things that look nice on their desktop.
> 
> It doesn't seem to be a problem with Windows. File names can be made to
> flow like paragraphs if needed, with newlines inserted at word breaks.

There is no problem in Linux either.  You can put spaces in file names,
and a gui program or file manager can split the filename to fit the
space better.

It turns out that on Windows (Win7, anyway) you can't put line breaks in
filenames.  I don't know if that is a restriction of the filesystem (I
tested with NTFS) or the OS, or if you can get around it using the POSIX
interfaces.

> 
> I mean, I'd quite like to embedded a movie clip in my filename [which
> means a few hundred MB of binary data], or change my name by deed poll
> to include newlines, tabs, and leading spaces, but it's not going to
> happen.
> 

Don't you think that is a /little/ extreme?

> We are talking about names, and names can reasonably be expected to have
> some restrictions.

Why?  They should have as few restrictions as practically possible.  It
is precisely the lack of restrictions that meant pretty much everything
on *nix systems worked fine with UTF-8 even though the code was written
long before UTF-8 was invented.

> 
> Just having spaces is a big enough problem. But at least a space just
> about counts as printable character.

So do line breaks.

I am not arguing that it is a good idea to put line breaks, or even
spaces, in your filenames - it makes them more awkward to use from the
command line.  I am arguing that the OS should not add unnecessary
restrictions, and they certainly are not a "security feature" as has
been suggested.

> 
>> 3. Newlines (and carriage returns) are valid in Windows too, AFAIK.
> 
> I don't think so. Creating a new file via fopen() will fail if the
> filename has an embedded newline character.
> 

Yes, so it would appear (after I tested a little).


> The same program works under Linux. Which also displays the newline as
> '?' so there doesn't seem much point. (A GUI will show the newline, but
> it will do that anyway when the name is too long and it needs to split it.)

How the newline is displayed depends on the program doing the display.
Shells, guis, file managers are just programs in Linux - they are not
special or part of the system.

> 
> IMO such things belong in the file itself. If the mere title of a file
> can have exactly the same content that you normally find in the file,
> then why bother with having actual files? Just have filenames!
> 

I regularly have files with no content - 0 sized files can definitely be
useful.  I wouldn't use them for something that needed more than one
line, however.

>> 4. The best way to handle these things is to have the minimum possible
>> assumptions,
> 
> I think the best way is not to be pander to unreasonable or too
> open-ended specifications.
> 
> How long can a filename be? Could it conceivably exceed available RAM?
> If so, do you need to write a program so that it can deal with that
> possibility?

I have regularly had the "joys" of dealing with Windows programs that
put artificial limits on the size of filenames or paths.  It is /so/
much fun when a program creates folders so deeply nested or with such
long names that Windows explorer can't handle them, because the program
is written by the good folks that brought us "640 KB should be enough
for anyone".


> 
>> 5. The entire Linux world, its history and its installed base is not
>> going to change details of its valid file names to suit /your/ needs.
> 
> This is what comes from not speaking up.
> 

No, it comes from not inventing problems where there are no problems.

> (BTW, the file I created on Linux using the filename "abc\ndef" as
> written in the source. How do refer to that file on the Linux command
> line? Because:
> 
>    cat abc\ndef
> 
> Doesn't work. Nor does 'cat "abc\ndef"'. Nor does 'cat abc?def' when
> other files match that filespec.
> 
> And neither does:
> 
>    cat abc
>    def
> 
> (Well, this tries to open "abc", which might work, then tries to run "def")
> 
> See why an actual newline is a bad idea here?)
> 

cat 'abc
def'

should work in bash.  Also type "cat ", then use tab completion.  Other
shells may handle it differently.

Sure, such filenames are inconvenient - and they are rarely a good idea.
 But if I gave you a file called "skål" you would also have a lot of
trouble trying to type the name from the command line.  Does that mean I
should not be allowed to use Norwegian letters in my file names?

An OS is supposed to provide the capabilities - not to impose policies
about what is a good idea or not for any particular person or situation.

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

#136113

David Brown <david.brown@hesbynett.no> writes:
>On 03/10/18 15:25, Bart wrote:

>
>> (BTW, the file I created on Linux using the filename "abc\ndef" as
>> written in the source. How do refer to that file on the Linux command
>> line? Because:
>> 
>>    cat abc\ndef
>> 
>> Doesn't work. Nor does 'cat "abc\ndef"'. Nor does 'cat abc?def' when
>> other files match that filespec.
>> 
>> And neither does:
>> 
>>    cat abc
>>    def
>> 
>> (Well, this tries to open "abc", which might work, then tries to run "def")
>> 
>> See why an actual newline is a bad idea here?)
>> 
>
>cat 'abc
>def'


$ echo "Bart" > abc$'\n'def
$ cat abc$'\n'def          
Bart
$ ls abc$'\n'def 
abc?def
$ rm abc$'\n'def
$ ls abc$'\n'def
ls: cannot access abc
def: No such file or directory

will work with any posix compatible shell (ksh, bash, pdksh, mksh, et alia).

Wild cards also work.

$ echo "Fred" > abc$'\n'def
$ cat abc?def
Fred
$ rm abc?def 

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

#136116

On 03/10/2018 15:05, David Brown wrote:
> On 03/10/18 15:25, Bart wrote:

>> I mean, I'd quite like to embedded a movie clip in my filename [which

> Don't you think that is a /little/ extreme?

/I/ would. But I've learnt that many do like to push things to the 
limits, given the capability.

>> We are talking about names, and names can reasonably be expected to have
>> some restrictions.
> 
> Why?  They should have as few restrictions as practically possible.  It
> is precisely the lack of restrictions that meant pretty much everything
> on *nix systems worked fine with UTF-8 even though the code was written
> long before UTF-8 was invented.

Newlines in names require a newline. For most people, that means 
pressing the Enter key.

But they will already be familiar with the kind of entry box that allows 
just the one line of text, and the kind that allows multiple lines.

With the former, used for things like URLs, searches, filenames (on 
Windows at least), usernames, passwords etc etc, they will also know 
that pressing Enter means end-of-data, or Go.

Filename data intuitively belongs in the one-line box category.


(I've now looked again at the remarks about this program not allowing 
newlines in filenames, and it is no more than a quibble.

Filenames can be entered one by one on the command line (where newlines 
/can/ be entered, on Linux, using your method), or one by one with each 
name on its own line, from stdin.

For all I know, there may be a way of passing through a newline char 
from stdin, on Linux.

What would be the solution to that anyway; how would /you/ handle it?

Personally I'm with the OP; I don't care. This is a convenience utility 
with some limitations. I was even able to run it myself, and on Windows, 
whereas I would never have figured out the right incantations to do it 
with Linux commands.)


>>
>> Just having spaces is a big enough problem. But at least a space just
>> about counts as printable character.
> 
> So do line breaks.

Space in ASCII is code 32. Usually 32 onwards are printable (up to 126 
anyway), with space considered to have a blank glyph.

0 to 31 are control codes. Newlines usually involve codes 13 and 10.


>> How long can a filename be? Could it conceivably exceed available RAM?
>> If so, do you need to write a program so that it can deal with that
>> possibility?
> 
> I have regularly had the "joys" of dealing with Windows programs that
> put artificial limits on the size of filenames or paths.  It is /so/
> much fun when a program creates folders so deeply nested or with such
> long names that Windows explorer can't handle them, because the program
> is written by the good folks that brought us "640 KB should be enough
> for anyone".

I think the limit on a file-spec was 260 characters. Which I actually 
found very convenient; I'd allocate 300 for some margin, and be sure I 
had enough for any possible file-name.

Otherwise, the alternative could get rather complicated, in C, before 
you've even got around to doing anything with the file!

(I just don't use deeply nested directories; normally just one level, 
sometimes two. I find deeper nesting highly unfriendly. And I especially 
hate those with artificial levels that use "../../../".)

> Sure, such filenames are inconvenient - and they are rarely a good idea.
>   But if I gave you a file called "skål" you would also have a lot of
> trouble trying to type the name from the command line.

That one I was able to copy&paste (unsurprisingly, I didn't have any 
such file).

But Unicode is a different subject, and support for it needs to go 
deeper than just a mere application.

And Unicode text can still be typed into a one-line entry box.

-- 
bart

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

#136117

Bart <bc@freeuk.com> writes:
>On 03/10/2018 15:05, David Brown wrote:

>>> Just having spaces is a big enough problem. But at least a space just
>>> about counts as printable character.
>> 
>> So do line breaks.
>
>Space in ASCII is code 32. Usually 32 onwards are printable (up to 126 
>anyway), with space considered to have a blank glyph.
>
>0 to 31 are control codes. Newlines usually involve codes 13 and 10.

Technically, <space>, <tab> CR and LF are considered "white space" characters
(e.g. isspace(c) returns true for those characters).

isprint(c) returns false for CR, LF and <tab>.

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

#136184

On 03/10/18 17:53, Bart wrote:
> On 03/10/2018 15:05, David Brown wrote:
>> On 03/10/18 15:25, Bart wrote:
> 
>>> I mean, I'd quite like to embedded a movie clip in my filename [which
> 
>> Don't you think that is a /little/ extreme?
> 
> /I/ would. But I've learnt that many do like to push things to the
> limits, given the capability.

Show me someone who things embedding a movie clip in a filename is a
good idea, or agree that you are being absurd - which does /not/ help
your argument in any way.

> 
>>> We are talking about names, and names can reasonably be expected to have
>>> some restrictions.
>>
>> Why?  They should have as few restrictions as practically possible.  It
>> is precisely the lack of restrictions that meant pretty much everything
>> on *nix systems worked fine with UTF-8 even though the code was written
>> long before UTF-8 was invented.
> 
> Newlines in names require a newline. For most people, that means
> pressing the Enter key.
> 
> But they will already be familiar with the kind of entry box that allows
> just the one line of text, and the kind that allows multiple lines.
> 
> With the former, used for things like URLs, searches, filenames (on
> Windows at least), usernames, passwords etc etc, they will also know
> that pressing Enter means end-of-data, or Go.
> 
> Filename data intuitively belongs in the one-line box category.
> 

As I said, putting newlines in filenames is likely to be inconvenient.
But it is not up to the OS to decide that something is inconvenient, and
therefore should not be allowed.

This is the kind of mistake Windows makes.  MS has made arbitrary
decisions about what is and is not allowed in different circumstances,
with the result that it can have trouble with interactions with other
systems.  Their answer was then to allow more some things in some
circumstances, and not in others, leading to a general inconsistency.
Some examples include:

1. Windows makes no distinction between the cases for filenames - so you
can't have "hello.txt" and "Hello.txt" as different files.  Except that
you /can/ do so if you use the POSIX apis, leaving you with files that
you can create but can't access normally.  And because it allows UTF
filenames, and capitalisation is a complicated problem in UTF, you get
inconsistent and incorrect results.  (For example, in Turkish "i" and
"I" are completely different letters.  The capital of "i" is "İ", and
the small version of "I" is "ı".  In Norwegian, AA is sometimes the same
letter as Å, sometimes a different one.  You can't make a clear and
rigid set of rules for this kind of thing - by trying to do so, Windows
guarantees it will be wrong.)

2. You can create filenames and nested paths that are too long for
standard windows command line or explorer to handle, making them nearly
impossible to fix or delete.  (I have done this, by mistake.  The way to
solve the problem was to share the parent folder, access it from a Linux
system, and delete it from there.)

3. With a little effort, you can create filenames in Windows with
invalid characters.  A filename such as "*.*" is a joy to work with.


> 
> (I've now looked again at the remarks about this program not allowing
> newlines in filenames, and it is no more than a quibble.
> 
> Filenames can be entered one by one on the command line (where newlines
> /can/ be entered, on Linux, using your method), or one by one with each
> name on its own line, from stdin.
> 
> For all I know, there may be a way of passing through a newline char
> from stdin, on Linux.
> 
> What would be the solution to that anyway; how would /you/ handle it?

I wouldn't put newlines in the filename in the first place.  But I
wouldn't put arbitrary restrictions on these things - if someone wants
to make filenames with awkward characters, that is /their/ problem, not
mine.

> 
> Personally I'm with the OP; I don't care. This is a convenience utility
> with some limitations. I was even able to run it myself, and on Windows,
> whereas I would never have figured out the right incantations to do it
> with Linux commands.)
> 
> 
>>>
>>> Just having spaces is a big enough problem. But at least a space just
>>> about counts as printable character.
>>
>> So do line breaks.
> 
> Space in ASCII is code 32. Usually 32 onwards are printable (up to 126
> anyway), with space considered to have a blank glyph.
> 
> 0 to 31 are control codes. Newlines usually involve codes 13 and 10.
> 
> 
>>> How long can a filename be? Could it conceivably exceed available RAM?
>>> If so, do you need to write a program so that it can deal with that
>>> possibility?
>>
>> I have regularly had the "joys" of dealing with Windows programs that
>> put artificial limits on the size of filenames or paths.  It is /so/
>> much fun when a program creates folders so deeply nested or with such
>> long names that Windows explorer can't handle them, because the program
>> is written by the good folks that brought us "640 KB should be enough
>> for anyone".
> 
> I think the limit on a file-spec was 260 characters. Which I actually
> found very convenient; I'd allocate 300 for some margin, and be sure I
> had enough for any possible file-name.
> 
> Otherwise, the alternative could get rather complicated, in C, before
> you've even got around to doing anything with the file!
> 

C is a poor language for dealing with strings of any sort.  But we know
that - it is the language you use to write the run-time support for
languages that are good with strings.  No one sane would write a PC
line-count utility in C except if they want to show how to handle file
reading in C - it's a single line in Python.

> (I just don't use deeply nested directories; normally just one level,
> sometimes two. I find deeper nesting highly unfriendly. And I especially
> hate those with artificial levels that use "../../../".)
> 
>> Sure, such filenames are inconvenient - and they are rarely a good idea.
>>   But if I gave you a file called "skål" you would also have a lot of
>> trouble trying to type the name from the command line.
> 
> That one I was able to copy&paste (unsurprisingly, I didn't have any
> such file).
> 
> But Unicode is a different subject, and support for it needs to go
> deeper than just a mere application.
> 
> And Unicode text can still be typed into a one-line entry box.
> 

It is just another example of how some things are inconvenient in some
circumstances.

If you were using Python, writing the filename "skål" would be very
inconvenient for you without a Norwegian keyboard layout (and no
"compose" key on your Windows keyboard - *nix users can use compose-a-a
or compose-o-a).  On the other hand, an embedded newline is easy - just
use a file name like "split\nline".

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

#136118

Bart <bc@freeuk.com> writes:
> On 03/10/2018 13:49, David Brown wrote:
>> On 03/10/18 13:07, Bart wrote:
[...]
>>> My approach would be:
>>>
>>> 1. Fix the newline problem in Linux
>> 
>> 1. There is no "newline problem" in Linux.
>> 
>> 2. Newlines can be useful in filenames, from a user's viewpoint.  People
>> sometimes like to have long names with spaces, newlines, and other
>> things that look nice on their desktop.

I've never seen a newline *usefully* used in a file name.  Spaces, yes
(I personally dislike spaces in file names, but they're common in some
contexts) -- and if some user interface displays a file name by
splitting it on white space, that's probably ok.

[...]

> We are talking about names, and names can reasonably be expected to have 
> some restrictions.

But you can't reasonably expect anyone else to follow restrictions that
you think are reasonable.

> Just having spaces is a big enough problem. But at least a space just 
> about counts as printable character.
>
>> 3. Newlines (and carriage returns) are valid in Windows too, AFAIK.
>
> I don't think so. Creating a new file via fopen() will fail if the 
> filename has an embedded newline character.
>
> The same program works under Linux. Which also displays the newline as 
> '?' so there doesn't seem much point. (A GUI will show the newline, but 
> it will do that anyway when the name is too long and it needs to split it.)

More recent versions of the GNU utilities (including ls, find, etc.)
display newlines in an unambiguous from by default.  For example:

$ touch foo-bar foo_bar 'foo bar' $'foo\nbar' $'foo\rbar'
$ ls -l
total 0
-rw-r--r-- 1 kst kst 0 Oct  3 11:06 'foo'$'\n''bar'
-rw-r--r-- 1 kst kst 0 Oct  3 11:06 'foo'$'\r''bar'
-rw-r--r-- 1 kst kst 0 Oct  3 11:06 'foo bar'
-rw-r--r-- 1 kst kst 0 Oct  3 11:06  foo-bar
-rw-r--r-- 1 kst kst 0 Oct  3 11:06  foo_bar
$ ls --version
ls (GNU coreutils) 8.28

The $'\n' is based on bash's (poorly named) "ANSI-C Quoting".

In my limited experience with Windows, it imposes stricter limitations
on file names that Linux does.  (For example, I don't think it allows
':'.)

> IMO such things belong in the file itself. If the mere title of a file 
> can have exactly the same content that you normally find in the file, 
> then why bother with having actual files? Just have filenames!
>
>> 4. The best way to handle these things is to have the minimum possible
>> assumptions,
>
> I think the best way is not to be pander to unreasonable or too 
> open-ended specifications.

And who decides what's "reasonable"?

If I were making that decision, I'd ban spaces in file names.
Fortunately for some of the rest of you, I have no such authority.

> How long can a filename be? Could it conceivably exceed available RAM? 
> If so, do you need to write a program so that it can deal with that 
> possibility?

I believe Linux imposes limits.  They're quite large, and I don't
remember off the top of my head what they are.

>> 5. The entire Linux world, its history and its installed base is not
>> going to change details of its valid file names to suit /your/ needs.
>
> This is what comes from not speaking up.
>
> (BTW, the file I created on Linux using the filename "abc\ndef" as 
> written in the source. How do refer to that file on the Linux command 
> line? Because:
>
>     cat abc\ndef
>
> Doesn't work. Nor does 'cat "abc\ndef"'. Nor does 'cat abc?def' when 
> other files match that filespec.
>
> And neither does:
>
>     cat abc
>     def
>
> (Well, this tries to open "abc", which might work, then tries to run "def")

cat $'abc\ndef'

cat 'abc
def'

> See why an actual newline is a bad idea here?)

Other than David Brown (and I disagree with him), nobody has suggested
that using newlines in file names is a good idea.  In fact it's a
terrible idea.  But the fact is that Linux/Unix/POSIX permits any
characters in file names other than '\0' and '/'.

I often assume that file names don't contain special characters, when
I'm working with a directory tree of files that happen to meet that
restriction.  (That's if I'm working interactively; if I write a script
that's going to be run more than once I'm more careful.)  It's a bit
easier to type

    for file in $(find . -type f) ; do some_comand $file ; done

without having to worry about special characters.  But if I don't *know*
that there are no special characters, the OS I use provides tools that
let me deal with that -- and those tools deal just as easily with
newlines as with spaces.

    find . -type f -print0 | xargs -0 -l some_command

It might have been a good idea, however many decades ago, to impose a
restriction disallowing newlines in file names.  And probably '\r' as
well.  And '\b'.  Maybe disallow all non-printing characters?  But the
system was designed when 7-bit or 8-bit character sets where the norm.
Leaving things open allowed Linux/Unix/POSIX file systems to support
UTF-8 file names with no changes.

Can you tell us *exactly* what restrictions you would have imposed?

For relevance to C, the fopen() function takes a pointer to string as an
argument, described as the name of the file.  The standard says nothing
about how that name is interpreted or how it might be restricted (other
than the implicit restriction that, because it's a string, it can't
contain null characters).  Which is as it should be.

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

#136121

Le 03/10/2018 à 20:23, Keith Thompson a écrit :
> Other than David Brown (and I disagree with him), nobody has suggested
> that using newlines in file names is a good idea.  In fact it's a
> terrible idea.

Yes, so my little programm doesn't support it.

What I was trying to say with this discussion is that it is important to 
not OVER-ENGINEER software, keeping it simple, and maintainable.

For instance, the program presented has no memory management. It just 
allocates memory and if it can't get the memory it needs it prints an 
error message and exits.

Simple. And it will work with thousands of files and big inputs since 
today's machines allow us MB of RAM without any problems. I developed it 
in a computer with 64 bit CPU and 4GB RAM the size of a credit card.

Then, let's use that memory, and let's leave it to the OS to make the 
garbage collection, something it can do more efficiently than my little 
program.

And if you have a file with "\n" in its name the little programm WILL 
NOT WORK.

Period.

jacob

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

#136125

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 03/10/2018 à 20:23, Keith Thompson a écrit :
>> Other than David Brown (and I disagree with him), nobody has suggested
>> that using newlines in file names is a good idea.  In fact it's a
>> terrible idea.
>
> Yes, so my little programm doesn't support it.
>
> What I was trying to say with this discussion is that it is important to 
> not OVER-ENGINEER software, keeping it simple, and maintainable.
[...]

Is writing a C program to do something that the existing OS utilities
can already do not over-engineering?

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

#136129

Le 03/10/2018 à 21:03, Keith Thompson a écrit :
> Is writing a C program to do something that the existing OS utilities
> can already do not over-engineering?

No.

GNU is not unix.

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

#136131

On 04/10/18 08:45, jacobnavia wrote:
> Le 03/10/2018 à 21:13, Stefan Ram a écrit :
>> jacobnavia <jacob@jacob.remcomp.fr> writes:
>>> Unix has the "wc" utility to count the lines of a file. It is a pity
>>
>>     Recently, I read something in (IIRC) a book (or maybe it was
> Xref: uni-berlin.de comp.lang.c:1141266
> 
> Le 03/10/2018 à 21:03, Keith Thompson a écrit :
>> Is writing a C program to do something that the existing OS utilities
>> can already do not over-engineering?
> 
> No.
> 
> GNU is not unix.

?

# uname
SunOS
# man wc
WC(1)                            User Commands              WC(1)

NAME
        wc - display a count of lines, words and characters in a file

SunOS is not GNU...

-- 
Ian.

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

#136133

jacobnavia <jacob@jacob.remcomp.fr> writes:
> Le 03/10/2018 à 21:03, Keith Thompson a écrit :
>> Is writing a C program to do something that the existing OS utilities
>> can already do not over-engineering?
>
> No.
>
> GNU is not unix.

Your original statement in the article that started this thread was:

    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.

By "linux", I assumed you meant something like, say, Ubuntu or Fedora,
which uses a Linux kernel and GNU user space programs (like coreutils
and findutils).

If you have a UNIX-like system, perhaps with a Linux kernel,
that *doesn't* have GNU coreutils and findutils, then the problem
you describe could be real, and your program could be useful.
(But building GNU utilities for the system could also be a solution.)

I'll note that the busybox version of "wc" (commonly used on small
Linux-based systems) doesn't have the "--files0-from=F" option,
but busybox find does have "-print0" and busybox xargs has "-0".

    find . -type f -print0 | xargs -0 wc

does things that your program can't.

If you don't care about those things, that's fine.  I'm merely
pointing out that there are existing (and IMHO more flexible and
robust) solutions to the problem your program tries to solve.

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

Page 2 of 11 — ← Prev page 1 [2] 3 4 … 11  Next page →

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

csiph-web