Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #100280 > unrolled thread
| Started by | Alla _ <modelling.data@gmail.com> |
|---|---|
| First post | 2016-12-26 00:31 -0800 |
| Last post | 2016-12-26 14:38 -0800 |
| Articles | 20 on this page of 252 — 20 participants |
Back to article view | Back to comp.lang.c
Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 00:31 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 01:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 02:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:04 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 12:04 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 05:49 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 15:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 07:31 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 16:44 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 08:00 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 17:43 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 12:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 23:56 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:33 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <mx2927@gmail.com> - 2016-12-26 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 09:48 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 19:03 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-26 10:39 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-26 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-26 20:56 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-26 13:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 00:27 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 09:35 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:33 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-28 20:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 15:31 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 01:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:33 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:16 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-29 14:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 23:49 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 15:34 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 08:49 -0800
Re: Reading lines from a file, eliminating CR and LF "James R. Kuyper" <jameskuyper@verizon.net> - 2017-01-04 12:55 -0500
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2016-12-29 00:19 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 13:01 -0800
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2016-12-29 07:35 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 08:58 -0800
Re: Reading lines from a file, eliminating CR and LF raltbos@xs4all.nl (Richard Bos) - 2017-01-01 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Jean-Marc Bourguet <jm@bourguet.org> - 2016-12-30 08:39 +0100
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-30 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 02:22 -0800
Re: Reading lines from a file, eliminating CR and LF "Peter \"Shaggy\" Haywood" <phaywood@alphalink.com.au> - 2016-12-31 00:22 +1100
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-02 03:29 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 10:09 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 14:01 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 16:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 16:49 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-03 05:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-03 08:47 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:39 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:35 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 20:00 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 13:15 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-02 17:00 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-02 19:48 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 09:32 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-13 12:52 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-15 15:46 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-15 16:54 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-30 11:25 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2017-01-30 14:06 -0800
Re: Reading lines from a file, eliminating CR and LF supercat@casperkitty.com - 2016-12-29 06:07 -0800
Re: Reading lines from a file, eliminating CR and LF Tim Rentsch <txr@alumni.caltech.edu> - 2017-01-13 15:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:37 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 19:29 +0100
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-27 11:41 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:30 -0800
Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2016-12-28 16:08 -0800
Re: Reading lines from a file, eliminating CR and LF fir <profesor.fir@gmail.com> - 2016-12-27 12:50 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-27 09:59 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-27 10:56 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-27 12:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:35 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-28 09:16 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:08 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-27 22:34 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 08:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 02:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 10:11 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:56 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:35 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-30 22:45 +0100
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-31 03:19 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:20 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 00:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 11:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:53 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:24 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 00:53 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:28 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-29 14:48 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 22:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 01:55 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-29 10:14 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2016-12-29 11:44 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 02:02 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:13 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 14:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:28 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:45 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:23 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 03:50 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 13:35 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2016-12-30 15:22 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 08:29 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-30 16:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-31 10:50 -0800
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2016-12-31 19:02 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-31 20:10 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 04:08 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 12:38 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:45 +0000
Re: Reading lines from a file, eliminating CR and LF BartC <bc@freeuk.com> - 2017-01-01 13:54 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:26 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:46 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 17:08 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 08:13 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-01 16:47 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 16:53 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:18 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-01 19:20 +0100
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-01 15:18 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:41 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-01 09:05 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-01 19:16 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 03:39 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 04:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:48 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 13:47 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 07:21 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 18:38 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 10:57 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 21:48 +0000
POSIX, was: Re: Reading lines from a file, eliminating CR and LF luser droog <luser.droog@gmail.com> - 2017-01-02 15:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-31 21:03 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-02 11:30 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 19:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-02 19:56 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-02 21:09 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:01 +1300
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:45 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:09 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:07 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-04 09:13 +1300
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 11:53 +1300
Re: Reading lines from a file, eliminating CR and LF Malcolm McLean <malcolm.mclean5@btinternet.com> - 2017-01-02 15:40 -0800
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:16 +1300
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 00:01 +0000
Re: Reading lines from a file, eliminating CR and LF Ian Collins <ian-news@hotmail.com> - 2017-01-03 13:21 +1300
Re: Reading lines from a file, eliminating CR and LF Ike Naar <ike@iceland.freeshell.org> - 2017-01-03 08:40 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 12:50 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:42 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 15:11 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 16:32 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 17:24 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 17:48 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-03 18:56 +0000
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 19:46 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:37 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-02 13:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 14:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 13:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 03:30 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 02:23 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-04 02:56 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 07:06 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 03:01 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 11:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 04:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:23 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:26 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:38 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 12:21 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:52 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 14:13 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 07:59 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:12 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:15 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:19 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 08:28 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 17:20 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 10:45 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 09:02 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-05 19:49 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 13:28 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:14 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 00:50 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 06:11 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-06 16:33 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-06 12:14 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 02:15 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:51 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 03:32 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 21:57 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 01:51 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 02:09 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 04:09 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-07 22:05 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-08 03:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-08 21:36 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 04:33 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-09 21:44 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 23:54 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 02:04 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 11:28 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 04:25 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-10 14:14 +0000
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-10 14:52 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-10 07:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 00:11 -0800
Re: Reading lines from a file, eliminating CR and LF mark.bluemel@gmail.com - 2017-01-12 01:13 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 01:41 -0800
Re: Reading lines from a file, eliminating CR and LF Richard Heathfield <rjh@cpax.org.uk> - 2017-01-12 09:55 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-12 10:25 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-08 19:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-09 05:27 -0800
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2017-01-07 17:06 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-07 08:11 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-05 16:04 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 12:36 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-04 12:49 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-04 05:19 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-04 15:14 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:57 -0800
Re: Reading lines from a file, eliminating CR and LF Keith Thompson <kst-u@mib.org> - 2017-01-05 08:24 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-05 02:58 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2017-01-04 13:02 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 03:37 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:46 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-03 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2017-01-03 02:43 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2017-01-02 22:45 +0000
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-29 10:17 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:42 -0800
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-30 00:51 -0800
Re: Reading lines from a file, eliminating CR and LF Ben Bacarisse <ben.usenet@bsb.me.uk> - 2016-12-29 11:25 +0000
Re: Reading lines from a file, eliminating CR and LF Manfred <noname@invalid.add> - 2016-12-28 20:57 +0100
Re: Reading lines from a file, eliminating CR and LF Alla _ <modelling.data@gmail.com> - 2016-12-28 23:16 -0800
Re: Reading lines from a file, eliminating CR and LF Barry Schwarz <schwarzb@dqel.com> - 2016-12-26 14:38 -0800
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-26 13:50 -0800 |
| Message-ID | <lnk2am8imc.fsf@kst-u.example.com> |
| In reply to | #100305 |
Manfred <noname@invalid.add> writes:
[...]
> Just to mention this: no newline should not be an error condition: you
> may have a line with no newline at the end of the file. Still such a
> (last) line is a valid one.
> (This was already mentioned by some else)
Essentially correct; feel free to ignore the following
language-lawyering.
The C standard says that for a text stream, it's implementation-defined
whether the final line requires a trailing '\n'. If it *is* required by
the current implementation, the behavior of reading a text file with no
'\n' on the last line is undefined.
In practice, I believe that most implementations don't require a
trailing '\n', which means that code that reads text files should be
prepared for a final unterminated line.
Whether a final end-of-line marker is required on a CSV file is a
separate question, to which there's probably no one definitive answer.
My suggestion would be to accept input with a missing final end-of-line
marker, but to always write such a marker on output.
--
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 | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 00:27 -0800 |
| Message-ID | <fc6ac8f4-239c-487c-b4d2-5825ef4f427b@googlegroups.com> |
| In reply to | #100308 |
On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: > Manfred <noname@invalid.add> writes: > [...] <snip> > My suggestion would be to accept input with a missing final end-of-line > marker, but to always write such a marker on output. > I am not sure I completely understand this. Do I need additional code for that? What happens if there is no newline character at the end of each line in the file? If the number of bytes, specified during the call to fgets, is larger than the end of the line (when there is actually no technical ending of the line in the file), then fgets would continue reading the next line until it reaches the specified amount of bytes, correct? Is it possible that csv files won't have line terminating values at the end of each line? If so, then my whole idea and this whole code for reading lines is incorrect. Oh.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-28 09:35 +0000 |
| Message-ID | <o400uc$o3j$2@dont-email.me> |
| In reply to | #100398 |
On 28/12/16 08:27, Alla _ wrote: > On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: >> Manfred <noname@invalid.add> writes: >> [...] > <snip> >> My suggestion would be to accept input with a missing final end-of-line >> marker, but to always write such a marker on output. >> > I am not sure I completely understand this. Do I need additional code for > that? I don't see why. > What happens if there is no newline character at the end of each line > in the file? You have the source code, so you are in an ideal position to find out. > If the number of bytes, specified during the call to fgets, is larger > than the end of the line (when there is actually no technical ending of the line > in the file), then fgets would continue reading the next line until it reaches the > specified amount of bytes, correct? No, it can't read past the end of the file. > Is it possible that csv files won't have > line terminating values at the end of each line? If so, then my whole idea > and this whole code for reading lines is incorrect. Oh. There is no single definition of CSV files. So if you write a program that reads CSV files, you get to decide what kind of CSV files you are prepared to read. -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-28 10:33 -0800 |
| Message-ID | <5422faa0-d924-4c9e-8838-77573bbfed61@googlegroups.com> |
| In reply to | #100400 |
On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote: > On 28/12/16 08:27, Alla _ wrote: > > On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: > >> Manfred <noname@invalid.add> writes: > >> [...] > > <snip> > >> My suggestion would be to accept input with a missing final end-of-line > >> marker, but to always write such a marker on output. > >> > > I am not sure I completely understand this. Do I need additional code for > > that? > > I don't see why. > > > What happens if there is no newline character at the end of each line > > in the file? > > You have the source code, so you are in an ideal position to find out. > > > If the number of bytes, specified during the call to fgets, is larger > > than the end of the line (when there is actually no technical ending of the line > > in the file), then fgets would continue reading the next line until it reaches the > > specified amount of bytes, correct? > > No, it can't read past the end of the file. Yes, I know that. I wasn't referring to the last line. Anyway, I believe this issue has been cleared. > > > Is it possible that csv files won't have > > line terminating values at the end of each line? If so, then my whole idea > > and this whole code for reading lines is incorrect. Oh. > > There is no single definition of CSV files. So if you write a program > that reads CSV files, you get to decide what kind of CSV files you are > prepared to read. All right.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-28 20:48 +0000 |
| Message-ID | <o418ci$sbt$1@dont-email.me> |
| In reply to | #100459 |
On 28/12/16 18:33, Alla _ wrote: > On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote: >> On 28/12/16 08:27, Alla _ wrote: >>> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: >>>> Manfred <noname@invalid.add> writes: >>>> [...] >>> <snip> >>>> My suggestion would be to accept input with a missing final end-of-line >>>> marker, but to always write such a marker on output. >>>> >>> I am not sure I completely understand this. Do I need additional code for >>> that? >> >> I don't see why. >> >>> What happens if there is no newline character at the end of each line >>> in the file? >> >> You have the source code, so you are in an ideal position to find out. >> >>> If the number of bytes, specified during the call to fgets, is larger >>> than the end of the line (when there is actually no technical ending of the line >>> in the file), then fgets would continue reading the next line until it reaches the >>> specified amount of bytes, correct? >> >> No, it can't read past the end of the file. > Yes, I know that. I wasn't referring to the last line. That makes no sense. How can it be anything /but/ the last line in the file, if there is nothing to indicate that the line has ended? -- Richard Heathfield Email: rjh at cpax dot org dot uk "Usenet is a strange place" - dmr 29 July 1999 Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2016-12-29 15:31 +0000 |
| Message-ID | <87tw9mda5m.fsf@bsb.me.uk> |
| In reply to | #100493 |
Richard Heathfield <rjh@cpax.org.uk> writes:
<snip>
> Firstly, let's deal with the fact that different platforms have
> different conventions.
<snip excellent explanation>
> The fix, as I have told you before, is to run this program on your data:
>
> #include <stdio.h>
> int main(void)
> {
> int ch;
> while((ch = getchar()) != EOF)
> {
> if(ch != '\r')
> {
> putchar(ch);
> }
> }
> return 0;
> }
(Or, untested on a Mac, tr -d '\r')
> END OF PROBLEM.
I may have missed all the vital context but this looks like very odd
advice to me. Why is \r so special? Can't the program just ignore it
as it will, I hope, ignore other odd characters like \b, \v and \f?
And if the plan is not to ignore odd input but to report on it, then
filtering out \r characters is not the right thing to do either.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-29 18:56 +0000 |
| Message-ID | <o43m59$ccb$1@dont-email.me> |
| In reply to | #100509 |
On 29/12/16 15:31, Ben Bacarisse wrote:
> Richard Heathfield <rjh@cpax.org.uk> writes:
>
>> The fix, as I have told you before, is to run this program on your data:
>>
>> #include <stdio.h>
>> int main(void)
>> {
>> int ch;
>> while((ch = getchar()) != EOF)
>> {
>> if(ch != '\r')
>> {
>> putchar(ch);
>> }
>> }
>> return 0;
>> }
>
> (Or, untested on a Mac, tr -d '\r')
>
>> END OF PROBLEM.
>
> I may have missed all the vital context but this looks like very odd
> advice to me. Why is \r so special?
It is a common wart, and easy to remove. It has caused a vast amount of
stupid and pointless distraction for Alla. She doesn't need all this
grief. Far better to rip out the silly wart separately in a data
pre-processing step than to jump through all kinds of hoops in an
attempt to correct for MS's stupidity.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Barry Schwarz <schwarzb@dqel.com> |
|---|---|
| Date | 2016-12-29 01:03 -0800 |
| Message-ID | <soj96c1a3gl4sful7om22k9nrp42j0rri9@4ax.com> |
| In reply to | #100493 |
On Thu, 29 Dec 2016 00:16:47 -0800 (PST), Alla _ <modelling.data@gmail.com> wrote: >On Wednesday, December 28, 2016 at 11:48:51 PM UTC+3, Richard Heathfield wrote: >> On 28/12/16 18:33, Alla _ wrote: >> > On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote: >> >> On 28/12/16 08:27, Alla _ wrote: >> >>> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: >> >>>> Manfred <noname@invalid.add> writes: >> >>>> [...] >> >>> <snip> >> >>>> My suggestion would be to accept input with a missing final end-of-line >> >>>> marker, but to always write such a marker on output. >> >>>> >> >>> I am not sure I completely understand this. Do I need additional code for >> >>> that? >> >> >> >> I don't see why. >> >> >> >>> What happens if there is no newline character at the end of each line >> >>> in the file? >> >> >> >> You have the source code, so you are in an ideal position to find out. >> >> >> >>> If the number of bytes, specified during the call to fgets, is larger >> >>> than the end of the line (when there is actually no technical ending of the line >> >>> in the file), then fgets would continue reading the next line until it reaches the >> >>> specified amount of bytes, correct? >> >> >> >> No, it can't read past the end of the file. >> > Yes, I know that. I wasn't referring to the last line. >> >> That makes no sense. How can it be anything /but/ the last line in the >> file, if there is nothing to indicate that the line has ended? > >Please, explain to me in pure English and in few words: >- can I assume that *every line*, but the last one, in csv files, converted from excel >files, has a newline character at the end - CRLF or just LF; and thus fgets will >always, if the parameter size has enough bytes, stop at the newline character, >putting '\0' after it; if there is no newline character, fgets, assuming enough >bytes passed to it, will stop when the end of the file is reached, meaning that this >last line will contain all valid characters as well as anything else found there >before the end of file is reached? Those additional characters would most >likely be some unprintable ones. >I can't now consider all possible difficulties and nuances a csv file can present, >so, if above assumptions are correct, then I assume I can limit myself to: >- "putting away" newline characters if found >- deleting all additional commas at the end, if found; >Manfred, I truly need this for future processing; this was the whole point >of writing this little program. >- return mistake if any unprintable characters are found, other that newline >ones. >Yes? What Richard was trying to get you to realize is that every line except the last must terminate with a LF. Otherwise, there would be no way for fgets to know when a line ended. To put it another way, if there is no LF between two lines, then fgets will treat them as a single line which in fact is the true situation. The last line is different. If it has a LF, fgets will recognize it and terminate the read after storing that character in the target buffer. If the last line does not have a LF, fgets will terminate the read after storing the last character of the file in the target buffer. (And of course the string is properly terminated.) Both preceding paragraphs assume the buffer is large enough to hold the line since your program was never prepared to deal with lines longer than the buffer. -- Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 01:33 -0800 |
| Message-ID | <57786d04-ab25-4021-96f7-dbb407972664@googlegroups.com> |
| In reply to | #100523 |
On Thursday, December 29, 2016 at 12:03:59 PM UTC+3, Barry Schwarz wrote: > On Thu, 29 Dec 2016 00:16:47 -0800 (PST), Alla _ > <modelling.data@gmail.com> wrote: > > >On Wednesday, December 28, 2016 at 11:48:51 PM UTC+3, Richard Heathfield wrote: > >> On 28/12/16 18:33, Alla _ wrote: > >> > On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote: > >> >> On 28/12/16 08:27, Alla _ wrote: > >> >>> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: > >> >>>> Manfred <noname@invalid.add> writes: > >> >>>> [...] > >> >>> <snip> > >> >>>> My suggestion would be to accept input with a missing final end-of-line > >> >>>> marker, but to always write such a marker on output. > >> >>>> > >> >>> I am not sure I completely understand this. Do I need additional code for > >> >>> that? > >> >> > >> >> I don't see why. > >> >> > >> >>> What happens if there is no newline character at the end of each line > >> >>> in the file? > >> >> > >> >> You have the source code, so you are in an ideal position to find out. > >> >> > >> >>> If the number of bytes, specified during the call to fgets, is larger > >> >>> than the end of the line (when there is actually no technical ending of the line > >> >>> in the file), then fgets would continue reading the next line until it reaches the > >> >>> specified amount of bytes, correct? > >> >> > >> >> No, it can't read past the end of the file. > >> > Yes, I know that. I wasn't referring to the last line. > >> > >> That makes no sense. How can it be anything /but/ the last line in the > >> file, if there is nothing to indicate that the line has ended? > > > >Please, explain to me in pure English and in few words: > >- can I assume that *every line*, but the last one, in csv files, converted from excel > >files, has a newline character at the end - CRLF or just LF; and thus fgets will > >always, if the parameter size has enough bytes, stop at the newline character, > >putting '\0' after it; if there is no newline character, fgets, assuming enough > >bytes passed to it, will stop when the end of the file is reached, meaning that this > >last line will contain all valid characters as well as anything else found there > >before the end of file is reached? Those additional characters would most > >likely be some unprintable ones. > >I can't now consider all possible difficulties and nuances a csv file can present, > >so, if above assumptions are correct, then I assume I can limit myself to: > >- "putting away" newline characters if found > >- deleting all additional commas at the end, if found; > >Manfred, I truly need this for future processing; this was the whole point > >of writing this little program. > >- return mistake if any unprintable characters are found, other that newline > >ones. > >Yes? > > What Richard was trying to get you to realize is that every line > except the last must terminate with a LF. Otherwise, there would be > no way for fgets to know when a line ended. To put it another way, if > there is no LF between two lines, then fgets will treat them as a > single line which in fact is the true situation. > > The last line is different. If it has a LF, fgets will recognize it > and terminate the read after storing that character in the target > buffer. If the last line does not have a LF, fgets will terminate the > read after storing the last character of the file in the target > buffer. (And of course the string is properly terminated.) > > Both preceding paragraphs assume the buffer is large enough to hold > the line since your program was never prepared to deal with lines > longer than the buffer. > Thank you. But this is exactly what I have said even before Richard answered me. And now you have repeated, in better terms though, exactly what I have written. Good. Solved. Thank you! A bit off topic: Seems a lot of people here do not understand everything I say (my poor English might cause this problem), or only skim through what I write, a priori assuming I say nonsense :) > -- > Remove del for email
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 00:16 -0800 |
| Message-ID | <e07738c8-6717-4fd9-9c1b-8c873f574857@googlegroups.com> |
| In reply to | #100493 |
On Wednesday, December 28, 2016 at 11:48:51 PM UTC+3, Richard Heathfield wrote: > On 28/12/16 18:33, Alla _ wrote: > > On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote: > >> On 28/12/16 08:27, Alla _ wrote: > >>> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: > >>>> Manfred <noname@invalid.add> writes: > >>>> [...] > >>> <snip> > >>>> My suggestion would be to accept input with a missing final end-of-line > >>>> marker, but to always write such a marker on output. > >>>> > >>> I am not sure I completely understand this. Do I need additional code for > >>> that? > >> > >> I don't see why. > >> > >>> What happens if there is no newline character at the end of each line > >>> in the file? > >> > >> You have the source code, so you are in an ideal position to find out. > >> > >>> If the number of bytes, specified during the call to fgets, is larger > >>> than the end of the line (when there is actually no technical ending of the line > >>> in the file), then fgets would continue reading the next line until it reaches the > >>> specified amount of bytes, correct? > >> > >> No, it can't read past the end of the file. > > Yes, I know that. I wasn't referring to the last line. > > That makes no sense. How can it be anything /but/ the last line in the > file, if there is nothing to indicate that the line has ended? Please, explain to me in pure English and in few words: - can I assume that *every line*, but the last one, in csv files, converted from excel files, has a newline character at the end - CRLF or just LF; and thus fgets will always, if the parameter size has enough bytes, stop at the newline character, putting '\0' after it; if there is no newline character, fgets, assuming enough bytes passed to it, will stop when the end of the file is reached, meaning that this last line will contain all valid characters as well as anything else found there before the end of file is reached? Those additional characters would most likely be some unprintable ones. I can't now consider all possible difficulties and nuances a csv file can present, so, if above assumptions are correct, then I assume I can limit myself to: - "putting away" newline characters if found - deleting all additional commas at the end, if found; Manfred, I truly need this for future processing; this was the whole point of writing this little program. - return mistake if any unprintable characters are found, other that newline ones. Yes?
[toc] | [prev] | [next] | [standalone]
| From | Richard Heathfield <rjh@cpax.org.uk> |
|---|---|
| Date | 2016-12-29 14:05 +0000 |
| Message-ID | <o43556$7a4$1@dont-email.me> |
| In reply to | #100541 |
On 29/12/16 08:16, Alla _ wrote:
> On Wednesday, December 28, 2016 at 11:48:51 PM UTC+3, Richard Heathfield wrote:
>> On 28/12/16 18:33, Alla _ wrote:
>>> On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote:
>>>> On 28/12/16 08:27, Alla _ wrote:
>>>>> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote:
>>>>>> Manfred <noname@invalid.add> writes:
>>>>>> [...]
>>>>> <snip>
>>>>>> My suggestion would be to accept input with a missing final end-of-line
>>>>>> marker, but to always write such a marker on output.
>>>>>>
>>>>> I am not sure I completely understand this. Do I need additional code for
>>>>> that?
>>>>
>>>> I don't see why.
>>>>
>>>>> What happens if there is no newline character at the end of each line
>>>>> in the file?
>>>>
>>>> You have the source code, so you are in an ideal position to find out.
>>>>
>>>>> If the number of bytes, specified during the call to fgets, is larger
>>>>> than the end of the line (when there is actually no technical ending of the line
>>>>> in the file), then fgets would continue reading the next line until it reaches the
>>>>> specified amount of bytes, correct?
>>>>
>>>> No, it can't read past the end of the file.
>>> Yes, I know that. I wasn't referring to the last line.
>>
>> That makes no sense. How can it be anything /but/ the last line in the
>> file, if there is nothing to indicate that the line has ended?
>
> Please, explain to me in pure English and in few words:
> - can I assume that *every line*, but the last one, in csv files, converted from excel
> files, has a newline character at the end
When you open a text stream, C considers the data to be divided into
lines, each line consisting of at least 0 (no, none, nil, nada)
characters PLUS one newline character '\n'. This is true whether it's a
CSV file, an HTML file, a C source file, a Windows .ini file, or
whatever file it is.
If the text stream is coming from a file that is not suitable for being
opened in text mode (e.g. because some boneheaded MS weenie decided that
they should write a carriage return before every newline even though
that isn't the convention of the platform on which the program is
running), that's a problem, and it will show up in data corruption.
Last line: you get to decide whether you will accept a final line that
doesn't have a \n on the end. There are two opposing schools of thought
about this: (1) accepting the line encourages sloppiness; and (2) 'be
generous in what you accept but strict in what you produce'.
> - CRLF or just LF; and thus fgets will
> always, if the parameter size has enough bytes, stop at the newline character,
> putting '\0' after it; if there is no newline character, fgets, assuming enough
> bytes passed to it, will stop when the end of the file is reached, meaning that this
> last line will contain all valid characters as well as anything else found there
> before the end of file is reached? Those additional characters would most
> likely be some unprintable ones.
Firstly, let's deal with the fact that different platforms have
different conventions. Imagine a system that marks line endings with the
following bytes: 0xFEEBDAED
On such a system, if you write a program that creates a text file and
writes this to it: "Hello world\n", the system must magically transform
the \n into 0xfeebdaed. And, when you read it back in as a text file,
again the system must magically transform 0xfeebdaed into \n.
Macs used to use \r rather than \n, but a C program that reads a text
file on an old Mac can still expect to see \n because the runtime system
ON THE OLD MAC must do magic to ensure this. And the C program still
writes a \n, and the runtime system must do magic to convert this to \r
for the old Mac.
Windows systems (and old DOS systems) use \r\n instead of \n, and the
runtime system ON WINDOWS must do the necessary magic to ensure that
\r\n is read as if it were \n, and \n is converted back to \r\n on the
way out.
The problem comes when you try to treat a Windows-format text file as if
it were a Linux format text file, or vice versa. It doesn't work, and
you get the problems you are currently experiencing.
The fix, as I have told you before, is to run this program on your data:
#include <stdio.h>
int main(void)
{
int ch;
while((ch = getchar()) != EOF)
{
if(ch != '\r')
{
putchar(ch);
}
}
return 0;
}
END OF PROBLEM.
--
Richard Heathfield
Email: rjh at cpax dot org dot uk
"Usenet is a strange place" - dmr 29 July 1999
Sig line 4 vacant - apply within
[toc] | [prev] | [next] | [standalone]
| From | Alla _ <modelling.data@gmail.com> |
|---|---|
| Date | 2016-12-29 23:49 -0800 |
| Message-ID | <c8a3783f-a59b-440f-a8c0-4252be1cd711@googlegroups.com> |
| In reply to | #100584 |
On Thursday, December 29, 2016 at 5:05:59 PM UTC+3, Richard Heathfield wrote: > On 29/12/16 08:16, Alla _ wrote: > > On Wednesday, December 28, 2016 at 11:48:51 PM UTC+3, Richard Heathfield wrote: > >> On 28/12/16 18:33, Alla _ wrote: > >>> On Wednesday, December 28, 2016 at 12:35:40 PM UTC+3, Richard Heathfield wrote: > >>>> On 28/12/16 08:27, Alla _ wrote: > >>>>> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: > >>>>>> Manfred <noname@invalid.add> writes: > >>>>>> [...] > >>>>> <snip> <snip> Thank you very much! (I have snipped the whole text, so not to get complaints on excessive text in the answer)
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@invalid.add> |
|---|---|
| Date | 2016-12-28 15:34 +0100 |
| Message-ID | <o40ihu$jjt$1@gioia.aioe.org> |
| In reply to | #100398 |
On 12/28/2016 9:27 AM, Alla _ wrote: > On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: >> Manfred <noname@invalid.add> writes: >> [...] > <snip> >> My suggestion would be to accept input with a missing final end-of-line >> marker, but to always write such a marker on output. >> > I am not sure I completely understand this. Do I need additional code for > that? Depends on how you are handling the line. The way it is going to look like in the current example you don't. What happens if there is no newline character at the end of each line > in the file? There is going to be a newline char at the end of each line, /except/ possibly for the /last/ line (as I mentioned earlier).
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2016-12-28 08:49 -0800 |
| Message-ID | <lnlgv0578v.fsf@kst-u.example.com> |
| In reply to | #100398 |
Alla _ <modelling.data@gmail.com> writes:
> On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote:
>> Manfred <noname@invalid.add> writes:
>> [...]
> <snip>
>> My suggestion would be to accept input with a missing final end-of-line
>> marker, but to always write such a marker on output.
>>
> I am not sure I completely understand this. Do I need additional code
> for that? What happens if there is no newline character at the end of
> each line in the file? If the number of bytes, specified during the
> call to fgets, is larger than the end of the line (when there is
> actually no technical ending of the line in the file), then fgets
> would continue reading the next line until it reaches the specified
> amount of bytes, correct? Is it possible that csv files won't have
> line terminating values at the end of each line? If so, then my whole
> idea and this whole code for reading lines is incorrect. Oh.
A text file may or may not have a '\n' on the end of the last line. For
example, the contents of a 2-line text file, represented as a string,
might be either
"Line 1\nLine 2\n"
or
"Line 1\nLine 2"
The former is generally preferred.
If you read a line using fgets(), ignoring the possibility of lines too
long to fit in your target array, you can just remove the trailing
newline if it's there. Or, if you prefer, you can treat a missing '\n'
as an error. It shouldn't be a huge deal.
--
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 | "James R. Kuyper" <jameskuyper@verizon.net> |
|---|---|
| Date | 2017-01-04 12:55 -0500 |
| Message-ID | <6e8dc576-ec8a-d678-7000-1e8175425e98@verizon.net> |
| In reply to | #100398 |
On 12/28/2016 03:27 AM, Alla _ wrote: > On Tuesday, December 27, 2016 at 12:50:34 AM UTC+3, Keith Thompson wrote: >> Manfred <noname@invalid.add> writes: >> [...] > <snip> >> My suggestion would be to accept input with a missing final end-of-line >> marker, but to always write such a marker on output. >> > I am not sure I completely understand this. Do I need additional code for > that? What happens if there is no newline character at the end of each line > in the file? If the number of bytes, specified during the call to fgets, is larger > than the end of the line (when there is actually no technical ending of the line > in the file), then fgets would continue reading the next line until it reaches the > specified amount of bytes, correct? If there is no "technical ending of the line", there is "no ending of the line" - the adjective "technical" doesn't change anything in this context. Therefore, fgets() can not have reached the "next line" yet, because it requires an "ending of the line" for the current line to end. The correct statement is that fgets "would continue reading the rest of the *same* line until it reaches the specified amount of bytes *or the end of the file, whichever comes first*."
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <txr@alumni.caltech.edu> |
|---|---|
| Date | 2016-12-29 00:19 -0800 |
| Message-ID | <kfnzijfw3jd.fsf@x-alumni2.alumni.caltech.edu> |
| In reply to | #100308 |
Keith Thompson <kst-u@mib.org> writes: > Manfred <noname@invalid.add> writes: > [...] >> Just to mention this: no newline should not be an error condition: you >> may have a line with no newline at the end of the file. Still such a >> (last) line is a valid one. >> (This was already mentioned by some else) > > Essentially correct; feel free to ignore the following > language-lawyering. > > The C standard says that for a text stream, it's implementation-defined > whether the final line requires a trailing '\n'. If it *is* required by > the current implementation, the behavior of reading a text file with no > '\n' on the last line is undefined. [...] That is one plausible interpretation. Another plausible interpretation is that the situation described simply cannot exist. If a file is closed with a non-empty last line, but no newline, then that last line is either discarded or it is written with a newline appended. The file system may have no way to represent a text file with a non-empty last line but without a trailing newline; or, if it does, an attempt to read such a line may read nothing and return EOF, or it may give the line with a newline appended. And which of these alternatives is meant to hold must be specified as part of the documentation that specifies what the implementation-defined requirement means in this implementation. Personally, I think the second of these is more likely than the first. But both are plausible interpretations of what the Standard is intended to prescribe.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-29 13:01 -0800 |
| Message-ID | <0ea09605-ba6f-4250-b087-430c7a75668f@googlegroups.com> |
| In reply to | #100464 |
On Thursday, December 29, 2016 at 4:58:30 PM UTC, supe...@casperkitty.com wrote: > On Thursday, December 29, 2016 at 9:35:20 AM UTC-6, Malcolm McLean wrote: > > So ironically binary files like JPEG are portable, even though binary > > mode is supposed to be non-portable (because newbies fwrite structs), > > and text mode files like C source are not. > > Code which uses fwrite on structures is generally more efficient and more > readable than code which uses bytewise operations to transfer all of the > data into byte buffer and writes that. If language designers don't want > people to write data in portable fashion, they should add a means via > which code can specify the exact layout of a structure, with the proviso > that code which accesses a structure that isn't in native format may be > slow and inefficient. > > Given that the Standard already requires compilers to be capable of > generating a sequence of shifting and masking operations for something > like "struct.x+=3;" [if x might be a bitfield], the amount of additional > logic to allow a programmer to specify the layout would be relatively > slight, especially if the Standard acknowledged that octets are totally > dominant as an interchange format [even on a 36-bit system, the most > useful types *for data interchange* are going to be the same as anywhere > else: big-endian and little-endian integers in 8, 16, 32, and 64-bit sizes, > and big-endian and little-endian floats in 32 and 64-bit sizes]. > > If the Standard included a way of specifying structure layouts in absolute > terms along with a copy-fields-by-name structure assignment operator (allow > assignment between an arbitrary pair of structure types if the every field > which is present in either is present in the other and represents the same > kind of thing [signed integer, unsigned integer, floating-point, pointer, > etc]; the consequences if a signed source field's value does not fit in the > destination type should be Implementation-Defined. > > If such features existed and support for them became widespread, the use of > fwrite on non-fixed-format structures could be considered obsolescent. As > it is, though, the failure of the Standard to recognize that certain formats > are dominant for purposes of data interchange often makes it impossible to > write code which is portable, readable, and efficient. > I maintain portability routines here. Considering the importance of portable file IO, these github pages attract only a small amount of attention. https://github.com/MalcolmMcLean/ieee754
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2016-12-29 07:35 -0800 |
| Message-ID | <1c67a89c-73a5-4ac4-b2b1-2e267e9b4174@googlegroups.com> |
| In reply to | #100464 |
On Thursday, December 29, 2016 at 2:07:18 PM UTC, supe...@casperkitty.com wrote: > The Standard does not recognize any way by which an implementation could > gain access to a file that it did not generate. It also imposes no > requirements about what happens if an attempt is made to write a file in > binary mode and read it in text mode, or vice versa. > > Consequently, if an implementation ensures that any text file written > thereby will end with a newline, that implementation may do anything it > likes if an attempt is made to open in text mode a non-empty file that > ends with something other than a newline, since from the point of view > of the Standard no such file could possibly exist unless written in > binary mode (which would be UB). > > Nonetheless, since the whole *purpose* of many programs is to read files > which were generated by some outside means, useful C implementations should > endeavor to behave usefully when given such files. > So ironically binary files like JPEG are portable, even though binary mode is supposed to be non-portable (because newbies fwrite structs), and text mode files like C source are not.
[toc] | [prev] | [next] | [standalone]
| From | supercat@casperkitty.com |
|---|---|
| Date | 2016-12-29 08:58 -0800 |
| Message-ID | <ba0c7ab7-e821-43a5-b5bc-2872b485d8d4@googlegroups.com> |
| In reply to | #100514 |
On Thursday, December 29, 2016 at 9:35:20 AM UTC-6, Malcolm McLean wrote: > So ironically binary files like JPEG are portable, even though binary > mode is supposed to be non-portable (because newbies fwrite structs), > and text mode files like C source are not. Code which uses fwrite on structures is generally more efficient and more readable than code which uses bytewise operations to transfer all of the data into byte buffer and writes that. If language designers don't want people to write data in portable fashion, they should add a means via which code can specify the exact layout of a structure, with the proviso that code which accesses a structure that isn't in native format may be slow and inefficient. Given that the Standard already requires compilers to be capable of generating a sequence of shifting and masking operations for something like "struct.x+=3;" [if x might be a bitfield], the amount of additional logic to allow a programmer to specify the layout would be relatively slight, especially if the Standard acknowledged that octets are totally dominant as an interchange format [even on a 36-bit system, the most useful types *for data interchange* are going to be the same as anywhere else: big-endian and little-endian integers in 8, 16, 32, and 64-bit sizes, and big-endian and little-endian floats in 32 and 64-bit sizes]. If the Standard included a way of specifying structure layouts in absolute terms along with a copy-fields-by-name structure assignment operator (allow assignment between an arbitrary pair of structure types if the every field which is present in either is present in the other and represents the same kind of thing [signed integer, unsigned integer, floating-point, pointer, etc]; the consequences if a signed source field's value does not fit in the destination type should be Implementation-Defined. If such features existed and support for them became widespread, the use of fwrite on non-fixed-format structures could be considered obsolescent. As it is, though, the failure of the Standard to recognize that certain formats are dominant for purposes of data interchange often makes it impossible to write code which is portable, readable, and efficient.
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2017-01-01 15:21 +0000 |
| Message-ID | <58691ada.4905265@news.xs4all.nl> |
| In reply to | #100514 |
Malcolm McLean <malcolm.mclean5@btinternet.com> wrote: > On Thursday, December 29, 2016 at 2:07:18 PM UTC, supe...@casperkitty.com wrote: > > > The Standard does not recognize any way by which an implementation could > > gain access to a file that it did not generate. It also imposes no > > requirements about what happens if an attempt is made to write a file in > > binary mode and read it in text mode, or vice versa. > So ironically binary files like JPEG are portable, even though binary > mode is supposed to be non-portable (because newbies fwrite structs), > and text mode files like C source are not. There's nothing ironic about that. Many formats of binary files are portable because their entire structure is specified octet-by-octet, without a single reference to the representation of values on the system using them. This may mean that the values in them need transcribing on one system or another - if only to switch integers between MSB and LSB representations! - but because you know how the values are arranged within the file, this is perfectly doable. What's non-portable about binary files is, as you note, straight dumps from memory. But this is not because they're binary, but because they're straight dumps. For a good example of how _not_ to create a file format, have a look at the mess that is BMP. Text files, by contrast, are rarely if ever specified to such detail. They just consist of lines, and the kind of line delimiter, or the allowable line length, is generally not specified. And yes, in a blind transfer, that _is_ non-portable - simply because of that _lack_ of specification. Of course, if you do it right, text files _can_ be ported; they just have to be transcribed on transfer. And this _is_ easier with text files than with badly specified binary files. Generally all you have to do is fudge the line endings, and in some cases, EOF markers or NUL padding. Quite simple if you know what you're doing, because there isn't much variation you can expect. That's also why _badly specified_ binary files are non-portable: because without a specification, you can expect almost anything to change, even between different iterations of the same system, never mind between PCs and mainframes. Let's be honest, which would you rather write: a utility to (read line, munge line ending, write line) repeat, write final line ending if not present; or one to read header, munge endianness, adjust padding, write header, (read record, munge endianness, adjust padding, write record) repeat, go back to header, adjust data in header for munged file sizes? Binary formats _need_ exact specification, and the good ones get it, and are therefore portable because you know _exactly_ what you get. Text formats don't need as much specification, and therefore are only universally portable with assistance, but only need a limited amount of assistance. _Bad_ binary formats are very hard to port reliably. Nothing ironic about it. Richard
[toc] | [prev] | [next] | [standalone]
Page 2 of 13 — ← Prev page 1 [2] 3 4 … 13 Next page →
Back to top | Article view | comp.lang.c
csiph-web