Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #136032 > unrolled thread
| Started by | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| First post | 2018-10-02 22:37 +0200 |
| Last post | 2018-12-17 15:18 +0000 |
| Articles | 20 on this page of 211 — 33 participants |
Back to article view | Back to comp.lang.c
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 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-04 15:37 +0200 |
| Message-ID | <pp553c$jq$1@dont-email.me> |
| In reply to | #136125 |
On 03/10/18 21:03, Keith Thompson wrote:
> 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?
>
Yes.
And if you have to write such a program, then writing it in C is
over-engineering.
#!/usr/bin/python
import sys
if len(sys.argv) < 2 :
print "Usage: lc.py filename..."
sys.exit(1)
total = 0
for fn in sys.argv[1:] :
try :
linecount = len(file(fn).readlines())
print("File %s: %i" % (fn, linecount))
total += linecount
except :
# Can't open file
pass
print("Total: %i" % total)
That's 20 lines of Python, which works cross-platform, ignores non-file
filenames, handles *nix, Windows and Mac line endings, and is quite
comfortable with any filenames the system supports. It's about a
quarter of the speed of "wc -l". The heart of the program - counting
the number of lines in a file - is a single line.
(Of course, writing it in C is on-topic, and perhaps a fine exercise in
C programming. Writing it in Python is practical to solve the problem
at hand, but is too easy to be fun.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 15:06 +0100 |
| Message-ID | <Y7ptD.276588$Os.123224@fx35.am4> |
| In reply to | #136187 |
On 04/10/2018 14:37, David Brown wrote:
> #!/usr/bin/python
>
> import sys
>
> if len(sys.argv) < 2 :
> print "Usage: lc.py filename..."
> sys.exit(1)
>
> total = 0
> for fn in sys.argv[1:] :
> try :
> linecount = len(file(fn).readlines())
> print("File %s: %i" % (fn, linecount))
> total += linecount
> except :
> # Can't open file
> pass
>
> print("Total: %i" % total)
>
>
> That's 20 lines of Python, which works cross-platform, ignores non-file
> filenames, handles *nix, Windows and Mac line endings, and is quite
> comfortable with any filenames the system supports. It's about a
> quarter of the speed of "wc -l". The heart of the program - counting
> the number of lines in a file - is a single line.
>
> (Of course, writing it in C is on-topic, and perhaps a fine exercise in
> C programming. Writing it in Python is practical to solve the problem
> at hand, but is too easy to be fun.)
Well it helps that it's incomplete and doesn't fulfil the same spec as
the original:
(1) It doesn't display the [actual] number of bytes in the file
(2) It doesn't have the option of entering the list of files from stdin,
which is where the problem with newlines inside filenames rears its head
(3) The output is unaligned.
(4) Not in the spec, but you say it is cross-platform. However it relies
on the OS doing the 'file-globbing' I think is is called, where
filespecs such as "*.c" are expanded to all the matching files. That
might also look inside sub-directories, but don't have time to check.
That doesn't happen on Windows.
Perhaps this will make it a little more fun.
--
bart
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-04 21:48 +0200 |
| Message-ID | <pp5qpt$jtr$1@dont-email.me> |
| In reply to | #136190 |
On 04/10/18 16:06, Bart wrote: > On 04/10/2018 14:37, David Brown wrote: > <snip> > Well it helps that it's incomplete and doesn't fulfil the same spec as > the original: > > (1) It doesn't display the [actual] number of bytes in the file > > (2) It doesn't have the option of entering the list of files from stdin, > which is where the problem with newlines inside filenames rears its head > > (3) The output is unaligned. > None of these is any problem to change. Maybe you'd have 25 lines instead of 20 - the point still stands. But this is not a Python group so I will not bother changing that kind of thing here. > (4) Not in the spec, but you say it is cross-platform. However it relies > on the OS doing the 'file-globbing' I think is is called, where > filespecs such as "*.c" are expanded to all the matching files. No, the OS does no such thing. In the *nix world, the /shell/ expands wild-cards. Not the OS, and not the program. If you need wild-card expansion in Windows, you can use the "glob" module. None of this is hard in Python - it is a tiny, tiny fraction of the effort needed to do it in C. And it will work without buffer overflows, memory leaks, or similar bugs. (That does not mean you can't have bugs in your Python code - you just don't have /those/ bugs.) > That > might also look inside sub-directories, but don't have time to check. > That doesn't happen on Windows. > > Perhaps this will make it a little more fun. >
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-04 15:28 +0200 |
| Message-ID | <pp54ho$sip$1@dont-email.me> |
| In reply to | #136118 |
On 03/10/18 20:23, Keith Thompson wrote: > > 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 /don't/ think it is a good idea, and have not suggested that. What I think is a good idea is for the OS (kernel, filesystem, key libraries, etc.) to have as few restrictions and rules as feasible. I think newlines should be allowed in filenames not because I want to put newlines in filenames, but because I don't want a special rule added to stop them.
[toc] | [prev] | [next] | [standalone]
| From | gazelle@shell.xmission.com (Kenny McCormack) |
|---|---|
| Date | 2018-10-04 14:16 +0000 |
| Message-ID | <pp57cf$j4a$1@news.xmission.com> |
| In reply to | #136186 |
In article <pp54ho$sip$1@dont-email.me>, David Brown <david.brown@hesbynett.no> wrote: >On 03/10/18 20:23, Keith Thompson wrote: > >> >> 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 /don't/ think it is a good idea, and have not suggested that. Yes, you have. Keith is, as always, right on this point. No, I'm not going to go quote mining, but you did explicitly state that it is a desirable feature. I understand completely, of course, your desire to now walk that back to "No, I only said that well-written utilities must allow for it". No, I don't intend to argue this any further. -- Modern Christian: Someone who can take time out from using Leviticus to defend homophobia and Exodus to plaster the Ten Commandments on every school and courthouse to claim that the Old Testament is merely "ancient laws" that "only applies to Jews".
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-04 11:09 -0700 |
| Message-ID | <lnd0sp4m9p.fsf@kst-u.example.com> |
| In reply to | #136186 |
David Brown <david.brown@hesbynett.no> writes:
> On 03/10/18 20:23, Keith Thompson wrote:
>> 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 /don't/ think it is a good idea, and have not suggested that.
Upthread, you wrote:
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.
Did you mean *displaying* file names with newlines rather than
having actual newline characters in the file names? (Though I've
rarely seen that done.)
> What I think is a good idea is for the OS (kernel, filesystem, key
> libraries, etc.) to have as few restrictions and rules as feasible. I
> think newlines should be allowed in filenames not because I want to put
> newlines in filenames, but because I don't want a special rule added to
> stop them.
Agreed. If you try to impose restrictions, there are going to be ways
to get around them, and when that happens tools that make assumptions
are going to break in arbitrarily bad ways. (Somebody recently
described what happens when you create files on Windows with funny
names.)
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-04 22:00 +0200 |
| Message-ID | <pp5rh7$olh$1@dont-email.me> |
| In reply to | #136212 |
On 04/10/18 20:09, Keith Thompson wrote: > David Brown <david.brown@hesbynett.no> writes: >> On 03/10/18 20:23, Keith Thompson wrote: >>> 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 /don't/ think it is a good idea, and have not suggested that. > > Upthread, you wrote: > > 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. > > Did you mean *displaying* file names with newlines rather than > having actual newline characters in the file names? (Though I've > rarely seen that done.) I was talking more generally - people making files in a gui desktop are more inclined to have filenames that they think look nice or are more descriptive, even if they are longer and contain spaces or odd characters. People making or using filenames from a command line will typically keep them short and dislike any awkward character. I have never thought is was a good idea to have newlines in filenames, but what I wrote suggested that I thought other people used them or thought it was a good idea. It is not /very/ difficult to make filenames with newlines in a file manager in Linux - but it is inconvenient enough that it is unlikely people would do it. It is certainly more inconvenient that I thought before testing it, after I'd made that comment. So it is probably unlikely that anyone thinks they are useful, except perhaps to make filenames that Windows doesn't like in order to annoy Windows users. > >> What I think is a good idea is for the OS (kernel, filesystem, key >> libraries, etc.) to have as few restrictions and rules as feasible. I >> think newlines should be allowed in filenames not because I want to put >> newlines in filenames, but because I don't want a special rule added to >> stop them. > > Agreed. If you try to impose restrictions, there are going to be ways > to get around them, and when that happens tools that make assumptions > are going to break in arbitrarily bad ways. (Somebody recently > described what happens when you create files on Windows with funny > names.) > I certainly described a few cases of trouble I have seen on Windows systems with funny names. Maybe someone else did too.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 21:18 +0100 |
| Message-ID | <jAutD.359617$Sv.87020@fx43.am4> |
| In reply to | #136220 |
On 04/10/2018 21:00, David Brown wrote: > On 04/10/18 20:09, Keith Thompson wrote: >> Did you mean *displaying* file names with newlines rather than >> having actual newline characters in the file names? (Though I've >> rarely seen that done.) > > I was talking more generally - people making files in a gui desktop are > more inclined to have filenames that they think look nice or are more > descriptive, even if they are longer and contain spaces or odd > characters. People making or using filenames from a command line will > typically keep them short and dislike any awkward character. > > I have never thought is was a good idea to have newlines in filenames, > but what I wrote suggested that I thought other people used them or > thought it was a good idea. It is not /very/ difficult to make > filenames with newlines in a file manager in Linux - but it is > inconvenient enough that it is unlikely people would do it. It makes some things more difficult. For the example, the ostensibly simple task of storing a list of filenames in a file. Similar to the challenge in the OP's program to read a list of filenames from stdin. If you take the simple approach of having one per line, how do you represent a name with an embedded newline? You can't enclose it in quotes, or separate them with commas, as those are also allowed characters of a filename. You might try using \n, except that \ can be part of a filename too! You end up typing yourself in knots trying to do it. If you do end with some scheme of escape codes, then it means you can't just a plain text file that can be simply printed out, or used anywhere else. -- bart
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-04 20:28 +0000 |
| Message-ID | <0KutD.184816$Ac3.365@fx45.iad> |
| In reply to | #136222 |
Bart <bc@freeuk.com> writes: >On 04/10/2018 21:00, David Brown wrote: > >It makes some things more difficult. For the example, the ostensibly >simple task of storing a list of filenames in a file. Similar to the >challenge in the OP's program to read a list of filenames from stdin. > >If you take the simple approach of having one per line, how do you >represent a name with an embedded newline? Quoted printable (=10), HTML entity (
), C escape sequences (\n), there are a surfeit of mechanisms available.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-04 21:59 +0100 |
| Message-ID | <NavtD.472767$Fr5.297974@fx41.am4> |
| In reply to | #136225 |
On 04/10/2018 21:28, Scott Lurndal wrote: > Bart <bc@freeuk.com> writes: >> On 04/10/2018 21:00, David Brown wrote: > >> >> It makes some things more difficult. For the example, the ostensibly >> simple task of storing a list of filenames in a file. Similar to the >> challenge in the OP's program to read a list of filenames from stdin. >> >> If you take the simple approach of having one per line, how do you >> represent a name with an embedded newline? > > Quoted printable (=10), HTML entity (
), C escape sequences (\n), there are a surfeit > of mechanisms available. None of these work (as embedded escapes within plain text), because Unix filenames can be pretty much /any/ character, including all of those. (I've just created a file called 
=10\n.) Also it will no longer be a universal text file, but one that uses a specific escape mechanism. For it to work, the entire filename must be part of the scheme. (Although I don't think every file name need be.) But suppose the format chosen was that of the C string constants. Now a list of such names might be: one two "three\nfour" And program to read a list of such names is not longer that simple. But suppose now you wanted the contents of that file as the name of another file, complete with actual newlines, and the existing escapes (line3 is used literally). That filename in a file will now look like this: "one\ntwo\n\"three\\nfour\"\n" (not sure about that final \n). Now that filename reader will have its work cut out. It will be easier to read the contents of the file, than its name! Making filenames so 'flexible' was an incredibly bad idea. -- bart
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-04 21:10 +0000 |
| Message-ID | <2lvtD.83166$SG2.18714@fx29.iad> |
| In reply to | #136228 |
Bart <bc@freeuk.com> writes: >On 04/10/2018 21:28, Scott Lurndal wrote: >> Bart <bc@freeuk.com> writes: >>> On 04/10/2018 21:00, David Brown wrote: >> >>> >>> It makes some things more difficult. For the example, the ostensibly >>> simple task of storing a list of filenames in a file. Similar to the >>> challenge in the OP's program to read a list of filenames from stdin. >>> >>> If you take the simple approach of having one per line, how do you >>> represent a name with an embedded newline? >> >> Quoted printable (=10), HTML entity (
), C escape sequences (\n), there are a surfeit >> of mechanisms available. > >None of these work (as embedded escapes within plain text), because Unix >filenames can be pretty much /any/ character, including all of those. >(I've just created a file called 
=10\n.) You asked how to store them in a file.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2018-10-04 15:53 -0700 |
| Message-ID | <lnva6h2ujd.fsf@kst-u.example.com> |
| In reply to | #136222 |
Bart <bc@freeuk.com> writes:
> On 04/10/2018 21:00, David Brown wrote:
[...]
>> I have never thought is was a good idea to have newlines in filenames,
>> but what I wrote suggested that I thought other people used them or
>> thought it was a good idea. It is not /very/ difficult to make
>> filenames with newlines in a file manager in Linux - but it is
>> inconvenient enough that it is unlikely people would do it.
>
> It makes some things more difficult.
Yes.
> For the example, the ostensibly
> simple task of storing a list of filenames in a file. Similar to the
> challenge in the OP's program to read a list of filenames from stdin.
>
> If you take the simple approach of having one per line, how do you
> represent a name with an embedded newline?
You don't -- so either don't store them that way, or take care that you
don't have any files whose names contain newlines, or acknowledge that
your format will fail if any files have names containing newlines.
But it's essentially a solved problem. The existing tools on most
Linux-based systems are capable of handling file names with newlines
(or any other arbitrary characters) with just a little extra effort,
using nul-delimited names as supported by find, xargs, wc, and
probably other tools as well.
But by all means feel free not to use them.
[...]
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2018-10-05 00:09 +0100 |
| Message-ID | <N4xtD.627579$2r.153140@fx33.am4> |
| In reply to | #136234 |
On 04/10/2018 23:53, Keith Thompson wrote: > Bart <bc@freeuk.com> writes: >> On 04/10/2018 21:00, David Brown wrote: > [...] >>> I have never thought is was a good idea to have newlines in filenames, >>> but what I wrote suggested that I thought other people used them or >>> thought it was a good idea. It is not /very/ difficult to make >>> filenames with newlines in a file manager in Linux - but it is >>> inconvenient enough that it is unlikely people would do it. >> >> It makes some things more difficult. > > Yes. > >> For the example, the ostensibly >> simple task of storing a list of filenames in a file. Similar to the >> challenge in the OP's program to read a list of filenames from stdin. >> >> If you take the simple approach of having one per line, how do you >> represent a name with an embedded newline? > > You don't -- so either don't store them that way, or take care that you > don't have any files whose names contain newlines, or acknowledge that > your format will fail if any files have names containing newlines. > > But it's essentially a solved problem. The existing tools on most > Linux-based systems are capable of handling file names with newlines > (or any other arbitrary characters) with just a little extra effort, > using nul-delimited names as supported by find, xargs, wc, and > probably other tools as well. That doesn't help. The OP posted code that didn't support such filenames, and somebody pointed it out. Someone else said it might be a security risk. So it will attract attention (and people here love to have a go). So (1) all those utilities have had the extra headache of solving it; (2) every other program that has to deal with filenames, also has to solve it, and in perpetuity. Even if a program gets the right filename contained within a string, how do you even print it out? It will screw up any kind of formatting. And you need to know how to record such filenames (say within a configuration file). It's a can of worms. Here's how to print a Windows filename: puts(file); What would that code look like with embedded newlines; how do you even represent them? What would have been the consequences of not allowing char 10 in a filename, or any codes from 1 to 31? Probably none at all. -- bart
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-05 02:06 +0100 |
| Message-ID | <87ftxlnqw6.fsf@bsb.me.uk> |
| In reply to | #136234 |
Keith Thompson <kst-u@mib.org> writes: > ... The existing tools on most > Linux-based systems are capable of handling file names with newlines > (or any other arbitrary characters) with just a little extra effort, > using nul-delimited names as supported by find, xargs, wc, and > probably other tools as well. Yes, sort, sed, awk and perl come to mind. All very handy for those "must not fail" situations. Unfortunately there is no universally agreed command-line flag for this (and for awk I think you have to set RS="\0" in the BEGIN block). -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-04 22:40 +0200 |
| Message-ID | <pp5ts3$61v$1@dont-email.me> |
| In reply to | #136220 |
The POSIX standard POSIX.1-2008 disallows all funny characters from file names. Bart is right. <quote> For a filename to be portable across implementations conforming to POSIX.1-2008, it shall consist only of the portable filename character set as defined in Portable Filename Character Set. Portable filenames shall not have the <hyphen> character as the first character since this may cause problems when filenames are passed as command line arguments. <end quote> The "Portable Filename Character Set", defined in 3.276 (“Portable Filename Character Set”); this turns out to be just A-Z, a-z, 0-9, <period>, <underscore>, and <hyphen> (aka the dash character). Is that clear?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2018-10-04 21:13 +0000 |
| Message-ID | <2ovtD.83167$SG2.65513@fx29.iad> |
| In reply to | #136226 |
jacobnavia <jacob@jacob.remcomp.fr> writes: >The POSIX standard POSIX.1-2008 disallows all funny characters from >file names. Bart is right. > ><quote> >For a filename to be portable across implementations conforming to >POSIX.1-2008, it shall consist only of the portable filename character >set as defined in Portable Filename Character Set. Portable filenames >shall not have the <hyphen> character as the first character since this >may cause problems when filenames are passed as command line arguments. ><end quote> > >The "Portable Filename Character Set", defined in 3.276 (“Portable >Filename Character Set”); this turns out to be just A-Z, a-z, 0-9, ><period>, <underscore>, and <hyphen> (aka the dash character). > >Is that clear? > You misunderstand the standard document. That portion of POSIX places _NO_ restrictions on the implementation. A POSIX compliant _IMPLEMENTATION_ is free to support any byte value in a filename (other than nul and forward slash). Users of POSIX (you, for example) must restrict the set of characters that they use if, and only if, they care about portability to a dissimilar implementation of the POSIX standard.
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2018-10-04 23:09 +0100 |
| Message-ID | <87r2h5nz38.fsf@bsb.me.uk> |
| In reply to | #136226 |
jacobnavia <jacob@jacob.remcomp.fr> writes: > The POSIX standard POSIX.1-2008 disallows all funny characters from > file names. No it does not. It's clear from the part that you quote that (a) you understand how to read the standard, and (b) what the parts you quote really mean. I want to find a way to avoid saying that you are lying, but I am having a hard time. Maybe you don't know the force of the word "disallows" in English? POSIX has this to say about filenames: Filename Filenames are sequences of bytes, not sequences of characters. The only bytes that this standard says cannot appear in any filename are the slash byte and the null byte. > Bart is right. About what? > <quote> > .For a filename to be portable across implementations conforming to > POSIX.1-2008, it shall consist only of the portable filename character > set as defined in Portable Filename Character Set. Portable filenames > shall not have the <hyphen> character as the first character since > this may cause problems when filenames are passed as command line > arguments. <end quote> > > The "Portable Filename Character Set", defined in 3.276 (“Portable > Filename Character Set”); this turns out to be just A-Z, a-z, 0-9, > <period>, <underscore>, and <hyphen> (aka the dash character). > > Is that clear? Yes it is. That's why I am having trouble taking this post as good-faith one expressing a view that is simply erroneous. -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-05 07:47 +0200 |
| Message-ID | <pp6tsn$q3o$2@dont-email.me> |
| In reply to | #136233 |
Le 05/10/2018 à 00:09, Ben Bacarisse a écrit : > jacobnavia <jacob@jacob.remcomp.fr> writes: > >> The POSIX standard POSIX.1-2008 disallows all funny characters from >> file names. > > No it does not. It's clear from the part that you quote that (a) you > understand how to read the standard, and (b) what the parts you quote > really mean. I want to find a way to avoid saying that you are lying, > but I am having a hard time. Maybe you don't know the force of the word > "disallows" in English? > It says very clearly that the special characters make a file name NOT PORTABLE and hence not supported by all implementations! > POSIX has this to say about filenames: > > Filename > > Filenames are sequences of bytes, not sequences of characters. The > only bytes that this standard says cannot appear in any filename are > the slash byte and the null byte. > Yes, you can make any unportable file names and if you are lucky they will be accepted. For a lengthy (but interesting) discussion see: https://dwheeler.com/essays/fixing-unix-linux-filenames.html where Mr wheeeler argues in the same vein as Bart... >> Bart is right. > > About what? > About the nonsense of allowing any characters in a file name. That's the subtopic we are discussing now isn't it? >> <quote> >> .For a filename to be portable across implementations conforming to >> POSIX.1-2008, it shall consist only of the portable filename character >> set as defined in Portable Filename Character Set. Portable filenames >> shall not have the <hyphen> character as the first character since >> this may cause problems when filenames are passed as command line >> arguments. <end quote> >> >> The "Portable Filename Character Set", defined in 3.276 (“Portable >> Filename Character Set”); this turns out to be just A-Z, a-z, 0-9, >> <period>, <underscore>, and <hyphen> (aka the dash character). >> >> Is that clear? > > Yes it is. That's why I am having trouble taking this post as > good-faith one expressing a view that is simply erroneous. > Special characters in file names ARE NOT PORTABLE and should be banned. Could we gree with that?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2018-10-05 09:44 +0200 |
| Message-ID | <pp74pm$cs$1@dont-email.me> |
| In reply to | #136241 |
On 05/10/18 07:47, jacobnavia wrote: > > Special characters in file names ARE NOT PORTABLE and should be banned. > Could we gree with that? Of course we could not agree on that. We can agree that anything outside of A-Z, a-z, 0-9, period, underscore and hyphen will limit the guaranteed portability of a file name across all POSIX systems. We also know that anything exceeding the 8.3 limitation will not be portable to DOS. If it exceeds 44 characters, it will not be portable to IBM S/370 (assuming Wikipedia is right). And names such as "COM1" or "LPT8" will limit portability with Windows. The POSIX standard here talks about the /minimal/ allowed characters for /maximal/ portability - regardless of the OS and of the filesystem in use, for a POSIX-compatible system. It says /nothing/ about banning or disallowing other characters. It says /nothing/ about saying people should always use fully portable names. Your native language is French. Do you think you should be banned from calling a filename "Française.txt", just because "ç" is not in the list of portable POSIX characters? If you are making a program or other files that you want to be maximally portable, stick to the simple characters. When you look in the /usr/ tree on a Linux system, you would expect to see everything following the POSIX portable filename rules. But when you look in /home, you expect to see people using exactly the filenames they want, using whatever characters they want. To get /slightly/ back on topic, this can be compared to writing C code such as "int x = 123456;". That is /not/ portable - it would not work on a system with 16-bit "int". But should that stop people writing it? Of course not - most code does not need to be portable to 16-bit int systems. If you /need/ such portability, then of course you write it in a different and portable way.
[toc] | [prev] | [next] | [standalone]
| From | jacobnavia <jacob@jacob.remcomp.fr> |
|---|---|
| Date | 2018-10-05 12:41 +0200 |
| Message-ID | <pp7f4j$qej$1@dont-email.me> |
| In reply to | #136243 |
Le 05/10/2018 à 09:44, David Brown a écrit : > Your native language is French. Do you think you should be banned from > calling a filename "Française.txt", just because "ç" is not in the list > of portable POSIX characters? Yes. I never used any special characters in file names, and I write francaise.txt because I KNOW (by experience) that in a few years, when I move that file from windows to mac or from mac to linux I will ALWAYS have problems since they do not use the same code page, or Unicode or WHATEVER! It has NEVER WORKED, and all files with special characters become garbled.
[toc] | [prev] | [next] | [standalone]
Page 3 of 11 — ← Prev page 1 2 [3] 4 5 … 11 Next page →
Back to top | Article view | comp.lang.c
csiph-web