Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #67230 > unrolled thread
| Started by | fl <rxjwg98@gmail.com> |
|---|---|
| First post | 2015-08-12 15:28 -0700 |
| Last post | 2015-08-14 09:03 -0700 |
| Articles | 20 on this page of 164 — 27 participants |
Back to article view | Back to comp.lang.c
How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 15:28 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-12 23:52 +0100
Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:13 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 00:33 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:06 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-13 20:50 +0000
Re: How to read a data file whose size is unknown in C? Stephen Sprunk <stephen@sprunk.org> - 2015-08-17 13:38 -0500
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-17 14:48 -0400
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-18 11:10 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-18 15:01 +0100
Re: How to read a data file whose size is unknown in C? gordonb.8n5lc@burditt.org (Gordon Burditt) - 2015-08-14 02:33 -0500
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-14 10:06 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 09:14 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-14 21:27 +0000
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:52 +0200
Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-15 01:17 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 10:27 +0200
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-15 18:09 +0000
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:05 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 13:50 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 21:37 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:33 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-15 22:58 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 00:08 +0200
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-16 00:40 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-16 02:23 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:37 -0700
Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:35 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 10:31 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:21 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 23:31 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-16 03:38 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:29 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:46 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:03 -0700
Re: How to read a data file whose size is unknown in C? Nobody <nobody@nowhere.invalid> - 2015-08-16 03:23 +0100
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 00:56 -0700
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-17 01:08 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-17 10:20 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 09:01 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 11:31 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 14:01 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-15 22:28 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:29 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-16 10:50 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:40 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-16 20:22 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 21:27 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-17 01:31 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 20:25 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 16:29 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-17 23:43 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-17 18:20 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-17 19:10 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-18 05:26 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:23 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-18 04:23 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:39 -0700
Re: How to read a data file whose size is unknown in C? Ike Naar <ike@iceland.freeshell.org> - 2015-08-18 16:49 +0000
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-18 17:42 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-18 19:57 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-19 16:12 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-19 18:04 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-20 16:52 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-20 18:18 -0700
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-21 20:39 +0000
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-21 17:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-21 19:35 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:28 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-22 22:43 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 00:07 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-22 18:59 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 23:22 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-23 19:17 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-23 21:35 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 16:59 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-24 17:57 -0700
Re: How to read a data file whose size is unknown in C? Philip Lantz <prl@canterey.us> - 2015-08-25 01:09 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-25 19:03 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-25 22:16 -0400
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-26 14:29 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-26 18:28 -0400
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-26 19:25 -0700
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-27 10:07 +0200
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 09:18 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 18:04 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-27 11:15 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-27 21:10 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-27 15:54 -0700
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:28 +0200
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-27 13:12 -0600
Re: How to read a data file whose size is unknown in C? David Brown <david.brown@hesbynett.no> - 2015-08-28 09:35 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-25 04:28 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-24 00:19 -0400
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-24 00:31 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-24 17:06 -0700
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:25 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-22 10:45 -0400
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-21 17:40 -0400
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 00:40 -0400
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-19 05:38 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-19 10:20 -0400
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:22 +0000
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:21 +0000
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-14 08:48 -0400
Re: How to read a data file whose size is unknown in C? fl <rxjwg98@gmail.com> - 2015-08-12 16:21 -0700
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-12 19:44 -0600
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-12 22:04 -0400
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 00:44 +0100
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 01:04 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 11:31 +0100
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 11:51 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 08:49 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-13 17:45 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:11 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:34 +0100
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 12:21 -0500
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 19:07 +0100
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-14 16:08 -0500
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 09:51 +0200
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-15 12:36 -0700
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-15 22:26 +0200
Re: How to read a data file whose size is unknown in C? raltbos@xs4all.nl (Richard Bos) - 2015-08-22 14:26 +0000
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-22 08:11 -0700
Re: How to read a data file whose size is unknown in C? Robert Wessel <robertwessel2@yahoo.com> - 2015-08-16 00:05 -0500
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-16 09:08 -0400
Re: How to read a data file whose size is unknown in C? gazelle@shell.xmission.com (Kenny McCormack) - 2015-08-16 15:22 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-16 17:28 -0700
Re: How to read a data file whose size is unknown in C? Tonton Th <tTh@nowhere.invalid> - 2015-08-14 11:06 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:28 -0700
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 18:56 +0000
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 13:39 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 00:21 +0100
Re: How to read a data file whose size is unknown in C? Ian Collins <ian-news@hotmail.com> - 2015-08-14 12:26 +1200
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 11:00 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-14 11:30 +0100
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 12:31 +0100
Re: How to read a data file whose size is unknown in C? "Rick C. Hodgin" <rick.c.hodgin@gmail.com> - 2015-08-14 04:51 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:21 -0700
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 09:23 -0700
Re: How to read a data file whose size is unknown in C? David Kleinecke <dkleinecke@gmail.com> - 2015-08-14 16:57 -0700
Re: How to read a data file whose size is unknown in C? Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2015-08-15 14:49 -0600
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-15 19:31 -0700
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-14 00:35 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-14 08:57 -0700
Re: How to read a data file whose size is unknown in C? Bartc <bc@freeuk.com> - 2015-08-14 17:28 +0100
Re: How to read a data file whose size is unknown in C? glen herrmannsfeldt <gah@ugcs.caltech.edu> - 2015-08-13 00:12 +0000
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 07:03 +0200
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 12:38 +0200
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 13:32 +0100
Re: How to read a data file whose size is unknown in C? jacobnavia <jacob@jacob.remcomp.fr> - 2015-08-13 14:49 +0200
Re: How to read a data file whose size is unknown in C? Richard Heathfield <rjh@cpax.org.uk> - 2015-08-13 14:05 +0100
Re: How to read a data file whose size is unknown in C? Ben Bacarisse <ben.usenet@bsb.me.uk> - 2015-08-13 14:50 +0100
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:14 -0700
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:42 -0400
Re: How to read a data file whose size is unknown in C? Ken Brody <kenbrody@spamcop.net> - 2015-08-13 10:56 -0400
Re: How to read a data file whose size is unknown in C? Keith Thompson <kst-u@mib.org> - 2015-08-13 09:16 -0700
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <zsiga@nospam.for.me> - 2015-08-13 18:12 +0200
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 12:50 -0400
Re: How to read a data file whose size is unknown in C? Lőrinczy Zsigmond <nospam@for.me> - 2015-08-13 20:07 +0200
Re: How to read a data file whose size is unknown in C? James Kuyper <jameskuyper@verizon.net> - 2015-08-13 14:38 -0400
Re: How to read a data file whose size is unknown in C? John Bode <jfbode1029@gmail.com> - 2015-08-13 09:30 -0700
Re: How to read a data file whose size is unknown in C? Malcolm McLean <malcolm.mclean5@btinternet.com> - 2015-08-14 09:03 -0700
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 09:01 -0700 |
| Message-ID | <lnd1yl7vlo.fsf@kst-u.example.com> |
| In reply to | #67567 |
jacobnavia <jacob@jacob.remcomp.fr> writes:
[...]
> Look
> You used microsoft software. Other systems that do not use that do not
> have that problem.
>
> d:\lcc\tmp>type cz.c
> #include <stdio.h>
>
> int main()
> {
> FILE *f = fopen("x", "wb");
> fwrite("test\r\n\32line2\r\n", 1, 14, f);
> fclose(f);
>
> f = fopen("x", "r");
> char buf[20];
> int r = fread(buf, 1, 20, f);
> printf("r = %d\n", r);
> r = fread(buf, 1, 20, f);
> printf("r = %d\n", r);
>
> return 0;
> }
>
> I compile with lcc-win:
>
> d:\lcc\tmp>lc64 cz.c
>
> d:\lcc\tmp>cz
> r = 12
> r = 0
>
> d:\lcc\tmp>
>
> You see? Using software that does NOT INTERPRET the data and produces an
> EOF PROVES that windows, by itself, does NOT USE CTRL-Z as eof
> terminator and that you can without any problems read a file containing
> cotrl z beyond that character!
>
> The TYPE utility has been written using the Microsoft runtime. As many
> other programs. But that is a problem of THAT SPECIFIC RUNTIME and NOT
> of windows as an OS.
>
> Note that mingw/gcc uses also microsoft runtime.
So you're drawing a distinction between the Microsoft runtime and
the Microsoft Windows operating system (kernel?). That's a valid
distinction, but not one that matters to most users.
Similarly, the Linux operating system doesn't treat '\n' specially;
it's the runtime library that treats it as an end-of-line marker.
Would you then argue that '\n' is not a special character on Linux?
Woud you argue that Windows doesn't use CRLF as an end-of-line
marker, because it's handled by the runtime library, not by
"Windows"?
The vast majority of programs a user will encounter on Windows are
built to use the Microsoft runtime library. As far as a user is
concerned a Ctrl-Z character in a text file is treated as the end
of the file. As far as a user is concerned, the "type" command is
part of Windows.
For all practical purposes, a Ctrl-Z character in a Windows text file
is treated as the end of the file by programs that read it as text.
The fact that this behavior is implemented by the Microsoft runtime
and not by the Windows OS is interesting, but hardly relevant for
most purposes. Practically speaking, the Microsoft runtime is part
of the Windows operating system, even though program can be built
to use a different runtime.
It's also interesting that your own lcc-win runtime *doesn't* treat
Ctrl-Z as an end-of-file marker. All else being equal, I prefer
lcc-win's behavior -- but I wonder if the inconsistency with other
Windows programs might cause problems. I suspect such problems
would be rare (I don't think Ctrl-Z is commonly used in text files).
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-15 11:31 +0100 |
| Message-ID | <mqn4bl$9dl$1@dont-email.me> |
| In reply to | #67443 |
On 15/08/2015 01:17, Nobody wrote:
> Specifically, if a file is opened in text mode (i.e. no "b" in the second
> argument to fopen), the implementation will report EOF on encountering a
> Ctrl-Z character ('\x1a'). It does this because that's how CP/M indicates
> the end of a text file (the filesystem itself only stores file sizes in
> terms of the number of blocks, not bytes).
>
> And the value returned by ftell(fp) immediately following a call to
> fseek(fp, 0, SEEK_END) won't tell you where the first '\x1a' character is;
> it just reads the "size" from the directory entry. It also won't account
> for any CRLF ("\r\n") pairs which each get converted to a single '\n'
> character when reading from a file opened in text mode.
I haven't paid attention to text mode for a while, so was going to
suggest that you were wrong, and that, for reading, text mode expands LF
to CRLF, rather than compresses it.
But I've just done some tests and, astonishingly, you seem to be right!
Given two near identical 3-line files, one using LF line-endings on
disk, and the other CRLF, I get these results:
A B C
FILE1 (LF) 14 14 14
FILE2 (CRLF) 17 14 17
A Byte-size on disk
B Chars read in text mode
C Chars read in binary mode
Given that this is run under Windows, you might expect that an LF file
would expand newlines to CRLF. And that in text mode, a CRLF would be
read as CRLF!
And running under Linux, I get these results (the first 17 is assumed as
I don't know what option 'ls' needs to display a file size**):
FILE2 (CRLF) 17 17 17
So it doesn't even serve the purpose of a consistent representation, in
memory, of newlines encountered in the input.
It seems the only thing that is intuitive, that works as entirely
expected and is consistent, is that in binary mode, the number of
characters read matches that of the file on disk. Which is what I
normally use.
> At least both of these factors result in the fseek+ftell approach
> overestimating the size (defined by the number of characters which can be
> read) rather than underestimating it.
fstat does the same.
(** I've now done my homework and a google search suggests, amongst
answers intended for a different purpose, that the '-lh' switch can
display - in an approximate fashion - the file size. Of course!)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-15 14:01 -0700 |
| Message-ID | <ln8u9c9sgu.fsf@kst-u.example.com> |
| In reply to | #67452 |
Bartc <bc@freeuk.com> writes:
> On 15/08/2015 01:17, Nobody wrote:
>> Specifically, if a file is opened in text mode (i.e. no "b" in the second
>> argument to fopen), the implementation will report EOF on encountering a
>> Ctrl-Z character ('\x1a'). It does this because that's how CP/M indicates
>> the end of a text file (the filesystem itself only stores file sizes in
>> terms of the number of blocks, not bytes).
>>
>> And the value returned by ftell(fp) immediately following a call to
>> fseek(fp, 0, SEEK_END) won't tell you where the first '\x1a' character is;
>> it just reads the "size" from the directory entry. It also won't account
>> for any CRLF ("\r\n") pairs which each get converted to a single '\n'
>> character when reading from a file opened in text mode.
>
> I haven't paid attention to text mode for a while, so was going to
> suggest that you were wrong, and that, for reading, text mode expands LF
> to CRLF, rather than compresses it.
>
> But I've just done some tests and, astonishingly, you seem to be right!
I'm surprised that you're astonished.
Windows and Unix use different on-disk representations for text files.
Windows uses a CRLF pair to represent the end of a line; Unix uses a
single LF character.
C's stdio abstracts this representation away, so programmers don't have
to worry about it. In memory, an end-of-line is represented as a single
LF ('\n') character. Reading an end-of-line marker from a file in text
mode gives you a '\n' character; writing a '\n' characdter to a file in
text mode writes an end-of-line marker.
If you read and write locally valid text files using C's stdio, and
exercise some care by not making unwarranted assumptions (such as that
the value returned by ftell() reflects the number of characters you've
written or read), then you can easily write portable code that deals
with local text files on either Windows or Unix, or on any other system
your code might happen to run on.
You can, of course, read and write text files in binary mode, and do the
system-specific translation yourself. Sometimes that's necessary if you
might have to deal with "foreign" text files. But C's stdio is
specifically designed to avoid the need to do that.
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-15 22:28 +0100 |
| Message-ID | <mqoaq6$psf$1@dont-email.me> |
| In reply to | #67467 |
On 15/08/2015 22:01, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> I haven't paid attention to text mode for a while, so was going to
>> suggest that you were wrong, and that, for reading, text mode expands LF
>> to CRLF, rather than compresses it.
>>
>> But I've just done some tests and, astonishingly, you seem to be right!
>
> I'm surprised that you're astonished.
>
> Windows and Unix use different on-disk representations for text files.
> Windows uses a CRLF pair to represent the end of a line; Unix uses a
> single LF character.
That's not really relevant any more. A text file on disk (especially
after downloading from somewhere else) is going to have line-endings of
LF or CRLF, whatever the local OS is. (Sometimes, CR, but I haven't seen
those for a while. Maybe others too but I've never come across them at all.)
I use binary mode and try and cope with any of the main 3 combinations
on input.
> C's stdio abstracts this representation away, so programmers don't have
> to worry about it. In memory, an end-of-line is represented as a single
> LF ('\n') character.
Except that it doesn't work: a CRLF in a file read under Linux is read
as CRLF not LF, even in text mode.
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-15 19:29 -0700 |
| Message-ID | <lnr3n47yoy.fsf@kst-u.example.com> |
| In reply to | #67471 |
Bartc <bc@freeuk.com> writes:
> On 15/08/2015 22:01, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> I haven't paid attention to text mode for a while, so was going to
>>> suggest that you were wrong, and that, for reading, text mode expands LF
>>> to CRLF, rather than compresses it.
>>>
>>> But I've just done some tests and, astonishingly, you seem to be right!
>>
>> I'm surprised that you're astonished.
>>
>> Windows and Unix use different on-disk representations for text files.
>> Windows uses a CRLF pair to represent the end of a line; Unix uses a
>> single LF character.
>
> That's not really relevant any more. A text file on disk (especially
> after downloading from somewhere else) is going to have line-endings of
> LF or CRLF, whatever the local OS is. (Sometimes, CR, but I haven't seen
> those for a while. Maybe others too but I've never come across them at all.)
Yes, which is exactly why it's relevant.
> I use binary mode and try and cope with any of the main 3 combinations
> on input.
>
>> C's stdio abstracts this representation away, so programmers don't have
>> to worry about it. In memory, an end-of-line is represented as a single
>> LF ('\n') character.
>
> Except that it doesn't work: a CRLF in a file read under Linux is read
> as CRLF not LF, even in text mode.
It works fine for native format text files. The Linux end-of-line
marker is LF. If you have a CRLF pair in a Linux text file, it's
a CR character followed by an end-of-line marker. Reading it in
text mode treats it like that. I don't understand why you'd expect
different behavior.
C's stdio is not designed to handle multiple foreign text file
formats on one system. It's designed to handle native text files
on each system.
If you read text files in binary mode, and your input happens to be
in Window format, you'll see a CRLF pair at the end of each line.
The same program reading a Linux text file on a Linux system will see
just an LF character. Your program has to deal with the difference.
On output, you have to know what OS you're running on so you can
print either LF or CRLF at the end of each line.
If you read and write text files in text mode, each line ends with LF
('\n'), and that's all there is to it.
Do you really not see the advantage of that?
(BTW, the most recent system I'm aware of that used just CR as an
end-of-line marker was MacOS prior to OSX. Modern MacOS is Unix-based
and uses LF.)
--
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 | Bartc <bc@freeuk.com> |
|---|---|
| Date | 2015-08-16 10:50 +0100 |
| Message-ID | <mqpm9k$met$1@dont-email.me> |
| In reply to | #67514 |
On 16/08/2015 03:29, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
>> On 15/08/2015 22:01, Keith Thompson wrote:
>>> C's stdio abstracts this representation away, so programmers don't have
>>> to worry about it. In memory, an end-of-line is represented as a single
>>> LF ('\n') character.
>>
>> Except that it doesn't work: a CRLF in a file read under Linux is read
>> as CRLF not LF, even in text mode.
>
> It works fine for native format text files.
But you /don't know/ if the file you're reading happens to be native
format or not. These days, it could be anything.
The Linux end-of-line
> marker is LF. If you have a CRLF pair in a Linux text file, it's
> a CR character followed by an end-of-line marker. Reading it in
> text mode treats it like that. I don't understand why you'd expect
> different behavior.
I expect that when I read: ABC<newline>DEF<newline> in line-oriented
*text* mode, then I should end up with ("ABC","DEF"), not sometimes
("ABC<CR>","DEF<CR>"). The CR shouldn't be part of the data. This I see
as the sole advantage of using text mode, and it doesn't work!
So I use binary mode, and deal with LF, CRLF or CR newline separators
myself; it's not hard. (You say that CR is not used anymore; that makes
it even simpler.)
> C's stdio is not designed to handle multiple foreign text file
> formats on one system.
Exactly; it doesn't work. Although the most likely foreign file seems to
be LF-files under Windows, which is better-behaved (C is not fazed by
the lack of expected CRLF line endings, although I've only tested fgetc()).
CRLF under Unix is probably less common, but only because the world of
open source is dominated by programs that originated under Unix or
Linux. (Nevertheless, on my machine, I run virtual Linux within Windows,
and I am always copying CRLF files to Linux.)
--
Bartc
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-16 17:40 -0700 |
| Message-ID | <lnpp2m7nmx.fsf@kst-u.example.com> |
| In reply to | #67522 |
Bartc <bc@freeuk.com> writes:
> On 16/08/2015 03:29, Keith Thompson wrote:
>> Bartc <bc@freeuk.com> writes:
>>> On 15/08/2015 22:01, Keith Thompson wrote:
>
>>>> C's stdio abstracts this representation away, so programmers don't have
>>>> to worry about it. In memory, an end-of-line is represented as a single
>>>> LF ('\n') character.
>>>
>>> Except that it doesn't work: a CRLF in a file read under Linux is read
>>> as CRLF not LF, even in text mode.
>>
>> It works fine for native format text files.
>
> But you /don't know/ if the file you're reading happens to be native
> format or not. These days, it could be anything.
As I said, C's stdio doesn't deal with the problem of reading
foreign-format text files. If you really need to deal with them, you'll
have to do something other than reading them in text mode using stdio
functions. Translating them to native format *before* trying to read
them is one possibility, but that's not always practical.
> The Linux end-of-line
>> marker is LF. If you have a CRLF pair in a Linux text file, it's
>> a CR character followed by an end-of-line marker. Reading it in
>> text mode treats it like that. I don't understand why you'd expect
>> different behavior.
>
> I expect that when I read: ABC<newline>DEF<newline> in line-oriented
> *text* mode, then I should end up with ("ABC","DEF"), not sometimes
> ("ABC<CR>","DEF<CR>"). The CR shouldn't be part of the data. This I see
> as the sole advantage of using text mode, and it doesn't work!
In a Unix/Linux native text file, the end-of-line marker is a single LF
('\n') character. Other control characters may appear in text files;
for example, if I write a '\a' ('\x07', ASCII BEL) character to a text
file, I can expect to see a '\a' character when I read it back. The C
standard doesn't guarantee that, but it's a reasonable expectation on a
POSIX system.
A '\r' character in a Unix/Linux text file *is part of the data*.
I understand that you dislike that, but that's the way it is.
> So I use binary mode, and deal with LF, CRLF or CR newline separators
> myself; it's not hard. (You say that CR is not used anymore; that makes
> it even simpler.)
I'm not trying to say you can't do that; you obviously can. I just
think you're making things unnecessarily difficult for yourself. For
example, you have to be aware of the expected output format when
*writing* text; I don't. With the restrictions you choose to impose on
yourself, you can't even write a portable "hello, world" program.
>> C's stdio is not designed to handle multiple foreign text file
>> formats on one system.
>
> Exactly; it doesn't work.
No, it does work *as designed*. It doesn't solve every possible
problem. Nor does it shine your shoes for you.
> Although the most likely foreign file seems to
> be LF-files under Windows, which is better-behaved (C is not fazed by
> the lack of expected CRLF line endings, although I've only tested fgetc()).
>
> CRLF under Unix is probably less common, but only because the world of
> open source is dominated by programs that originated under Unix or
> Linux. (Nevertheless, on my machine, I run virtual Linux within Windows,
> and I am always copying CRLF files to Linux.)
I've seen plenty of Windows-format text files on Linux. It's annoying,
but most of the tools I use (including my preferred text editor and
compiler) handle them without too much difficulty, either because they
adapt to the format or because treat '\r' as whitespace and ignore it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-16 20:22 -0700 |
| Message-ID | <07514fdc-ec24-4c0e-b280-cc626b8d0c9b@googlegroups.com> |
| In reply to | #67553 |
On Sunday, August 16, 2015 at 5:15:03 PM UTC-7, Keith Thompson wrote:
> Bartc <bc@freeuk.com> writes:
> > On 16/08/2015 03:29, Keith Thompson wrote:
> >> Bartc <bc@freeuk.com> writes:
> >>> On 15/08/2015 22:01, Keith Thompson wrote:
> >
> >>>> C's stdio abstracts this representation away, so programmers don't have
> >>>> to worry about it. In memory, an end-of-line is represented as a single
> >>>> LF ('\n') character.
> >>>
> >>> Except that it doesn't work: a CRLF in a file read under Linux is read
> >>> as CRLF not LF, even in text mode.
> >>
> >> It works fine for native format text files.
> >
> > But you /don't know/ if the file you're reading happens to be native
> > format or not. These days, it could be anything.
>
> As I said, C's stdio doesn't deal with the problem of reading
> foreign-format text files. If you really need to deal with them, you'll
> have to do something other than reading them in text mode using stdio
> functions. Translating them to native format *before* trying to read
> them is one possibility, but that's not always practical.
>
> > The Linux end-of-line
> >> marker is LF. If you have a CRLF pair in a Linux text file, it's
> >> a CR character followed by an end-of-line marker. Reading it in
> >> text mode treats it like that. I don't understand why you'd expect
> >> different behavior.
> >
> > I expect that when I read: ABC<newline>DEF<newline> in line-oriented
> > *text* mode, then I should end up with ("ABC","DEF"), not sometimes
> > ("ABC<CR>","DEF<CR>"). The CR shouldn't be part of the data. This I see
> > as the sole advantage of using text mode, and it doesn't work!
>
> In a Unix/Linux native text file, the end-of-line marker is a single LF
> ('\n') character. Other control characters may appear in text files;
> for example, if I write a '\a' ('\x07', ASCII BEL) character to a text
> file, I can expect to see a '\a' character when I read it back. The C
> standard doesn't guarantee that, but it's a reasonable expectation on a
> POSIX system.
>
> A '\r' character in a Unix/Linux text file *is part of the data*.
> I understand that you dislike that, but that's the way it is.
>
> > So I use binary mode, and deal with LF, CRLF or CR newline separators
> > myself; it's not hard. (You say that CR is not used anymore; that makes
> > it even simpler.)
>
> I'm not trying to say you can't do that; you obviously can. I just
> think you're making things unnecessarily difficult for yourself. For
> example, you have to be aware of the expected output format when
> *writing* text; I don't. With the restrictions you choose to impose on
> yourself, you can't even write a portable "hello, world" program.
>
> >> C's stdio is not designed to handle multiple foreign text file
> >> formats on one system.
> >
> > Exactly; it doesn't work.
>
> No, it does work *as designed*. It doesn't solve every possible
> problem. Nor does it shine your shoes for you.
>
> > Although the most likely foreign file seems to
> > be LF-files under Windows, which is better-behaved (C is not fazed by
> > the lack of expected CRLF line endings, although I've only tested fgetc()).
> >
> > CRLF under Unix is probably less common, but only because the world of
> > open source is dominated by programs that originated under Unix or
> > Linux. (Nevertheless, on my machine, I run virtual Linux within Windows,
> > and I am always copying CRLF files to Linux.)
>
> I've seen plenty of Windows-format text files on Linux. It's annoying,
> but most of the tools I use (including my preferred text editor and
> compiler) handle them without too much difficulty, either because they
> adapt to the format or because treat '\r' as whitespace and ignore it.
>
> --
> Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
> Working, but not speaking, for JetHead Development, Inc.
> "We must do something. This is something. Therefore, we must do this."
> -- Antony Jay and Jonathan Lynn, "Yes Minister"
This confusion (CR annd LN) might be used to make writing a text
processor easier by freeing up CR to indicate soft (as in word-wrap)
end-of-lines. It is pretty much guaranteed that CR will not be used
for anything else.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-16 21:27 -0700 |
| Message-ID | <lnh9ny7d5n.fsf@kst-u.example.com> |
| In reply to | #67558 |
David Kleinecke <dkleinecke@gmail.com> writes:
[...]
>> I've seen plenty of Windows-format text files on Linux. It's annoying,
>> but most of the tools I use (including my preferred text editor and
>> compiler) handle them without too much difficulty, either because they
>> adapt to the format or because treat '\r' as whitespace and ignore it.
>
> This confusion (CR annd LN) might be used to make writing a text
> processor easier by freeing up CR to indicate soft (as in word-wrap)
> end-of-lines. It is pretty much guaranteed that CR will not be used
> for anything else.
I don't think that's a good idea. A CR character in a text file is very
likely to be there because it was created on Windows; giving it some
inconsistent special meaning on Unix would likely cause even more
confusion than we have now. I'm not even sure what a "soft (as in
word-wrap) end-of-line" would be, but in any case I'm sure there's a
better way to represent it.
--
Keith Thompson (The_Other_Keith) kst-u@mib.org <http://www.ghoti.net/~kst>
Working, but not speaking, for JetHead Development, Inc.
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-17 01:31 -0700 |
| Message-ID | <feab4575-560c-46ea-99cb-e724c6db40d2@googlegroups.com> |
| In reply to | #67561 |
On Monday, August 17, 2015 at 5:00:02 AM UTC+1, Keith Thompson wrote:
>
> I don't think that's a good idea. A CR character in a text file is very
> likely to be there because it was created on Windows; giving it some
> inconsistent special meaning on Unix would likely cause even more
> confusion than we have now. I'm not even sure what a "soft (as in
> word-wrap) end-of-line" would be, but in any case I'm sure there's a
> better way to represent it.
>
In flowing text, a hard end of line indicates a paragraph end,
that should be followed either by an indentation or one or more
blank lines.
A soft end of line indicates that the writer has run out of space
and must wrap to the next line. Some brain dead or special-purpose
editors, such as the one I'm typing this at, won't wrap sensibly and
automatically, so you have to type returns, as at a manual typewriter.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-17 20:25 +0000 |
| Message-ID | <mqtfvv$d9$1@speranza.aioe.org> |
| In reply to | #67561 |
Keith Thompson <kst-u@mib.org> wrote: > David Kleinecke <dkleinecke@gmail.com> writes: (snip) >> This confusion (CR annd LN) might be used to make writing a text >> processor easier by freeing up CR to indicate soft (as in word-wrap) >> end-of-lines. It is pretty much guaranteed that CR will not be used >> for anything else. > I don't think that's a good idea. A CR character in a text file is very > likely to be there because it was created on Windows; giving it some > inconsistent special meaning on Unix would likely cause even more > confusion than we have now. I'm not even sure what a "soft (as in > word-wrap) end-of-line" would be, but in any case I'm sure there's a > better way to represent it. Some versions of vi recognize files with CRLF line terminators, read the file in without them, then rewrite them when you save. That means you can't edit the CR. -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 16:29 -0700 |
| Message-ID | <ln1tf15wan.fsf@kst-u.example.com> |
| In reply to | #67627 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>> David Kleinecke <dkleinecke@gmail.com> writes:
>
> (snip)
>>> This confusion (CR annd LN) might be used to make writing a text
>>> processor easier by freeing up CR to indicate soft (as in word-wrap)
>>> end-of-lines. It is pretty much guaranteed that CR will not be used
>>> for anything else.
>
>> I don't think that's a good idea. A CR character in a text file is very
>> likely to be there because it was created on Windows; giving it some
>> inconsistent special meaning on Unix would likely cause even more
>> confusion than we have now. I'm not even sure what a "soft (as in
>> word-wrap) end-of-line" would be, but in any case I'm sure there's a
>> better way to represent it.
>
> Some versions of vi recognize files with CRLF line terminators,
> read the file in without them, then rewrite them when you save.
>
> That means you can't edit the CR.
At least for vim, and at least under Linux, you can override that using
the "-b" (binary) option.
--
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 | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-17 23:43 +0000 |
| Message-ID | <mqtrjn$oeb$1@speranza.aioe.org> |
| In reply to | #67650 |
Keith Thompson <kst-u@mib.org> wrote: (snip) >> Some versions of vi recognize files with CRLF line terminators, >> read the file in without them, then rewrite them when you save. >> That means you can't edit the CR. > At least for vim, and at least under Linux, you can override that using > the "-b" (binary) option. Good to know. It hasn't happened to me recently, but last time it did I didn't know the override. Is there also a set command for it? thanks, -- glen
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <kst-u@mib.org> |
|---|---|
| Date | 2015-08-17 18:20 -0700 |
| Message-ID | <lnoai54ckb.fsf@kst-u.example.com> |
| In reply to | #67658 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:
> Keith Thompson <kst-u@mib.org> wrote:
>
> (snip)
>>> Some versions of vi recognize files with CRLF line terminators,
>>> read the file in without them, then rewrite them when you save.
>
>>> That means you can't edit the CR.
>
>> At least for vim, and at least under Linux, you can override that using
>> the "-b" (binary) option.
>
> Good to know. It hasn't happened to me recently, but last time it
> did I didn't know the override.
>
> Is there also a set command for it?
Yes, there's ":set binary", but if you enter it after loading the file
it's too late; the CRs have already been stripped.
$ vim dosfile.txt
:set binary
vim has an extensive built-in help system (":help", ":help binary",
etc.) -- and this isn't exactly topical.
--
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 Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-17 19:10 -0700 |
| Message-ID | <305bb403-c869-4f2f-bf0d-39e1b0f10468@googlegroups.com> |
| In reply to | #67561 |
On Sunday, August 16, 2015 at 9:00:02 PM UTC-7, Keith Thompson wrote: > David Kleinecke <dkleinecke@gmail.com> writes: > [...] > >> I've seen plenty of Windows-format text files on Linux. It's annoying, > >> but most of the tools I use (including my preferred text editor and > >> compiler) handle them without too much difficulty, either because they > >> adapt to the format or because treat '\r' as whitespace and ignore it. > > > > This confusion (CR annd LN) might be used to make writing a text > > processor easier by freeing up CR to indicate soft (as in word-wrap) > > end-of-lines. It is pretty much guaranteed that CR will not be used > > for anything else. > > I don't think that's a good idea. A CR character in a text file is very > likely to be there because it was created on Windows; giving it some > inconsistent special meaning on Unix would likely cause even more > confusion than we have now. I'm not even sure what a "soft (as in > word-wrap) end-of-line" would be, but in any case I'm sure there's a > better way to represent it. I yield to no one in my disdain for Windows. In order to mark the soft EOL I must make a pass throught the text. On that pass I can check for CR. The only CR I expect to see are the first half of a CR+LF. If I am copying as I go I just don't copy it. If I am reading a text I can do any number of things. I have to have some strategy to handle unexpected characters (except in the corner case where I am implementing a text in a 253 character alphabet). I usually suppose there is some other unused character whose glyph has zero width and chnage the CR to that. Alternativly I could some other non-ASCII character (CTRL-Z, for example for soft EOL. The downside here is lines that have no spaces for a wrap to be made in. Overwriting a character with a soft EOL loses data. There are various things I could do to correct this. The most promising if I am reading a text read in seems to be do my soft EOL's some other way. That suggests copying the input text. Desiging a text processor is fun - there are so many things to keep track of.
[toc] | [prev] | [next] | [standalone]
| From | glen herrmannsfeldt <gah@ugcs.caltech.edu> |
|---|---|
| Date | 2015-08-18 05:26 +0000 |
| Message-ID | <mqufli$r80$1@speranza.aioe.org> |
| In reply to | #67669 |
David Kleinecke <dkleinecke@gmail.com> wrote: > On Sunday, August 16, 2015 at 9:00:02 PM UTC-7, Keith Thompson wrote: (snip on uses for '\r') >> I don't think that's a good idea. A CR character in a text file is very >> likely to be there because it was created on Windows; giving it some >> inconsistent special meaning on Unix would likely cause even more >> confusion than we have now. I'm not even sure what a "soft (as in >> word-wrap) end-of-line" would be, but in any case I'm sure there's a >> better way to represent it. > I yield to no one in my disdain for Windows. Yes, but I blame DEC for this one. It has the advantage that you can send files to teletypes without conversion, but that seems a small advantage to me. From DEC to CP/M to DOS to Windows. -- glen
[toc] | [prev] | [next] | [standalone]
| From | raltbos@xs4all.nl (Richard Bos) |
|---|---|
| Date | 2015-08-22 14:23 +0000 |
| Message-ID | <55d8858d.20340125@news.xs4all.nl> |
| In reply to | #67672 |
glen herrmannsfeldt <gah@ugcs.caltech.edu> wrote: > David Kleinecke <dkleinecke@gmail.com> wrote: > > On Sunday, August 16, 2015 at 9:00:02 PM UTC-7, Keith Thompson wrote: > > (snip on uses for '\r') > > >> I don't think that's a good idea. A CR character in a text file is very > >> likely to be there because it was created on Windows; giving it some > >> inconsistent special meaning on Unix would likely cause even more > >> confusion than we have now. I'm not even sure what a "soft (as in > >> word-wrap) end-of-line" would be, but in any case I'm sure there's a > >> better way to represent it. > > > I yield to no one in my disdain for Windows. > > Yes, but I blame DEC for this one. It has the advantage that you can > send files to teletypes without conversion, but that seems a small > advantage to me. It is now. It wasn't then. Richard
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.mclean5@btinternet.com> |
|---|---|
| Date | 2015-08-18 04:23 -0700 |
| Message-ID | <ac1c699d-81ce-4548-b607-4a326a5dc83a@googlegroups.com> |
| In reply to | #67669 |
On Tuesday, August 18, 2015 at 3:10:58 AM UTC+1, David Kleinecke wrote: > > I yield to no one in my disdain for Windows. > > In order to mark the soft EOL I must make a pass throught the text. On > that pass I can check for CR. The only CR I expect to see are the first > half of a CR+LF. > That's actually a nice little utility to write. You are given text with hard newlines. The task is to mark the soft ones as soft and the hard ones as hard. The program is considered correct if a human considers rewrapped text to be right. It's not a fully specified problem, in that there will always be a few inputs where it goes wrong. But I think we should be able to get most texts right.
[toc] | [prev] | [next] | [standalone]
| From | David Kleinecke <dkleinecke@gmail.com> |
|---|---|
| Date | 2015-08-18 17:39 -0700 |
| Message-ID | <255d2242-3d6a-46ac-b419-29b4771c0acb@googlegroups.com> |
| In reply to | #67702 |
On Tuesday, August 18, 2015 at 4:24:04 AM UTC-7, Malcolm McLean wrote: > On Tuesday, August 18, 2015 at 3:10:58 AM UTC+1, David Kleinecke wrote: > > > > I yield to no one in my disdain for Windows. > > > > In order to mark the soft EOL I must make a pass throught the text. On > > that pass I can check for CR. The only CR I expect to see are the first > > half of a CR+LF. > > > That's actually a nice little utility to write. > > You are given text with hard newlines. The task is to mark the soft ones > as soft and the hard ones as hard. The program is considered correct > if a human considers rewrapped text to be right. > > It's not a fully specified problem, in that there will always be > a few inputs where it goes wrong. But I think we should be able to > get most texts right. Modulo line length.
[toc] | [prev] | [next] | [standalone]
| From | Ike Naar <ike@iceland.freeshell.org> |
|---|---|
| Date | 2015-08-18 16:49 +0000 |
| Message-ID | <slrn3vfsmt6oj2.7e7.ike@iceland.freeshell.org> |
| In reply to | #67669 |
On 2015-08-18, David Kleinecke <dkleinecke@gmail.com> wrote: > Alternativly I could some other non-ASCII character (CTRL-Z, for example > for soft EOL. CTRL-Z *is* an ASCII character (SUB, code point 26(decimal) or 1A(hex)).
[toc] | [prev] | [next] | [standalone]
Page 3 of 9 — ← Prev page 1 2 [3] 4 5 6 7 8 9 Next page →
Back to top | Article view | comp.lang.c
csiph-web