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 28 of 33 — ← Prev page 1 … 26 27 [28] 29 30 … 33 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 23:02 +0100 |
| Message-ID | <uph4da$28ebd$1@dont-email.me> |
| In reply to | #381496 |
On 01/02/2024 18:06, bart wrote: > On 01/02/2024 14:50, David Brown wrote: >> On 01/02/2024 02:29, bart wrote: >>> On 01/02/2024 00:47, Scott Lurndal wrote: >>>> bart <bc@freeuk.com> writes: >>>>> On 31/01/2024 23:36, Ben Bacarisse wrote: >>>>>> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>>> >>>>>> 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 think they're poorly designed too. >>>> >>>> Of course you do. They're not bart programs. >>>> >>>>> >>>>> From the POV of interactive console programs, they /are/ poor. >>>> >>>> You don't provide any reason why - do elucidate! >>> >>> They only do one thing, like you can't first do A, then B. They don't >>> give any prompts. They often apparently do nothing (so you can't tell >>> if they're busy, waiting for input, or hanging). There is no dialog. >> >> That's the whole point! >> >> If you want to do A, then B, then you do "A | B", or "A; B", or "A && >> B" or "A || B". And if you want to do A, then B twice, then C, then A >> again, you write "A | B | B | C | A". Other operator choices let you >> say "do this then that", or "do this, and if successful do that", etc. >> >> Your monolithic AB program fails when you want to do C, or want to do >> A and B in a way the AB author didn't envisage. >> >> You have a Transformer - a toy that can be either a car or a robot. >> I've got a box of Lego. Sometimes I need instructions and a bit of >> time, but I can have a car, a robot, a plane, an alien, a house, and >> anything else I might want. > > > You can only do one thing, as you can only have one unbroken byte > sequence as output sent to stdout. I can do one sequence of many things. Your suggested "clipboard" idea was no different. But it's not difficult to have intermediary files if you want to do more complicated things. > > You can't send output A to stdout, then B to stdout, and certainly can't > interleave messages to the console on stdout, as that would then be all > mixed up with the possibly binary data, and if redirected, you won't see > it. $ cat A one two three $ cat B cat dog cow $ (cat A; cat B) | wc -l 6 That's the output of two commands, "cat A" and "cat B", each going to their stdout, and they are concatenated into a single pipe going to the "wc -l" command to count the lines. And if I wanted to redirect them to a file "x" and also view them, I'd write : $ (cat A; cat B) | tee x one two three cat dog cow $ wc -l x 6 x I'm not sure we are getting anywhere with you trying to invent more and more complex situations in an attempt to find something that can't be done from a Linux bash shell. > > I can see the idea of having one permanently open channel, but call it > stdbinout or stdpipeout. But you still won't be able to generate a > sequence of distinct data blocks along that one channel because it is > continuous. > > This why 'as' only ever produces one object file, even for multiple > input source files. "as" produces one object file, because that's what the program does. If you want two object files, run it twice. In Unix systems, starting programs and running lots of programs at a time is cheap. It's not a system that requires monolithic programs in order to work efficiently. > > And explains why 'as' treats multiple .s input files as though they were > all part of the same single source file: you can take one .s file, chop > it up into multiple .s files, and submit them all to 'as' (keeping the > right order). It does that because that's what makes sense. If you want to assembly multiple .s files into individual .o files, then you do that. If you want to assemble them into a single .o file, then you do that. Your choice. Having it generate multiple .o files for multiple .s inputs would restrict that choice. > > It's a feature! It's also the whackiest assembler I've encountered, this > century anyway. That fact that it's implemented as a crude filter with > one input stream and one output streams helps explain it. > > Although it works differently from most such filters, because if its > output is not piped, and not redirected, it is sent to a file (always > called a.out). It's not quite crazy enough to send binary object file > data to the termimal; I wonder why not? You really are scraping the bottom of the barrel to try to justify your irrational hatreds, aren't you? You put a lot of effort into desperately trying to dislike programs that don't work exactly the way your programs work. It's a very strange hobby you have.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 22:56 +0000 |
| Message-ID | <uph7i6$28ugb$1@dont-email.me> |
| In reply to | #381526 |
On 01/02/2024 22:02, David Brown wrote:
> On 01/02/2024 18:06, bart wrote:
>> You can't send output A to stdout, then B to stdout, and certainly
>> can't interleave messages to the console on stdout, as that would then
>> be all mixed up with the possibly binary data, and if redirected, you
>> won't see it.
>
> $ cat A
> one
> two
> three
>
> $ cat B
>
> cat
> dog
> cow
>
> $ (cat A; cat B) | wc -l
> 6
>
> That's the output of two commands, "cat A" and "cat B", each going to
> their stdout, and they are concatenated into a single pipe going to the
> "wc -l" command to count the lines.
I see you don't get it. This is the equivalent of a program which is
supposed to do this:
print A to TTY
print B to LPT
print C to TTY
print D to LPT
but instead is written as this:
print A to TTY
print B to TTY
print C to TTY
print D to TTY
and you are expected to redirect all TTY output to LPT.
At least, on LPT, B and D can each start with a separate title page; on
stdout directed to a file, it will be all mixed up.
> I'm not sure we are getting anywhere with you trying to invent more and
> more complex situations in an attempt to find something that can't be
> done from a Linux bash shell.
They're remarkably simple situations!
>> And explains why 'as' treats multiple .s input files as though they
>> were all part of the same single source file: you can take one .s
>> file, chop it up into multiple .s files, and submit them all to 'as'
>> (keeping the right order).
>
> It does that because that's what makes sense.
Sorry, but it is rubbish.
> Having it generate multiple .o files for multiple .s inputs
> would restrict that choice.
And yet that is exactly what gcc does; see below.
> You really are scraping the bottom of the barrel to try to justify your
> irrational hatreds, aren't you? You put a lot of effort into
> desperately trying to dislike programs that don't work exactly the way
> your programs work.
Because their UIs are rubbish. They are inconsistent. They are
restricted. And yet they are deified for some inexplicable reason. Over
the past few decades nobody has written a better assembler?
At least there are external ones you can use instead, but gcc will not
generate .s files in the right syntax (I guess that's another tool you
will pull of that bottomless bag of such tools).
> It's a very strange hobby you have.
I write language tools. Ones which are always derided in this newsgroup.
They've included quite a few assemblers.
And yet they all have sensible command line interfaces that do what you
expect.
Which is more that can be said for gcc and especially 'as'.
If you do this on gcc:
gcc one.s two.s
it will create one.o and two.s. Do this on as:
as one.s two.s
it will not only create one file a.out, but will concatenate both,
giving unexpected results:
c:\c>gcc -S cipher.c hmac.c sha2.c
c:\c>as cipher.s hmac.s sha2.s
hmac.s: Assembler messages:
hmac.s:328: Error: symbol `.L18' is already defined
hmac.s:352: Error: symbol `.L17' is already defined
...
WTF? Compare with this:
c:\c>mcc -s cipher hmac sha2
Compiling 3 files to .asm
c:\c>aa cipher hmac sha2
Assembling cipher.asm to cipher.exe
It works impeccably. Even better than 'as', even if that had worked as
expected, because there you still have the task of linking the outputs.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-02 03:13 +0100 |
| Message-ID | <uphj4e$2ai9g$1@dont-email.me> |
| In reply to | #381536 |
On 01.02.2024 23:56, bart wrote:
> On 01/02/2024 22:02, David Brown wrote:
>> On 01/02/2024 18:06, bart wrote:
>
>>> You can't send output A to stdout, then B to stdout, and certainly
>>> can't interleave messages to the console on stdout, as that would
>>> then be all mixed up with the possibly binary data, and if
>>> redirected, you won't see it.
>>
>> $ cat A
>> one
>> two
>> three
>>
>> $ cat B
>>
>> cat
>> dog
>> cow
>>
>> $ (cat A; cat B) | wc -l
>> 6
>>
>> That's the output of two commands, "cat A" and "cat B", each going to
>> their stdout, and they are concatenated into a single pipe going to
>> the "wc -l" command to count the lines.
I see you're trying to teach shell basics to Bart; interesting.
>
> I see you don't get it. This is the equivalent of a program which is
What is meant by "This"? (I cannot find code or description.)
> supposed to do this:
>
> print A to TTY
> print B to LPT
> print C to TTY
> print D to LPT
Is that the task? Are A-D program names? Any other requirements
or restrictions you impose?
cat A
cat B | lpr # of course you don't need cat here: lpr B
cat C
cat D | lpr # of course you don't need cat here: lpr D
You want stdout collected? Do it as David suggested, e.g.
{ cat A ; lpr B ; cat C ; lpr D ;} | processor-for-A-and-C
Or you want to split A, B, C, or D to different channels or tools?
Then use 'tee', and/or use redirection to files, and/or to processes.
>
> but instead is written as this:
>
> print A to TTY
> print B to TTY
> print C to TTY
> print D to TTY
>
> and you are expected to redirect all TTY output to LPT.
>
> At least, on LPT, B and D can each start with a separate title page; on
> stdout directed to a file, it will be all mixed up.
See above. - Any other task? - Or did you mean something else?
(It's hard to believe that there's something possible in the DOS
cmd/bat/bart world that wouldn't be possible in Unix shell - besides
blue screens of course.)
Janis
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-02 09:44 +0100 |
| Message-ID | <upia0v$2h7rf$3@dont-email.me> |
| In reply to | #381536 |
On 01/02/2024 23:56, bart wrote: > On 01/02/2024 22:02, David Brown wrote: >> I'm not sure we are getting anywhere with you trying to invent more >> and more complex situations in an attempt to find something that can't >> be done from a Linux bash shell. > > They're remarkably simple situations! As I said, you can try to invent more and more unrealistic situations to try to "prove" that bash is useless and Unix is flawed and its designers were incompetent, along with every other programmer and developer throughout time, while Bart from Usenet has the perfect solution for everything. If you are happy with everything you have made yourself, and think everything else is unusable, incompetently made, and probably designed specifically to annoy you personally, why bother with any of it? Why are you here, complaining about everything? What do you gain from frothing at the mouth like this, other than high blood pressure? Ask about C issues. Tell us about C programs. You can even ask about off-topic stuff - many of us have tried to give you lots of information about things you are ignorant of. But /please/ stop whining.
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2024-02-02 01:08 +0000 |
| Message-ID | <uphfa7$29ukk$3@dont-email.me> |
| In reply to | #381526 |
On Thu, 1 Feb 2024 23:02:17 +0100, David Brown wrote: > But it's not difficult to have intermediary files if you want to do more > complicated things. This is the point where someone says “I wish a shell script pipeline could express a general flow graph”. . . . . . ... nobody?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 15:35 +0100 |
| Message-ID | <upga71$23qjh$1@dont-email.me> |
| In reply to | #381419 |
On 01/02/2024 01:21, bart wrote:
> 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 think they're poorly designed too.
Then you are wrong too. (Although I think you've been doing a slightly
better job than Malcolm of explaining /why/ you think they way you do.)
Basically, neither you nor Malcolm are familiar with these tools. You
don't use them significantly - and when you do, it is for simple things
and you feel they are over-complicated for the tasks /you/ need. And
maybe they /are/ over-complicated for your particular needs - but they
are useful to a large number of people in a large number of ways. They
are not poorly designed - they are simply not designed for /your/ needs
and preferences.
This of course works in all directions. Some people prefer gui tools
and think command-line tools are hard to use. Some people prefer
command line tools and think gui tools are slow and inefficient. Some
people like combining multiple small, flexible tools that each handle
part of the task - others prefer monolithic tools that try to do
everything. Each possibility has its advantages, and disadvantages, its
proponents and detractors. And if you want to be a happy and efficient
developer, you stay open to using any of the solutions - learn at least
a bit about them all, and use what suits you and your needs best at the
time.
But do not mistake "I don't like this" or "I think this is hard" with
"it's poorly designed".
>
> From the POV of interactive console programs, they /are/ poor. But the
> mistake is thinking that they are actual programs or commands, when
> really they are just filters. They are not designed to be standalone
> commands.
>
Of course they are programs. Some programs can be used as filters -
that doesn't mean they are not programs!
> Even 'cat', if I type it by itself, just sits there. (I wonder what use
> it has in a sequence like ... | cat | ...; what does it add to the data?)
>
Nothing, in this case.
And if I open - say - MS Word, then close it again, I have also done
nothing. Does that mean MS Word is a useless program that doesn't
really do anything?
> AFAICS, this stuff mainly works inside scripts. Or do people here spend
> all day manually piping stuff between programs?
This stuff works in scripts /and/ ad-hoc from the command line. People
use both, whatever is convenient at the time. I don't spend "all day"
piping stuff, but I guess I perhaps use pipes a dozen or so times a day
- the variance here is so big it's hard to give a sensible average.
Many cases are piping the output of one command into "less" and/or
"grep". Other common targets for pipes (for me) are head, tail (or
"tail -f"), "hexdump -C", "wc -l".
>
> As for alternatives, I don't know. There are any number of ways this
> could be done. But if everyone has become inured to this piping
> business, they will not be receptive to anything different.
No one has claimed pipes or *nix stream redirection is a "perfect"
system. No one has suggested they think things could not have been done
in different ways. Just as with C, you are mistaking "we know how this
works, we use it, we are happy enough with it that we can work with it,
we know why it is this way" with "we think this is perfect and nothing
else will come close". Discussions with you would be so much more
fruitful if you didn't have such an absurd "you're with us or against
us" attitude. Opinions are not binary.
Those of us who understand *nix shell usage, pipes and indirection, and
are familiar with *nix common command line tools, and are therefore able
to give qualified opinions based on facts and experience (i.e., not you,
and not Malcolm), seem to find them useful. I'm sure, however, we can
all think of potential improvements.
But like C, the advantages of familiarity and common implementations
greatly outweigh the disadvantages. Maybe "ls" would have been better
if it had been spelt "list". Perhaps "rm" should have had different
defaults, or "sed" could have been less cryptic. The fact that "ls",
"rm", and other fundamentals works exactly the same way on every *nix
system made in the last 40 years, gaining new features if needed without
breaking compatibility, is a /massive/ advantage.
You claim others are not open to considering something different, which
may potentially be "better" (for some values of "better"). You are
wrong. Most people, however, understand that momentum is important. It
can mean clearly inferior systems become standard - such as Windows or
the x86 ISA, which are technically massively inferior to alternatives,
but are successful due to momentum.
>
> Here however are some ideas:
>
> * Have versions of these tools for use as filters with no UI, just
> a default input and output, and versions for interactive use with
> helpful prompts. Or even just a sensibly named output! Instead of
> every program writing a.out.
>
Sometimes a "front end" with a nice UI /is/ useful. So people write
front ends with nice UI's - text-based or gui. Typically these are
great for common tasks, and are cumbersome or useless for rarer or more
advanced stuff. And that's fine - use whatever works best for you at
the time. If you think "ssh" is complicated from the command line, use
"putty" - but that won't handle all the uses that some people need.
But I most certainly don't want interactive and "helpful" prompts for
most of my command-line tools. It's fine on occasion if it is
necessary, useful if something out of the ordinary happens, and
appropriate for things like passwords. But when I know what I am doing,
why would I want to see help messages repeated? And if I don't know
what I am doing - it's the first time using a command, or I've forgotten
some details, then I have "prog --help", "man prog", or "google prog"
that will all give much more useful information than interactive prompts
ever could.
Can you imagine typing "ls" and being asked :
* Did you want to list files in the current directory, or elsewhere?
* Did you want to list all files, including hidden files?
* Did you want to use colour?
and then twenty more questions for the other common options for ls?
What would be the benefits of "sort" using command line options for
"filter" or "script" usage and then asking a dozen questions for
"interactive" use?
> * Have a concept of a current block of data, analogous to a clipboard.
> Then separate commands can load data, sort it, count it, display it,
> write it etc, with no need for intermediate named files.
You mean, a convenient way of moving data between programs? Sort of
like taking data output by one program, and passing it into another
program? Maybe something akin to a factory assembly line - or a
pipeline? Perhaps we could make this convenient with a simple symbol,
and let it be organised and controlled by the shell so that individual
programs don't need to implement anything special - they just read in
data and dump it out in a simple, standardised way, and with this
wonderful "pipeline" idea, people can tie together different existing
standard programs in any combinations they like! Genius! If only those
hopeless Unix people had thought about this 50+ years ago, instead of
messing around with stream redirection and pipes.
>
> But I'd be happier if this was all contained within a separate
> application from an OS shell program.
Yes, because it is /so/ much better if it is limited to a few commands
that you think of when writing this special application, than having a
general system that works with any commands.
Basically, all you are saying is that you'd like command line utilities
to work with a default file name "/tmp/clipboard" - something you didn't
want earlier on.
Let's use /tmp/x for convenience.
/tmp$ cat > fred
one
two
three
four
<ctrl-D>
> > load fred
> Data loaded
$ cp fred x
>
> > lc
> 4 lines
>
$ wc -l x
4 x
> > list
> 1 one
> 2 two
> 3 three
> 4 four
$ cat x
one
two
three
four
$ cat -n x
1 one
2 two
3 three
4 four
>
> > rev
> Reversed
tac x | sponge x
>
> > list
> 1 four
> 2 three
> 3 two
> 4 one
$ cat -n x
1 four
2 three
3 two
4 one
>
> > sort
> Sorted
>
$ sort x | sponge x
> > upper
$ awk '{print toupper($0)}' x | sponge x
>
> > list
> 1 FOUR
> 2 ONE
> 3 THREE
> 4 TWO
$ cat -n x
1 FOUR
2 ONE
3 THREE
4 TWO
>
> > save bill
> Written to bill
>
> > q
>
$ cp x bill
The "sponge" utility reads all of its stdin, then writes the file.
Otherwise, since Unix is inherently multi-tasking and runs the programs
in parallel (unlike your utility), trying to redirect output back into
the same file you use for output is a race condition. Utilities are
generally designed for pipes, not destructive changes to a single file.
With pipes, this is all vastly simpler:
$ cat fred | tac | sort | awk '{print toupper($0)}' > bill
Oh, and the sorting and case conversion works for your locale, including
UTF-8.
[toc] | [prev] | [next] | [standalone]
| From | bart <bc@freeuk.com> |
|---|---|
| Date | 2024-02-01 15:32 +0000 |
| Message-ID | <upgdic$24dp0$1@dont-email.me> |
| In reply to | #381466 |
On 01/02/2024 14:35, David Brown wrote:
> On 01/02/2024 01:21, bart wrote:
>> * Have versions of these tools for use as filters with no UI, just
>> a default input and output, and versions for interactive use with
>> helpful prompts. Or even just a sensibly named output! Instead of
>> every program writing a.out.
>>
>
> Sometimes a "front end" with a nice UI /is/ useful. So people write
> front ends with nice UI's - text-based or gui. Typically these are
> great for common tasks, and are cumbersome or useless for rarer or more
> advanced stuff. And that's fine - use whatever works best for you at
> the time. If you think "ssh" is complicated from the command line, use
> "putty" - but that won't handle all the uses that some people need.
>
>
> But I most certainly don't want interactive and "helpful" prompts for
> most of my command-line tools. It's fine on occasion if it is
> necessary, useful if something out of the ordinary happens, and
> appropriate for things like passwords. But when I know what I am doing,
> why would I want to see help messages repeated? And if I don't know
> what I am doing - it's the first time using a command, or I've forgotten
> some details, then I have "prog --help", "man prog", or "google prog"
> that will all give much more useful information than interactive prompts
> ever could.
>
> Can you imagine typing "ls" and being asked :
>
> * Did you want to list files in the current directory, or elsewhere?
> * Did you want to list all files, including hidden files?
> * Did you want to use colour?
>
> and then twenty more questions for the other common options for ls?
>
>
> What would be the benefits of "sort" using command line options for
> "filter" or "script" usage and then asking a dozen questions for
> "interactive" use?
I'd classify command-line programs into categories:
* Filters, as I explained before, which are designed to work with piped data
* Programs that can meaningfully be run with no command line options
(such as your 'ls' example), because a default action is defined
* Programs that expect command line parameters, which can generate an
error message or usage info if missing
* Programs that launch into an on-going session, which may or may not
take command line parameters (eg. python interpreter)
* Everything else, programs which are launched from the command line but
do not otherwise have a CLI, eg. a GUI text editor.
The troublesome ones are those I've called filters. Some programs I
expect to behaviour conventionally, unexpectedly behave as filters, such
as 'as'.
>
>> * Have a concept of a current block of data, analogous to a clipboard.
>> Then separate commands can load data, sort it, count it, display it,
>> write it etc, with no need for intermediate named files.
>
> You mean, a convenient way of moving data between programs? Sort of
...
>
>>
>> But I'd be happier if this was all contained within a separate
>> application from an OS shell program.
>
> Yes, because it is /so/ much better if it is limited to a few commands
> that you think of when writing this special application, than having a
> general system that works with any commands.
>
> Basically, all you are saying is that you'd like command line utilities
> to work with a default file name "/tmp/clipboard" - something you didn't
> want earlier on.
No. Someone said that it is convenient to run a sequence of programs,
where each processes the output of the other, without having to
explicitly named intermediate files.
I'm exploring other ways of doing that ...
> Let's use /tmp/x for convenience.
>
> /tmp$ cat > fred
> one
> two
> three
> four
> <ctrl-D>
>
> > > load fred
> > Data loaded
>
> $ cp fred x
...
> $ cat -n x
> 1 FOUR
> 2 ONE
> 3 THREE
> 4 TWO
>
> >
> > > save bill
> > Written to bill
> >
> > > q
> >
>
> $ cp x bill
>
>
> With pipes, this is all vastly simpler:
>
> $ cat fred | tac | sort | awk '{print toupper($0)}' > bill
... one way, which follows on from my previous suggestion to have two
versions of filter utilities, might be to have versions which work on
that blob of current data as I demonstrated.
Then on the shell command line you'd have:
> cload fred
> ctac
> csort
> cawk ...
> csave bill
Any inputs will always come from that blob; it will not just do nothing
waiting for input, unless the command is specifically for that.
And if so, it can prompt for it. For that matter, it can also write
messages confirming what it's just done, or show a progress report.
If you like, you can also have a stack of such data blobs, so:
> cload fred
> cdupl
> csave bill
> crev
> csave llib
(I think I've just invented shell-Forth!)
I've just realised why it is that your filter programs don't show
prompts or any kinds of messages: because those are sent to stdout, and
therefore will screw up any data that is being sent there as the primary
output.
THAT'S why sending what ought to be packaged data to stdout is Wrong.
> The "sponge" utility reads all of its stdin, then writes the file.
> Otherwise, since Unix is inherently multi-tasking and runs the programs
> in parallel (unlike your utility), trying to redirect output back into
> the same file you use for output is a race condition. Utilities are
> generally designed for pipes, not destructive changes to a single file.
My utility is like pretty much any application that loads a file, does
something with it, and writes it out. (Eg. text or image editors.)
So that kind of pattern is well understand. The difference is that your
filters tend to bluntly work on the whole blob of data.
The kind of REPL utility I outlined is far more user-friendly. The data
it deals with isn't as transient as the data in a pipe either.
Halfway through my session, the data is still there. You can examine it
so far, and decide where to go next, or perhaps reverse the last stup.
When you write a|b|c>d, it whizzes through it all at once. I can write
more on this but I simply don't think that any 'Unix-head' here is going
to get it; it's too ingrained.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-02-01 12:23 -0800 |
| Message-ID | <87zfwkorwp.fsf@nosuchdomain.example.com> |
| In reply to | #381481 |
bart <bc@freeuk.com> writes:
[...]
> I've just realised why it is that your filter programs don't show
> prompts or any kinds of messages: because those are sent to stdout,
> and therefore will screw up any data that is being sent there as the
> primary output.
Yes! (But your use of "your" is odd. Nobody here owns those programs.)
> THAT'S why sending what ought to be packaged data to stdout is Wrong.
No.
--
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 | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-02-02 03:26 +0100 |
| Message-ID | <uphjrr$2al2n$1@dont-email.me> |
| In reply to | #381511 |
> bart <bc@freeuk.com> writes: > [...] >> I've just realised why it is that your filter programs don't show >> prompts or any kinds of messages: because those are sent to stdout, >> and therefore will screw up any data that is being sent there as the >> primary output. Erm, no. Filter programs just don't need a prompt. And if you have a program that want to provide a prompt, and provide data on standard output, you usually wouldn't use stdout for that; use stderr or /dev/tty, depending on the intention of the tool. And even if you intend to use a prompt on stdout (what really sounds as a weak idea) you can program a test whether your file descriptor is attached to the tty if you like. To demonstrate that, here's some ksh code... $ ( exec 0>&- ; [[ -t 0 ]] ; echo $? ) # stdin closed 1 # error $ ( [[ -t 0 ]] ; echo $? ) # stdin attached to tty 0 # okay $ ls x | ( [[ -t 0 ]] ; echo $? ) # stdin attached to pipe 1 # error Janis
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2024-02-02 23:41 +0000 |
| Message-ID | <87plxeph82.fsf@bsb.me.uk> |
| In reply to | #381419 |
bart <bc@freeuk.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 think they're poorly designed too.
I am curious to read your reasoning...
> From the POV of interactive console programs, they /are/ poor. But the
> mistake is thinking that they are actual programs or commands, when really
> they are just filters. They are not designed to be standalone
> commands.
So it's a bad design, not because of the nature of the data ("binary"
vs. "text") but because you claim a filter is not a command? Where does
that notion come from?
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 01:53 +0000 |
| Message-ID | <upetj9$1p0ag$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. > >> 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. So whilst of course you can get this to work, it's not very robust. If additionally the data is binary or text which can't be inspected by a human, then you can't easily construct test inputs to get the individual programs working and debugged independently of the others. But you are right that creating temporary binary files isn't ideal either. The files tend to hang about and then people wonder what they mean and if they are an essential component of something. In reality when getting a video game together, you need a lot of temporary binary files - you can't have raw sources, pipelines, and a final executable. And our Azure build pipeline works that way too. It doesn't pipe C source to the compilers, it gathers the source, does the pre-processing, and creates temporary files which the compilers are invoked upon. Then it deletes them. It is indeed endless input and output file names to be juggled and tidied up afterward. -- 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 14:45 +0000 |
| Message-ID | <f8OuN.411736$83n7.231512@fx18.iad> |
| 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. Even a monolithic program is decomposed into subroutines (or malcolm functions). A pipeline is the same concept at a higher level. >Load the encryoted text into memory, and then pass it to subroutines to >do the various analyses. So your program is arbitrarily large and needs to be recompiled to add new subroutines. Advantage to the pipeline, again.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 14:57 +0000 |
| Message-ID | <upgbhd$23u8i$1@dont-email.me> |
| In reply to | #381469 |
On 01/02/2024 14:45, Scott Lurndal wrote: > 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. > > Even a monolithic program is decomposed into subroutines (or malcolm functions). > > A pipeline is the same concept at a higher level. > Exactly. So whilst it might have some advantages, they aren't going to be very large, because as you say, it;s the same basic concept. >> Load the encryoted text into memory, and then pass it to subroutines to >> do the various analyses. > > So your program is arbitrarily large and needs to be recompiled > to add new subroutines. Advantage to the pipeline, again. > The computer I'm typing this on isn't especially expensive and is just my personal machine. But it has six cores each of which execute 3.7 billion instructions per second. So programs have to be very large indeed before compile time is a significant problem. -- 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:47 +0100 |
| Message-ID | <upgedo$24ick$1@dont-email.me> |
| In reply to | #381474 |
On 01.02.2024 15:57, Malcolm McLean wrote: > On 01/02/2024 14:45, Scott Lurndal wrote: >> Malcolm McLean <malcolm.arthur.mclean@gmail.com> writes: >>> I'd write a monolithic program. I certainly want re-usability of functions, modules, components, commands, and systems. (And I want no duplication on any level.) >> Even a monolithic program is decomposed into subroutines (or malcolm >> functions). There are various ways to organize software. Some supported by the language, some by the OS mechanisms, some specifically implemented. >> A pipeline is the same concept at a higher level. Functions is a way, communicating processes is a way, etc. etc. etc. All can be taken to combine various entities. All mechanisms can be used together or some omitted. > Exactly. So whilst it might have some advantages, they aren't going to > be very large, because as you say, it;s the same basic concept. I think that you draw the wrong conclusion (on a statement that is prone to misunderstandings or even wrong). Pipelines are a very useful method to let processes communicate in a one-way direction (as the name already suggests). From that it's immediately recognizable that filters are a natural element in that OS-architectural glue. One original Unix philosophy was to have specialized commands that do one thing well, and to combine such tasks as necessary. (To some degree there was as similar statement concerning C function design.) Unfortunately some popular GNU tools deviate from that. Features get incorporated (as duplicates) in many tools (instead of using the existing specialized one). Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 16:22 +0000 |
| Message-ID | <nzPuN.297651$PuZ9.37505@fx11.iad> |
| In reply to | #381484 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 01.02.2024 15:57, Malcolm McLean wrote: >> On 01/02/2024 14:45, Scott Lurndal wrote: >> Exactly. So whilst it might have some advantages, they aren't going to >> be very large, because as you say, it;s the same basic concept. > >I think that you draw the wrong conclusion (on a statement that is >prone to misunderstandings or even wrong). > >Pipelines are a very useful method to let processes communicate in >a one-way direction (as the name already suggests). From that it's >immediately recognizable that filters are a natural element in that >OS-architectural glue. > >One original Unix philosophy was to have specialized commands that >do one thing well, and to combine such tasks as necessary. (To some >degree there was as similar statement concerning C function design.) >Unfortunately some popular GNU tools deviate from that. Features get >incorporated (as duplicates) in many tools (instead of using the >existing specialized one). I believe the classic example is the documenters workbench. Troff converts a set of page layout directives into a typeset document. Originally for the CAT typesetter, but I'll address that later. So, now you want to add tables. You can modify troff to add new macros that use existing markup directives, or you can add a filter that converts a 'table description' language into troff markup directives. $ < document.tr | tbl | troff -mm > typesetter_output Now, you want to add support for arbitrary mathematical formulae. You can modify troff to add more macros, or you can write a filter that converts an 'equation description' to troff and add that to your pipeline; $ <document.tr | eqn | tbl | troff -mm > typesetter_output Now, you realize that you want to support multiple typesetters, so you can either modify troff to support all possible typesetters, or you can add post processing filters. $ <document.tr | eqn | tbl | ditroff -mm | dit2cat > typesetter_output $ <document.tr | eqn | tbl | ditroff -mm | dit2ps > postscript output Then you might want to be able to include pictures in your document. $ <document.tr | pic | eqn | tbl | ditroff -mm | dit2ps | ps2pdf > document.pdf. Or you might want ascii text output $ <document.tr | pic | eqn | tbl | nroff -mm > document.txt
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-02-01 15:55 +0100 |
| Message-ID | <upgbd6$23tto$2@dont-email.me> |
| In reply to | #381430 |
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?
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-02-01 15:41 +0000 |
| Message-ID | <upge2t$24gnk$1@dont-email.me> |
| In reply to | #381473 |
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. 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? -- 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 17:15 +0100 |
| Message-ID | <upgg36$24rs7$1@dont-email.me> |
| In reply to | #381482 |
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.
Reasons to not use pipelines are when you don't have a linear flow.
In some circumstances you can bypass the pipe (opening a side-channel)
on other cases you can't or it's overly messy to do so.
Reasons not to use in-memory processing are of course if you have huge
amounts of data. Then you need filtering and pipeline processing.
(A former fellow student who worked for the ESO told me remarkable
things about the amounts of data they continuously receive and that
must on the fly be processed.) Another more recent example can be
processing of real time data for Digital Twins (e.g. city models).
Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-02-01 19:36 +0000 |
| Message-ID | <LoSuN.420648$83n7.151350@fx18.iad> |
| In reply to | #381489 |
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
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <433-929-6894@kylheku.com> |
|---|---|
| Date | 2024-02-01 19:50 +0000 |
| Message-ID | <20240201114540.189@kylheku.com> |
| In reply to | #381503 |
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);
}
--
TXR Programming Language: http://nongnu.org/txr
Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal
Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
Page 28 of 33 — ← Prev page 1 … 26 27 [28] 29 30 … 33 Next page →
Back to top | Article view | comp.lang.c
csiph-web