Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #380602 > unrolled thread
| Started by | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| First post | 2024-01-22 01:51 +0000 |
| Last post | 2024-01-25 15:02 +0100 |
| Articles | 20 on this page of 649 — 20 participants |
Back to article view | Back to comp.lang.c
iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 01:51 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-22 02:00 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-21 21:48 -0500
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 05:23 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-22 09:30 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-22 16:24 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 20:34 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 13:22 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 22:07 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-22 14:56 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 23:44 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 00:10 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 20:34 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-22 21:32 +0000
Re: iso646.h Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-22 23:08 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-22 23:37 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 00:12 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-23 06:54 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:05 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:34 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 15:43 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-22 20:23 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-23 06:47 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:50 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:59 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-23 09:24 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:30 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 22:03 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:53 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 07:58 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:11 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:23 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 21:55 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 07:22 +0100
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 20:25 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:17 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-25 00:50 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:23 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 01:33 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:20 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 16:56 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:07 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:12 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:08 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 10:03 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 11:54 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-23 16:32 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-23 17:21 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 21:49 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:52 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 14:51 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:33 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 16:16 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:39 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 11:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:15 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:02 +0100
C/CPP macro conventions (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:25 +0100
Re: C/CPP macro conventions (was Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 08:25 +0000
Re: C/CPP macro conventions (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 10:09 +0100
Re: C/CPP macro conventions (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-24 10:13 +0100
Re: C/CPP macro conventions (was Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-25 23:05 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 18:34 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 18:52 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 14:23 -0500
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 20:32 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:52 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 22:09 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:37 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:10 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-24 12:24 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:38 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 18:42 +0100
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 17:49 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 18:40 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:15 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 22:01 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 11:52 -0800
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 20:03 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:14 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:11 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-25 00:01 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 13:43 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 14:19 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:20 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 16:40 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 13:43 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:11 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 11:35 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:09 +0100
Unix shell conditionals (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 08:38 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 21:28 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 22:00 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-23 22:33 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-23 23:46 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 14:49 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 19:45 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:28 +0100
Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 19:32 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-23 19:59 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 20:18 +0000
Re: Python (Re: iso646.h) Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2024-01-24 07:49 -0700
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 15:07 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 15:17 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 15:46 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 16:27 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 19:55 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 20:57 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:17 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 12:13 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 14:57 +0000
Re: Python (Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-25 16:17 +0100
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 15:52 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 16:14 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:27 -0800
Re: Python (Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 18:06 +0000
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 19:35 +0000
Re: Python (Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 15:56 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 12:09 -0800
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 22:00 +0000
Re: Python (Re: iso646.h) Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-27 22:12 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 00:29 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:55 +0000
Re: Python (Re: iso646.h) kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:47 +0000
Re: Python (Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:35 -0800
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:41 +0000
Re: Python (Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 03:13 +0000
Re: Python (Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:37 +0000
Re: Python (Re: iso646.h) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-26 05:48 -0800
Re: Python (Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 23:51 +0000
Re: Python (Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-23 16:35 -0800
Re: Python (Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-23 16:40 -0800
Re: Python (Re: iso646.h) bart <bc@freeuk.com> - 2024-01-24 00:06 +0000
Re: Python (Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-24 12:37 +0100
Re: Python (Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-25 22:55 +0000
Re: Python (Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-24 13:30 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 12:13 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 22:01 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-23 22:45 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:39 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-23 22:54 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 15:10 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 23:40 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 16:27 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 00:47 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 17:32 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 02:42 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 23:56 -0500
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 05:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 21:43 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 06:35 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 14:14 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:19 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 07:34 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-23 23:26 -0500
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-23 20:53 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:41 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:15 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 19:32 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 09:06 +0100
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 14:17 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:30 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 21:00 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 22:13 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:44 +0000
Re: COBOL (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 01:37 +0000
Re: COBOL (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-25 02:20 +0000
Re: COBOL (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:23 -0800
Re: COBOL (was Re: iso646.h) bart <bc@freeuk.com> - 2024-01-25 11:58 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 02:49 +0000
Re: COBOL (was Re: iso646.h) Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 19:09 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 17:44 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 17:27 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-24 20:21 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:26 -0800
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-24 20:31 +0000
Re: COBOL (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:53 +0000
Re: COBOL (was Re: iso646.h) Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:24 +0000
Re: COBOL (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 18:21 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 22:09 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 23:20 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 15:56 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 12:20 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-24 13:00 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-24 14:22 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-24 14:54 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 08:27 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-24 20:50 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:01 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 13:53 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:48 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 09:57 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 21:07 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:18 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 15:59 +0100
Re: Compose Key (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 21:22 +0000
Re: Compose Key (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-27 16:17 +0100
Re: Compose Key (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:28 +0000
Re: Compose Key (was Re: iso646.h) Blue-Maned_Hawk <bluemanedhawk@invalid.invalid> - 2024-01-27 22:38 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:08 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 20:30 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 21:13 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 20:06 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 21:04 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 21:16 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 22:01 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:11 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-26 01:19 +0000
Operators (Algol 68) (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:08 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-25 00:52 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 17:07 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 07:48 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:07 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 14:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 16:53 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-25 17:11 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 21:11 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 02:21 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:01 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 18:31 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 19:59 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 12:27 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:01 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:30 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:22 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:43 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 20:14 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 14:09 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:10 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:44 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:49 +0000
Re: Functional Programming (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 00:22 +0000
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:18 +0000
Re: Functional Programming (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 02:06 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-28 12:35 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:40 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-01-29 09:52 +0100
Re: Functional Programming (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:13 +0000
Re: Functional Programming (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-02 09:21 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-28 01:31 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:40 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 21:16 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 22:46 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 22:41 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 15:41 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 23:51 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:17 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 16:25 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:46 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-26 23:52 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:27 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 00:38 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:09 +0100
Re: Localization (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:58 +0000
Re: Localization (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 15:57 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 16:58 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 17:26 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 18:53 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 19:39 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:31 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:50 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 20:59 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:34 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:50 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:53 -0800
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-27 18:47 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 12:53 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:43 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 14:49 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 00:03 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-29 01:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 17:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 02:17 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:05 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:56 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 13:35 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-29 16:23 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 18:40 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 16:33 -0800
Re: iso646.h bart <bc@freeuk.com> - 2024-01-27 00:42 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:16 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-27 17:24 +0000
Re: Java (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:04 +0000
[OT] Re: Java (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 17:42 +0100
Re: [OT] Re: Java (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:44 +0000
[OT] Usefulness of OO/C++/features (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 17:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:11 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:43 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 11:13 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 12:53 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 20:17 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-27 21:40 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 00:31 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:22 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 22:55 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 15:00 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-29 12:09 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-29 19:33 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 12:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:51 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-29 12:10 -0500
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 12:53 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-27 21:06 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 00:35 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 01:22 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:26 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 01:59 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 13:00 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 16:09 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 19:24 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-28 19:49 +0000
Re: Binary Pipelines (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-28 20:48 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-28 14:54 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 18:47 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 21:06 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-29 13:00 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 18:29 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:23 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 12:06 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 21:04 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:04 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 08:59 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 12:53 +0200
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:21 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:02 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:05 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 11:30 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 18:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 22:41 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 01:59 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-29 23:55 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-29 12:10 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 22:14 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-29 22:24 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-29 23:27 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 09:13 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 14:03 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 15:49 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:06 +0000
Re: iso646.h Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-01-30 16:12 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 16:33 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:54 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:39 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:12 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-31 01:39 -0500
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:20 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 14:47 +0100
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-31 19:43 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 12:14 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-31 20:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 13:26 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 01:23 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 01:34 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 16:28 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 23:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 15:34 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:58 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 18:27 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:52 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 16:01 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:13 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:15 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:08 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 15:28 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-02 16:50 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-01 00:52 -0500
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-02-01 00:45 -0500
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 17:25 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 16:55 +0000
Creation era of stdin, stdout, stderr (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-30 19:06 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:29 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 20:24 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 12:55 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 21:42 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:10 +0000
Re: iso646.h dave_thompson_2@comcast.net - 2024-02-26 04:20 -0500
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 17:34 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 18:43 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-30 20:54 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:07 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:45 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:20 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:38 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:05 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 00:08 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:10 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 02:12 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:42 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-02 03:47 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 20:02 -0800
Re: iso646.h dave_thompson_2@comcast.net - 2024-02-26 04:18 -0500
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:00 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 15:21 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:53 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:03 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 15:28 +0200
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 15:30 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 15:54 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 16:10 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 17:49 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-01-30 18:22 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-30 18:44 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 20:46 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:22 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 14:58 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 15:39 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-30 18:39 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-01-30 19:45 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 11:59 -0800
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-30 16:16 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:35 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 15:09 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 15:46 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:11 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 10:35 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 11:34 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 17:24 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 22:46 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:29 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:41 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:06 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:00 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:15 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-30 11:50 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:02 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 12:43 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 13:58 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 13:35 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 15:10 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 18:19 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 19:53 +0200
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:49 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:17 +0000
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-31 11:20 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 18:06 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-01 23:52 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:16 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-31 06:06 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-01-30 23:18 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 08:36 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 15:21 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:15 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 16:25 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:58 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:17 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:05 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:26 +0200
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:27 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:01 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:24 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:18 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-31 19:20 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 02:48 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 07:16 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 13:17 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 16:04 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 08:33 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 23:48 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 16:49 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:10 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 17:36 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 02:23 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 18:30 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:49 +0000
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:24 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:07 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:18 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 23:57 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 13:34 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-03 11:27 -0800
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 12:43 +0200
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 12:15 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 13:49 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 17:03 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:49 +0000
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:04 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 16:54 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-31 09:16 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:21 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-31 15:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:29 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 19:36 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:25 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 16:33 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 17:42 +0200
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 15:58 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:05 +0100
Re: iso646.h Michael S <already5chosen@yahoo.com> - 2024-01-31 18:18 +0200
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 17:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 17:20 +0000
[OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 20:11 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 19:28 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:12 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) bart <bc@freeuk.com> - 2024-02-01 12:50 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 04:57 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 07:18 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:44 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-02 09:34 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) bart <bc@freeuk.com> - 2024-02-02 10:57 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-03 01:43 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-03 12:47 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-04 22:36 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 15:26 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-05 01:49 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-04 18:08 -0800
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 15:04 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:16 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-31 20:16 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Michael S <already5chosen@yahoo.com> - 2024-01-31 22:22 +0200
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) scott@slp53.sl.home (Scott Lurndal) - 2024-01-31 20:50 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Michael S <already5chosen@yahoo.com> - 2024-01-31 23:00 +0200
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-01-31 21:20 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:27 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:16 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) cross@spitfire.i.gajendra.net (Dan Cross) - 2024-02-01 13:21 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) David Brown <david.brown@hesbynett.no> - 2024-02-01 11:45 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 13:03 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 04:58 +0000
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:22 -0800
[meta] Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 15:38 +0100
Re: [OT] Unix shells and POSIX shell (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:00 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-31 19:22 +0100
Re: iso646.h Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-02-01 05:17 -0800
Re: Alternative Shells (was Re: iso646.h) Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 05:04 +0000
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-01-31 23:36 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 00:21 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 00:47 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 01:29 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:42 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:50 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 17:06 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 23:02 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 22:56 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:13 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 09:44 +0100
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-02-02 01:08 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:35 +0100
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 15:32 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:23 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 03:26 +0100
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 23:41 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 01:53 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:45 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 14:57 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:47 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 16:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 15:55 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:41 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 17:15 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 19:36 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-01 19:50 +0000
Re: iso646.h Richard Harnden <richard.nospam@gmail.invalid> - 2024-02-01 20:03 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 23:06 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 22:38 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 09:51 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 13:28 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-02 15:47 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-02 15:38 +0000
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 23:38 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-02-02 23:59 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 05:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 14:02 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 13:26 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-01 16:07 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 15:50 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 16:30 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 18:03 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 12:09 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 20:59 +0000
Re: iso646.h bart <bc@freeuk.com> - 2024-02-01 21:25 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 13:34 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 22:25 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-02-01 14:40 -0800
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-01 15:31 -0800
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 22:24 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 12:41 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-02-02 08:39 -0800
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-02-02 12:33 +0100
Re: iso646.h Ben Bacarisse <ben.usenet@bsb.me.uk> - 2024-02-02 21:40 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-03 05:14 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-02-01 16:48 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-02-01 16:19 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-02-01 14:53 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 18:02 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 19:33 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 19:45 +0000
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-24 19:48 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:30 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 03:56 +0000
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 05:25 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 07:02 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:46 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 14:29 +0100
Re: iso646.h kalevi@kolttonen.fi (Kalevi Kolttonen) - 2024-01-25 15:08 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 16:18 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 11:20 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 12:17 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 07:56 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 23:03 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:06 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-26 18:59 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 20:18 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-26 23:15 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-26 15:55 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 17:07 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-27 17:34 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-28 13:02 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 01:12 +0100
Re: iso646.h James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-01-26 20:43 -0500
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:21 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 03:05 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 11:34 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-27 11:02 +0000
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-27 12:36 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 18:32 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 19:48 +0100
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-29 19:35 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 21:10 +0100
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-29 22:27 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-30 10:05 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-27 17:46 +0100
Re: iso646.h Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-01-28 20:16 +0100
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-29 17:20 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 10:48 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-23 21:51 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-24 19:48 +0000
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-24 19:52 +0000
Re: iso646.h "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-01-24 13:00 -0800
Re: iso646.h Lawrence D'Oliveiro <ldo@nz.invalid> - 2024-01-25 00:26 +0000
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 01:25 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 12:09 -0800
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 03:46 +0000
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-24 19:59 -0800
Re: iso646.h Kaz Kylheku <433-929-6894@kylheku.com> - 2024-01-25 05:39 +0000
Re: iso646.h Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2024-01-25 09:55 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:19 +0100
Re: iso646.h Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-01-25 07:26 -0800
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-26 17:12 +0100
Re: iso646.h scott@slp53.sl.home (Scott Lurndal) - 2024-01-25 16:22 +0000
Re: iso646.h David Brown <david.brown@hesbynett.no> - 2024-01-25 15:02 +0100
Page 29 of 33 — ← Prev page 1 … 27 28 [29] 30 31 … 33 Next page →
| From | Richard Harnden <richard.nospam@gmail.invalid> |
|---|---|
| Date | 2024-02-01 20:03 +0000 |
| Message-ID | <upgtff$2764a$1@dont-email.me> |
| In reply to | #381505 |
On 01/02/2024 19:50, Kaz Kylheku wrote:
> On 2024-02-01, Scott Lurndal <scott@slp53.sl.home> wrote:
>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>>> On 01.02.2024 16:41, Malcolm McLean wrote:
>>>>
>>>> So could you list one or two reasons why you might prefer a program with
>>>> five subroutines, and one or two reasons why you might prefer to write
>>>> five programs which communicate via piped data?
>>>
>>> A quite appealing and naturally appearing task (from the past) to use
>>> pipes was to model communication cascades. Something like (off the top
>>> of my head)...
>>>
>>> data-source | sign | compress | crc | encrypt | channel-enc |
>>> interleaver | channel-simulator | deinterleaver | channel-dec |
>>> decrypt | crc-check | uncompress | check-sign | data-sink
>>>
>>> Component-pairs can be omitted, say you may leave out the un-/compress
>>> function. And every component may be either special purpose or general.
>>> A special purpose entity could be BCH-enc and RCPC-enc, or it can also
>>> be (if better suited) a combined module, say 'crc -16' vs. 'crc -32'
>>> with the function realized as option argument.
>>
>> There was also the widely used netpbm package for translating
>> between different image formats.
>>
>> https://en.wikipedia.org/wiki/Netpbm
>>
>> $ giftopnm somepic.gif | ppmtobmp > somepic.bmp
>> $ for i in *.png; do pngtopam $i | ppmtojpeg >`basename $i .png`.jpg; done
>
> Also, in regard to some silly objections upthread about the danger of
> binary data on standard ouptut, programs in Unix can easily do the
> Following (and arguably should):
>
> if (isatty(STDOUT_FILENO)) {
> fprintf(stderr, "Cowardly refusing to dump binary data to a terminal.\n");
> exit(EXIT_FAILURE);
> }
>
Yes, so common that the shell has test -t
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 23:06 +0100 |
| Message-ID | <uph4kp$28ebd$2@dont-email.me> |
| In reply to | #381482 |
On 01/02/2024 16:41, Malcolm McLean wrote: > On 01/02/2024 14:55, David Brown wrote: >> On 01/02/2024 02:53, Malcolm McLean wrote: >>> On 31/01/2024 23:36, Ben Bacarisse wrote: >>>> >>>> An example where it's really useful not to care: I have a suite of >>>> tools >>>> for doing toy cryptanalysis. Some apply various transformations and/or >>>> filters to byte streams and others collect and output (on stderr) >>>> various statistics. Plugging them together in various pipelines is >>>> very >>>> handy when investigating an encrypted text. The output is almost >>>> always >>>> "binary" in the sense that there would be not point in looking at on a >>>> terminal. >>>> >>>> According to you, these tools are poorly designed. I don't think so. >>>> How would you design them? Endless input and output file names to be >>>> juggled and tidied up afterwards? >>>> >>> I'd write a monolithic program. >> >> It's very strange to me to see people that consider themselves >> programmers talk about having multiple small functions to do specific >> tasks and combining them into bigger functions to solve bigger >> problems, yet are reduced to quivering jellies at the thought of >> multiple small programs to do specific tasks that can be combined to >> solve bigger tasks. >> >> Do you think the C standard library would be improved by a single >> function "flubadub" that takes 20 parameters and can calculate >> logarithms, print formatted text, allocate memory and write it all to >> a file? >> > By breaking down the problem into several parts e.g. "collect > statistical data, analyse statistics, form hypothesis, attempt > decryption, check decrypt for plausible plaintext" we can usually attack > it better. And you're right, there's not a fundamental difference > between writing one program with five subroutines, or five programs > which pass data to each other via pipelines. That's not what I said. Try re-reading. I can't be bothered arguing against yet another straw man. > But that doesn't mean that decision must not be made, or that you can't > give reasons for and against each option. > > So could you list one or two reasons why you might prefer a program with > five subroutines, and one or two reasons why you might prefer to write > five programs which communicate via piped data?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 22:38 +0000 |
| Message-ID | <uph6hf$28p5f$1@dont-email.me> |
| In reply to | #381527 |
On 01/02/2024 22:06, David Brown wrote: > On 01/02/2024 16:41, Malcolm McLean wrote: >> On 01/02/2024 14:55, David Brown wrote: >>> On 01/02/2024 02:53, Malcolm McLean wrote: >>>> On 31/01/2024 23:36, Ben Bacarisse wrote: >>>>> >>>>> An example where it's really useful not to care: I have a suite of >>>>> tools >>>>> for doing toy cryptanalysis. Some apply various transformations >>>>> and/or >>>>> filters to byte streams and others collect and output (on stderr) >>>>> various statistics. Plugging them together in various pipelines is >>>>> very >>>>> handy when investigating an encrypted text. The output is almost >>>>> always >>>>> "binary" in the sense that there would be not point in looking at on a >>>>> terminal. >>>>> >>>>> According to you, these tools are poorly designed. I don't think so. >>>>> How would you design them? Endless input and output file names to be >>>>> juggled and tidied up afterwards? >>>>> >>>> I'd write a monolithic program. >>> >>> It's very strange to me to see people that consider themselves >>> programmers talk about having multiple small functions to do specific >>> tasks and combining them into bigger functions to solve bigger >>> problems, yet are reduced to quivering jellies at the thought of >>> multiple small programs to do specific tasks that can be combined to >>> solve bigger tasks. >>> >>> Do you think the C standard library would be improved by a single >>> function "flubadub" that takes 20 parameters and can calculate >>> logarithms, print formatted text, allocate memory and write it all to >>> a file? >>> >> By breaking down the problem into several parts e.g. "collect >> statistical data, analyse statistics, form hypothesis, attempt >> decryption, check decrypt for plausible plaintext" we can usually >> attack it better. And you're right, there's not a fundamental >> difference between writing one program with five subroutines, or five >> programs which pass data to each other via pipelines. > > That's not what I said. Try re-reading. I can't be bothered arguing > against yet another straw man. > >> But that doesn't mean that decision must not be made, or that you >> can't give reasons for and against each option. >> >> So could you list one or two reasons why you might prefer a program >> with five subroutines, and one or two reasons why you might prefer to >> write five programs which communicate via piped data? > I'm sure you're capable of going through the exercise and then you might gain a bit of insight on how to design such software systems. And, no, arguing that you'd go for a monolithic program doesn't necessarily mean that you are a "quivering jelly" at the thought of writing several simpler ones. And in fact to start you off I actually mentioned a few advantages of the pipeline approach. There are advantages and drawbacks to both. But I can't force you to think about what those might be if you won't, and from experience just telling you provokes your natural contentiousness and isn't very effective. It's reasonable to write a function flubadub which woirks as you say. It's not going to be a good candidate for the standard library as it would be too specific to a particular task. Unless it has several modes, making it effectively several functions with a common call address. That's not really similar to a monolithic program, even if it does have several "modes", because the modes would be related. You might have one mode for attempting decryption and another mode for achiving intercepts, and because they operate on the same archive, keeping the source in the same physical program prevents the archiver and the archive reader getting into incompatible versions. (There's an advantage of monolithic programs for the list). However you wouldn't write a monolithic program to decryot and to play space invaders. At least not normally. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 09:51 +0100 |
| Message-ID | <upiado$2h7rf$4@dont-email.me> |
| In reply to | #381533 |
On 01/02/2024 23:38, Malcolm McLean wrote: > I'm sure you're capable of going through the exercise and then you might > gain a bit of insight on how to design such software systems. And, no, > arguing that you'd go for a monolithic program doesn't necessarily mean > that you are a "quivering jelly" at the thought of writing several > simpler ones. And in fact to start you off I actually mentioned a few > advantages of the pipeline approach. I am perfectly aware of the advantages and disadvantages of monolithic approaches. I am also perfectly aware that you won't read that previous sentence, understand it, or consider it before making up your next pointless straw man or making up another lecture on something you know nothing about while the rest of us do. > > There are advantages and drawbacks to both. But I can't force you to > think about what those might be if you won't, and from experience just > telling you provokes your natural contentiousness and isn't very effective. >
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-02 13:28 +0000 |
| Message-ID | <upiql7$2k41a$1@dont-email.me> |
| In reply to | #381584 |
On 02/02/2024 08:51, David Brown wrote: > On 01/02/2024 23:38, Malcolm McLean wrote: >> I'm sure you're capable of going through the exercise and then you >> might gain a bit of insight on how to design such software systems. >> And, no, arguing that you'd go for a monolithic program doesn't >> necessarily mean that you are a "quivering jelly" at the thought of >> writing several simpler ones. And in fact to start you off I actually >> mentioned a few advantages of the pipeline approach. > > I am perfectly aware of the advantages and disadvantages of monolithic > approaches. > Well it's kind of poroof of the pudding. Ben has several programs connected by piplines and asked me what I thought of the design. I said I'd go for a monolithinc approach. You criticised mem giving no reason ither than that my oreferred approach was monolithic. So any reasonable erson would assume that you think that a monolithic approach is in and of itself bad. When invited to list the advantages and disadvantages if either, you refused to do so. I am sure that you are capable of doing this, and you are basically right. But you haven't actually done so. And it's proof of the pudding. Thne fact is there is case for `Ben's approach, there's a case for my approach, and maybe Ben's case is better. I've no objection to anyone weighing in on that. But fundamentally you do not understand what it means to offer an argument or how to make a case. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 15:47 +0100 |
| Message-ID | <upiv9p$2ku97$1@dont-email.me> |
| In reply to | #381596 |
On 02/02/2024 14:28, Malcolm McLean wrote: > On 02/02/2024 08:51, David Brown wrote: >> On 01/02/2024 23:38, Malcolm McLean wrote: >>> I'm sure you're capable of going through the exercise and then you >>> might gain a bit of insight on how to design such software systems. >>> And, no, arguing that you'd go for a monolithic program doesn't >>> necessarily mean that you are a "quivering jelly" at the thought of >>> writing several simpler ones. And in fact to start you off I actually >>> mentioned a few advantages of the pipeline approach. >> >> I am perfectly aware of the advantages and disadvantages of monolithic >> approaches. >> > Well it's kind of poroof of the pudding. Ben has several programs > connected by piplines and asked me what I thought of the design. I said > I'd go for a monolithinc approach. You criticised mem giving no reason > ither than that my oreferred approach was monolithic. So any reasonable > erson would assume that you think that a monolithic approach is in and > of itself bad. No, they would not. But I don't think, based on your postings, you count as a "reasonable person". > > When invited to list the advantages and disadvantages if either, you > refused to do so. I am sure that you are capable of doing this, and you > are basically right. But you haven't actually done so. And it's proof of > the pudding. > > Thne fact is there is case for `Ben's approach, there's a case for my > approach, and maybe Ben's case is better. I've no objection to anyone > weighing in on that. But fundamentally you do not understand what it > means to offer an argument or how to make a case. > I know exactly what it means. But I know when it is pointless, when the person on the other side pays not the slightest attention to what is being said and instead wanders off in their own little world with their own little ideas and their own independent terminology. What would be the point in giving reasons for anything, when you won't read them? Why should I give arguments, when you will "counter" them by telling us that grass is blue, using your own definition for "blue"? I've put a lot of effort into trying to explain things to you - enough is enough. I get more intelligent responses talking to my cat.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-02 15:38 +0000 |
| Message-ID | <upj2a2$2lhgs$1@dont-email.me> |
| In reply to | #381605 |
On 02/02/2024 14:47, David Brown wrote: > On 02/02/2024 14:28, Malcolm McLean wrote: >> On 02/02/2024 08:51, David Brown wrote: >>> On 01/02/2024 23:38, Malcolm McLean wrote: >>>> I'm sure you're capable of going through the exercise and then you >>>> might gain a bit of insight on how to design such software systems. >>>> And, no, arguing that you'd go for a monolithic program doesn't >>>> necessarily mean that you are a "quivering jelly" at the thought of >>>> writing several simpler ones. And in fact to start you off I >>>> actually mentioned a few advantages of the pipeline approach. >>> >>> I am perfectly aware of the advantages and disadvantages of >>> monolithic approaches. >>> >> Well it's kind of poroof of the pudding. Ben has several programs >> connected by piplines and asked me what I thought of the design. I >> said I'd go for a monolithinc approach. You criticised mem giving no >> reason ither than that my oreferred approach was monolithic. So any >> reasonable erson would assume that you think that a monolithic >> approach is in and of itself bad. > > No, they would not. > > But I don't think, based on your postings, you count as a "reasonable > person". > >> >> When invited to list the advantages and disadvantages if either, you >> refused to do so. I am sure that you are capable of doing this, and >> you are basically right. But you haven't actually done so. And it's >> proof of the pudding. >> >> Thne fact is there is case for `Ben's approach, there's a case for my >> approach, and maybe Ben's case is better. I've no objection to anyone >> weighing in on that. But fundamentally you do not understand what it >> means to offer an argument or how to make a case. >> > > I know exactly what it means. But I know when it is pointless, when the > person on the other side pays not the slightest attention to what is > being said and instead wanders off in their own little world with their > own little ideas and their own independent terminology. > > What would be the point in giving reasons for anything, when you won't > read them? Why should I give arguments, when you will "counter" them by > telling us that grass is blue, using your own definition for "blue"? > I've put a lot of effort into trying to explain things to you - enough > is enough. I get more intelligent responses talking to my cat. > > OK so here's how it went. >> On 31/01/2024 23:36, Ben Bacarisse wrote: >>> >> An example where it's really useful not to care: I have a suite of tools >>> for doing toy cryptanalysis. Some apply various transformations and/or >>> filters to byte streams and others collect and output (on stderr) >>> various statistics. Plugging them together in various pipelines is very >>> handy when investigating an encrypted text. The output is almost always >>> "binary" in the sense that there would be not point in looking at on a >> terminal. >> >> According to you, these tools are poorly designed. I don't think so. >> How would you design them? Endless input and output file names to be >> juggled and tidied up afterwards? >> > I'd write a monolithic program. [David Brown] It's very strange to me to see people that consider themselves programmers talk about having multiple small functions to do specific tasks and combining them into bigger functions to solve bigger problems, yet are reduced to quivering jellies at the thought of multiple small programs to do specific tasks that can be combined to solve bigger tasks. Do you think the C standard library would be improved by a single function "flubadub" that takes 20 parameters and can calculate logarithms, print formatted text, allocate memory and write it all to a file? So Ben describes his system, then asks how I woud design to to remove the pipelines (they don't actually seem to be binary pipelines, which is what I was objecting to, but Ben says that because of the type of data they pass they are as good as. Let that pass.) Would I create a lot of temporary intermediate files? That would be one approach. But my answer is no I wouldn't, I'd merge the programs into one monolithic program. Then you wouldn't need either intermediate files or pipelines. Now that shoukd be regarded as an entirely reasonable, unexceptional answer to the question. Of course you can say "actually you are only pretending to be reasonable. You're concocting a post hoc justification for not having pipelines. You wouldn't really do that." And maybe there's something in that. I represent and stand for hope, charity, and reason, and always try to express these values. But I'm not pure reason. I do have my human failings. However bascially it's an answer. And I go on to discuss the pros and cons. Now lets look at your contribution. It's unnecessarily contentious. It's insulting. And whilst it does make a point, it's a rather silly one and not really addressing the issue, which is about communications. And it does seem that you think "distributed good, monolithic bad". You might not exacty say it in as many words. But it's hard to see how someone wouldn't gain that impression. But of course you do have a reasonable degree of intelligence, and you can easily be brought to see that monolithic systems have their advantages as well as their disadvantages. You know that really already. You've just blinded yourself to it through pure contentiousness. Try to see these things. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-02 23:38 +0000 |
| Message-ID | <87v876phch.fsf@bsb.me.uk> |
| In reply to | #381430 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > On 31/01/2024 23:36, Ben Bacarisse wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >> >>> On 30/01/2024 07:27, Tim Rentsch wrote: >>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>> On 29/01/2024 20:10, Tim Rentsch wrote: >>>>> >>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>>> >>>>>> [...] >>>>>> >>>>>>> I've never used standard output for binary data. >>>>>>> [...] it strikes me as a poor design decision. >>>>>> >>>>>> How so? >>>>> >>>>> Because the output can't be inspected by humans, and because it might >>>>> have unusual effects if passed though systems designed to handle >>>>> human-readable text. >> Maybe you are not used to a system where it's trivial to inspect such >> data. When "some_prog" produces data that are not compatible with the >> current terminal settings, "some_prog | hd" shows a hex dump instead. >> The need to do this does not make "some_prog" poorly designed. It may >> simply mean that the output is /intended/ for further processing. >> >>> For instance in some systems designed to receive >>>>> ASCII text, there is no distinction between the nul byte and "waiting >>>>> for next data byte". Obviously this will cause difficuties if the data >>>>> is binary. >>>>> Also many binary formats can't easily be extended, so you can pass one >>>>> image and that's all. While it is possible to devise a text format >>>>> which is similar, in practice text formats usually have enough >>>>> redundancy to be easily extended. >>>>> >>>>> So it's harder to correct errors, more prone to errors, and harder to >>>>> extend. >>>> Your reasoning is all gobbledygook. Your comments reflect only >>>> limitations in your thinking, not any essential truth about using >>>> standard out for binary data. >>>> >>> I must admit that it's nothing I have ever done or considered doing. >>> >>> However standard output is designed for text and not binary ouput. >> What is your evidence? stdout was just designed for output (as far as I >> can tell) and, anyway, what is the distinction you are making between >> binary and text? iconv --from ACSII --to EBCDIC-UK will produce >> something that is "logically" text on stdout, but it might look like >> binary to you. >> An example where it's really useful not to care: I have a suite of tools >> for doing toy cryptanalysis. Some apply various transformations and/or >> filters to byte streams and others collect and output (on stderr) >> various statistics. Plugging them together in various pipelines is very >> handy when investigating an encrypted text. The output is almost always >> "binary" in the sense that there would be not point in looking at on a >> terminal. >> According to you, these tools are poorly designed. I don't think so. >> How would you design them? Endless input and output file names to be >> juggled and tidied up afterwards? >> > I'd write a monolithic program. > Load the encryoted text into memory, and then pass it to subroutines to do > the various analyses. > You can of course process it, and then pass the processed output to other > programs. And that does have a point if the program which is acceoting the > processed outout is doing something which has no necessary connection to > cryptanalysis. So for example a program to produce a pie chart from a list > of letter frequencies. But if it's transforming the encrypted text in > intricate and specialised ways, then analysing the transformed text in > other specialised and intricate ways, then firstly you've probably > introduced coupling and dependency between the two programs, and secondly > you're probably at some point going to want to modify the second program in > the pipeline to look at the raw data. I don't think you understand the design at all. What coupling? And why would I modify the program to inspect the data when there are several inspection program that can be inserted before or after to do just that? I've commented elsewhere on why I think a monolithic program is not a good design, so I won't repeat that here. I just don't understand any of your objections to my design. Specifically, you don't address the fact that you claim it's wrong simply because the data going to stdout are binary. Have you abandoned that generic criticism? Is there why you split the thread with two replies? -- Ben.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-02 23:59 +0000 |
| Message-ID | <20240202155824.923@kylheku.com> |
| In reply to | #381641 |
On 2024-02-02, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote: > I've commented elsewhere on why I think a monolithic program is not a > good design, so I won't repeat that here. All the programs I use are some kind of "lithic"; not so much mono- as neo-. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 05:24 +0000 |
| Message-ID | <upf9ug$1uf0j$1@dont-email.me> |
| In reply to | #381417 |
On 31/01/2024 23:36, Ben Bacarisse wrote: > Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: > >> On 30/01/2024 07:27, Tim Rentsch wrote: >>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> >>>> On 29/01/2024 20:10, Tim Rentsch wrote: >>>> >>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>>> >>>>> [...] >>>>> >>>>>> I've never used standard output for binary data. >>>>>> [...] it strikes me as a poor design decision. >>>>> >>>>> How so? >>>> >>>> Because the output can't be inspected by humans, and because it might >>>> have unusual effects if passed though systems designed to handle >>>> human-readable text. > > Maybe you are not used to a system where it's trivial to inspect such > data. When "some_prog" produces data that are not compatible with the > current terminal settings, "some_prog | hd" shows a hex dump instead. > The need to do this does not make "some_prog" poorly designed. It may > simply mean that the output is /intended/ for further processing. > Well almost by definition binary output is intended for further processing. Binary audio files must ultimately be converted to analogue if anyone is to listen to them, for example. I had to check how to do a hex dump on the system I'm typing this on. The name of the hex dumper is xxd instead of hd, but otherwise it works the same way and will accept piped data. But the fact I had to look it up tells you that I've never actually used it. The two problems with hex dumps are that you've got to do mental arithmetic to convert 8 bit hex values into 16 or 32 bit fields, and that once you get a variable length field, it's virtually impossible to keep track of and match up the following fields. So in reality what I do when troubleshooting binary data is to write a scratch program, or, more often because the trouble is in the existing parser, put diagnosics in an existing parser to print out a few fields and inspect them that way. Of course to check that audio or image data is right you have to listen to it or view it - you can't tell from looking at the individual samples. -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-01 14:02 +0100 |
| Message-ID | <upg4ol$22tss$1@dont-email.me> |
| In reply to | #381438 |
On 01.02.2024 06:24, Malcolm McLean wrote: > On 31/01/2024 23:36, Ben Bacarisse wrote: >> >> Maybe you are not used to a system where it's trivial to inspect such >> data. When "some_prog" produces data that are not compatible with the >> current terminal settings, "some_prog | hd" shows a hex dump instead. >> The need to do this does not make "some_prog" poorly designed. It may >> simply mean that the output is /intended/ for further processing. >> > Well almost by definition binary output is intended for further > processing. Binary audio files must ultimately be converted to analogue > if anyone is to listen to them, for example. Well, not necessarily. Let's leave the typical use case for a moment... It might also be analyzed and converted to a digitally represented formula, say some TeX code, or e.g. like the formal syntax that the lilypond program uses. > I had to check how to do a hex dump on the system I'm typing this on. > The name of the hex dumper is xxd instead of hd, but otherwise it works > the same way and will accept piped data. But the fact I had to look it > up tells you that I've never actually used it. Well, there's always the old Unix standard tool, 'od'. I use that without thinking or looking it up, since it was ever there, despite I only rarely use it. And you observed correctly that nowadays there's typically even more than one tool available. (And Bart will probably write his own tool. :-) > The two problems with hex > dumps are that you've got to do mental arithmetic to convert 8 bit hex > values into 16 or 32 bit fields, Hmm.. - have you inspected the man pages of the tools? At least for 'od' I know it's easy per option... od -c file # characters (or escapes and octals) od -t x1 file # hex octets od -t x2 file # words (two octets) od -c -t x1 file # characters and octets > and that once you get a variable length > field, it's virtually impossible to keep track of and match up the > following fields. An inherent property of a binary. In that case you need data specific applications. > So in reality what I do when troubleshooting binary > data is to write a scratch program, or, more often because the trouble > is in the existing parser, put diagnosics in an existing parser to print > out a few fields and inspect them that way. That's fine. > Of course to check that > audio or image data is right you have to listen to it or view it - you > can't tell from looking at the individual samples. Depends on the sort of check, and the solution approach. (See my lilypond example.) Janis
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 13:26 +0000 |
| Message-ID | <upg65m$235lp$1@dont-email.me> |
| In reply to | #381454 |
On 01/02/2024 13:02, Janis Papanagnou wrote:
> On 01.02.2024 06:24, Malcolm McLean wrote:
>> On 31/01/2024 23:36, Ben Bacarisse wrote:
>>>
>>> Maybe you are not used to a system where it's trivial to inspect such
>>> data. When "some_prog" produces data that are not compatible with the
>>> current terminal settings, "some_prog | hd" shows a hex dump instead.
>>> The need to do this does not make "some_prog" poorly designed. It may
>>> simply mean that the output is /intended/ for further processing.
>>>
>> Well almost by definition binary output is intended for further
>> processing. Binary audio files must ultimately be converted to analogue
>> if anyone is to listen to them, for example.
>
> Well, not necessarily. Let's leave the typical use case for a moment...
>
> It might also be analyzed and converted to a digitally represented
> formula, say some TeX code, or e.g. like the formal syntax that the
> lilypond program uses.
>
And ultimately converted to a non binary form. A list of 1s and 0s is
seldom any use to the final consumer of the data.
>
>> The two problems with hex
>> dumps are that you've got to do mental arithmetic to convert 8 bit hex
>> values into 16 or 32 bit fields,
>
> Hmm.. - have you inspected the man pages of the tools?
>
I just ran "man xxd". The man page contains this statement.
The tool's weirdness matches its creator's brain. Use entirely at your
own risk. Copy files. Trace it. Become a wizard.
> At least for 'od' I know it's easy per option...
> od -c file # characters (or escapes and octals)
> od -t x1 file # hex octets
> od -t x2 file # words (two octets)
> od -c -t x1 file # characters and octets
>
So a JPEG file starts with
FF D8
FF E0
hi lo (length of the FF E0 segment)
So we want the output
FF D8 FF E0 [1000] to check that the segment markers are correct and FF
E0 segment is genuinely a thousand bytes (or whatever it is). This isn't
easy to achieve with a hex dump utility.
--
Check out Basic Algorithms and my other books:
https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-01 16:07 +0100 |
| Message-ID | <upgc4f$2454d$1@dont-email.me> |
| In reply to | #381459 |
On 01.02.2024 14:26, Malcolm McLean wrote: > On 01/02/2024 13:02, Janis Papanagnou wrote: >> Well, not necessarily. Let's leave the typical use case for a moment... >> >> It might also be analyzed and converted to a digitally represented >> formula, say some TeX code, or e.g. like the formal syntax that the >> lilypond program uses. >> > And ultimately converted to a non binary form. A list of 1s and 0s is > seldom any use to the final consumer of the data. No, I was speaking about an application that creates lilypond _input_, which is a formal language to write notes, e.g. for evaluation by the lilypond software, but not excluding other usages. > >>> The two problems with hex >>> dumps are that you've got to do mental arithmetic to convert 8 bit hex >>> values into 16 or 32 bit fields, >> >> Hmm.. - have you inspected the man pages of the tools? >> > I just ran "man xxd". The man page contains this statement. > > The tool's weirdness matches its creator's brain. Use entirely at your > own risk. Copy files. Trace it. Become a wizard. This statement repelled you? (Can't help you here.) >> At least for 'od' I know it's easy per option... >> od -c file # characters (or escapes and octals) >> od -t x1 file # hex octets >> od -t x2 file # words (two octets) >> od -c -t x1 file # characters and octets >> > So a JPEG file starts with > FF D8 > FF E0 > hi lo (length of the FF E0 segment) > > So we want the output > > FF D8 FF E0 [1000] to check that the segment markers are correct and FF > E0 segment is genuinely a thousand bytes (or whatever it is). This isn't > easy to achieve with a hex dump utility. I don't know binary format details about jpg, so I cannot help you here. I was responding to your question where you wanted entities larger than a single octet. I showed you some examples what I can do with 'od'. (Just open it's man page to find all sorts of possible options and option combinations.) Yes, you can use entities of length four. Guess how? By 'od -t x4 file' Or if you need decimal numbers use 'od -t d4 file' or 'od -t d2 file'. And I already answered that for specific binary structures you'll need something data specific. You can also generalize that to some degree... For example I recently wrote a shell script that supports binary data definitions in a very primitive declarative form; it's allowing me to specify the field lengths, output type, and identification for readable output. It allows hex, bin, dec, text, hex-seq, data to skip. Length of fields many be constants, 0-terminated, or defined by another preceding field. It also handles endianness. You see even some primitive "generic" thing needs a couple features. Janis
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 15:50 +0000 |
| Message-ID | <upgekv$24gnk$2@dont-email.me> |
| In reply to | #381478 |
On 01/02/2024 15:07, Janis Papanagnou wrote: > On 01.02.2024 14:26, Malcolm McLean wrote: >> On 01/02/2024 13:02, Janis Papanagnou wrote: >>> Well, not necessarily. Let's leave the typical use case for a moment... >>> >>> It might also be analyzed and converted to a digitally represented >>> formula, say some TeX code, or e.g. like the formal syntax that the >>> lilypond program uses. >>> >> And ultimately converted to a non binary form. A list of 1s and 0s is >> seldom any use to the final consumer of the data. > > No, I was speaking about an application that creates lilypond _input_, > which is a formal language to write notes, e.g. for evaluation by the > lilypond software, but not excluding other usages. > >> >>>> The two problems with hex >>>> dumps are that you've got to do mental arithmetic to convert 8 bit hex >>>> values into 16 or 32 bit fields, >>> >>> Hmm.. - have you inspected the man pages of the tools? >>> >> I just ran "man xxd". The man page contains this statement. >> >> The tool's weirdness matches its creator's brain. Use entirely at your >> own risk. Copy files. Trace it. Become a wizard. > > This statement repelled you? (Can't help you here.) > >>> At least for 'od' I know it's easy per option... >>> od -c file # characters (or escapes and octals) >>> od -t x1 file # hex octets >>> od -t x2 file # words (two octets) >>> od -c -t x1 file # characters and octets >>> >> So a JPEG file starts with >> FF D8 >> FF E0 >> hi lo (length of the FF E0 segment) >> >> So we want the output >> >> FF D8 FF E0 [1000] to check that the segment markers are correct and FF >> E0 segment is genuinely a thousand bytes (or whatever it is). This isn't >> easy to achieve with a hex dump utility. > > I don't know binary format details about jpg, so I cannot help you here. > JPEG is an extremely common binary file format and JPEG files will be found on most general purpose computers. All you need to know for the purposes of the discussion is that the first four bytes are segment identifiers and must have the values I gave, whilst bytes five and six are a big endian 16 bit number that represents a segment length, and that potentially any of those values could be unexpected and you might want to inspect them. So how would you achieve that in a convenient and non-error prone way? -- Check out Basic Algorithms and my other books: https://www.lulu.com/spotlight/bgy1mm
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 16:30 +0000 |
| Message-ID | <JGPuN.297652$PuZ9.135961@fx11.iad> |
| In reply to | #381486 |
Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >On 01/02/2024 15:07, Janis Papanagnou wrote: >> On 01.02.2024 14:26, Malcolm McLean wrote: >>> On 01/02/2024 13:02, Janis Papanagnou wrote: >>>> Well, not necessarily. Let's leave the typical use case for a moment... >>>> >>>> It might also be analyzed and converted to a digitally represented >>>> formula, say some TeX code, or e.g. like the formal syntax that the >>>> lilypond program uses. >>>> >>> And ultimately converted to a non binary form. A list of 1s and 0s is >>> seldom any use to the final consumer of the data. >> >> No, I was speaking about an application that creates lilypond _input_, >> which is a formal language to write notes, e.g. for evaluation by the >> lilypond software, but not excluding other usages. >> >>> >>>>> The two problems with hex >>>>> dumps are that you've got to do mental arithmetic to convert 8 bit hex >>>>> values into 16 or 32 bit fields, >>>> >>>> Hmm.. - have you inspected the man pages of the tools? >>>> >>> I just ran "man xxd". The man page contains this statement. >>> >>> The tool's weirdness matches its creator's brain. Use entirely at your >>> own risk. Copy files. Trace it. Become a wizard. >> >> This statement repelled you? (Can't help you here.) >> >>>> At least for 'od' I know it's easy per option... >>>> od -c file # characters (or escapes and octals) >>>> od -t x1 file # hex octets >>>> od -t x2 file # words (two octets) >>>> od -c -t x1 file # characters and octets >>>> >>> So a JPEG file starts with >>> FF D8 >>> FF E0 >>> hi lo (length of the FF E0 segment) >>> >>> So we want the output >>> >>> FF D8 FF E0 [1000] to check that the segment markers are correct and FF >>> E0 segment is genuinely a thousand bytes (or whatever it is). This isn't >>> easy to achieve with a hex dump utility. >> >> I don't know binary format details about jpg, so I cannot help you here. >> >JPEG is an extremely common binary file format and JPEG files will be >found on most general purpose computers. >All you need to know for the purposes of the discussion is that the >first four bytes are segment identifiers and must have the values I >gave, whilst bytes five and six are a big endian 16 bit number that >represents a segment length, and that potentially any of those values >could be unexpected and you might want to inspect them. > >So how would you achieve that in a convenient and non-error prone way? $ if file /tmp/garage.jpg | grep JPEG > /dev/null^Jthen^Jecho "it is a jpeg"^Jfi it is a jpeg
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 18:03 +0000 |
| Message-ID | <upgmdd$2605r$1@dont-email.me> |
| In reply to | #381495 |
On 01/02/2024 16:30, Scott Lurndal wrote:
> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes:
>> On 01/02/2024 15:07, Janis Papanagnou wrote:
>>> On 01.02.2024 14:26, Malcolm McLean wrote:
>>>> On 01/02/2024 13:02, Janis Papanagnou wrote:
>>>>> Well, not necessarily. Let's leave the typical use case for a moment...
>>>>>
>>>>> It might also be analyzed and converted to a digitally represented
>>>>> formula, say some TeX code, or e.g. like the formal syntax that the
>>>>> lilypond program uses.
>>>>>
>>>> And ultimately converted to a non binary form. A list of 1s and 0s is
>>>> seldom any use to the final consumer of the data.
>>>
>>> No, I was speaking about an application that creates lilypond _input_,
>>> which is a formal language to write notes, e.g. for evaluation by the
>>> lilypond software, but not excluding other usages.
>>>
>>>>
>>>>>> The two problems with hex
>>>>>> dumps are that you've got to do mental arithmetic to convert 8 bit hex
>>>>>> values into 16 or 32 bit fields,
>>>>>
>>>>> Hmm.. - have you inspected the man pages of the tools?
>>>>>
>>>> I just ran "man xxd". The man page contains this statement.
>>>>
>>>> The tool's weirdness matches its creator's brain. Use entirely at your
>>>> own risk. Copy files. Trace it. Become a wizard.
>>>
>>> This statement repelled you? (Can't help you here.)
>>>
>>>>> At least for 'od' I know it's easy per option...
>>>>> od -c file # characters (or escapes and octals)
>>>>> od -t x1 file # hex octets
>>>>> od -t x2 file # words (two octets)
>>>>> od -c -t x1 file # characters and octets
>>>>>
>>>> So a JPEG file starts with
>>>> FF D8
>>>> FF E0
>>>> hi lo (length of the FF E0 segment)
>>>>
>>>> So we want the output
>>>>
>>>> FF D8 FF E0 [1000] to check that the segment markers are correct and FF
>>>> E0 segment is genuinely a thousand bytes (or whatever it is). This isn't
>>>> easy to achieve with a hex dump utility.
>>>
>>> I don't know binary format details about jpg, so I cannot help you here.
>>>
>> JPEG is an extremely common binary file format and JPEG files will be
>> found on most general purpose computers.
>> All you need to know for the purposes of the discussion is that the
>> first four bytes are segment identifiers and must have the values I
>> gave, whilst bytes five and six are a big endian 16 bit number that
>> represents a segment length, and that potentially any of those values
>> could be unexpected and you might want to inspect them.
>>
>> So how would you achieve that in a convenient and non-error prone way?
>
> $ if file /tmp/garage.jpg | grep JPEG > /dev/null^Jthen^Jecho "it is a jpeg"^Jfi
> it is a jpeg
That doesn't work for me:
root@xxx:/mnt/c/mx# ls card2.jpg
card2.jpg
root@xxx:/mnt/c/mx# if file card2.jpg | grep JPEG >
/dev/null^Jthen^Jecho "it is a jpeg"^Jfi
>
>
I just get a lone ">". If press Enter, I get more. If I press Ctrl=D, it
says:
> -bash: syntax error: unexpected end of file
logout
I think anyway that you need to grep for JFIF not JPEG, but that is a
really poor way to check for a JPEG file. Any text or binary file can
have a JFIF byte sequence.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-01 12:09 -0800 |
| Message-ID | <878r44q73s.fsf@nosuchdomain.example.com> |
| In reply to | #381500 |
bart <bc@freeuk.com> writes:
> On 01/02/2024 16:30, Scott Lurndal wrote:
[...]
>> $ if file /tmp/garage.jpg | grep JPEG > /dev/null^Jthen^Jecho "it is a jpeg"^Jfi
>> it is a jpeg
>
> That doesn't work for me:
Not if you type the "^J"s as '^' and 'J'. They were intended to
represent newlines. I would use semicolons instead:
$ if file /tmp/garage.jpg | grep JPEG > /dev/null ; then echo "it is a jpeg" ; fi
it is a jpeg
(I might also use "grep -q" rather than redirecting to /dev/null.)
[...]
> I think anyway that you need to grep for JFIF not JPEG, but that is a
> really poor way to check for a JPEG file. Any text or binary file can
> have a JFIF byte sequence.
That's not an issue. "file" doesn't just look for "JFIF" to determine
that a file is a jpg.
Try running the "file" command on a jpg file. Its output includes both
"JPEG" and "JFIF". Try running it on a text file containing the string
"JFIF".
The output of "file" is primarily meant to be human-readable, so
processing it automatically can be tricky, but it's usually doable --
and it also has a "--mime" option if you want more specificity.
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 20:59 +0000 |
| Message-ID | <CCTuN.104492$JLvf.67793@fx44.iad> |
| In reply to | #381508 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >bart <bc@freeuk.com> writes: >> On 01/02/2024 16:30, Scott Lurndal wrote: >[...] >>> $ if file /tmp/garage.jpg | grep JPEG > /dev/null^Jthen^Jecho "it is a jpeg"^Jfi >>> it is a jpeg >> >> That doesn't work for me: > >Not if you type the "^J"s as '^' and 'J'. They were intended to >represent newlines. I would use semicolons instead: Yes, that's an artifact of ksh history entries for multiline commands. I should have edited it before posting.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 21:25 +0000 |
| Message-ID | <uph28d$27u2h$1@dont-email.me> |
| In reply to | #381508 |
On 01/02/2024 20:09, Keith Thompson wrote: > bart <bc@freeuk.com> writes: >> On 01/02/2024 16:30, Scott Lurndal wrote: > [...] >>> $ if file /tmp/garage.jpg | grep JPEG > /dev/null^Jthen^Jecho "it is a jpeg"^Jfi >>> it is a jpeg >> >> That doesn't work for me: > > Not if you type the "^J"s as '^' and 'J'. They were intended to > represent newlines. I would use semicolons instead: > > $ if file /tmp/garage.jpg | grep JPEG > /dev/null ; then echo "it is a jpeg" ; fi > it is a jpeg > > (I might also use "grep -q" rather than redirecting to /dev/null.) > > [...] > >> I think anyway that you need to grep for JFIF not JPEG, but that is a >> really poor way to check for a JPEG file. Any text or binary file can >> have a JFIF byte sequence. > > That's not an issue. "file" doesn't just look for "JFIF" to determine > that a file is a jpg. I see, so 'file' is a special command that does all the work. grep checks whether the description contains JPEG. Although it won't work for any of my private formats.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2024-02-01 13:34 -0800 |
| Message-ID | <uph2ol$285r5$1@dont-email.me> |
| In reply to | #381518 |
On 2/1/2024 1:25 PM, bart wrote: > On 01/02/2024 20:09, Keith Thompson wrote: >> bart <bc@freeuk.com> writes: >>> On 01/02/2024 16:30, Scott Lurndal wrote: >> [...] >>>> $ if file /tmp/garage.jpg | grep JPEG > /dev/null^Jthen^Jecho "it is >>>> a jpeg"^Jfi >>>> it is a jpeg >>> >>> That doesn't work for me: >> >> Not if you type the "^J"s as '^' and 'J'. They were intended to >> represent newlines. I would use semicolons instead: >> >> $ if file /tmp/garage.jpg | grep JPEG > /dev/null ; then echo "it >> is a jpeg" ; fi >> it is a jpeg >> >> (I might also use "grep -q" rather than redirecting to /dev/null.) >> >> [...] >> >>> I think anyway that you need to grep for JFIF not JPEG, but that is a >>> really poor way to check for a JPEG file. Any text or binary file can >>> have a JFIF byte sequence. >> >> That's not an issue. "file" doesn't just look for "JFIF" to determine >> that a file is a jpg. > > I see, so 'file' is a special command that does all the work. grep > checks whether the description contains JPEG. Although it won't work for > any of my private formats. > > Why would it work with your private formats? ;^)
[toc] | [prev] | [next] | [standalone]
Page 29 of 33 — ← Prev page 1 … 27 28 [29] 30 31 … 33 Next page →
Back to top | Article view | comp.lang.c
csiph-web