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 25 of 33 — ← Prev page 1 … 23 24 [25] 26 27 … 33 Next page →
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-31 13:49 +0100 |
| Message-ID | <updfld$1gv55$1@dont-email.me> |
| In reply to | #381326 |
On 31.01.2024 13:15, Malcolm McLean wrote: > On 31/01/2024 10:43, Michael S wrote: >> >> Frankly, Unix redirection racket looks like something hacked together >> rather than designed as result of the solid thinking process. >> As long as there were only standard input and output it was sort of >> logical. But when they figured out that it is insufficient, they had >> chosen a quick hack instead of constructing a solution that wouldn't >> offend engineering senses of any non-preconditioned observer. (What a bullshit.) >> > It was designed for very memory constrained systems which handled text > on a line by line basis. So one line of a long file wuld be processed > and passed down the pipeline, and you wouldn't need temporary disk files > or large amounts of memory. I'm sure it worked quite well for that. You are right about the intention of pipes. (Though not only for "memory constrained systems", but generally to avoid unnecessary and costly disk I/O.) But it's not line oriented. (That would be non-performant.) In Unix systems there's a distinction between line-oriented and buffered I/O. You can configure I/O with what you want if you program your tools. Typically tools when in non-interactive mode use efficient buffered mode. And there's also methods to force buffered I/O to become line oriented (cf. 'pty') for specific cases where you want it. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-01-31 17:03 +0200 |
| Message-ID | <20240131170312.00006f30@yahoo.com> |
| In reply to | #381326 |
On Wed, 31 Jan 2024 12:15:23 +0000 Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > On 31/01/2024 10:43, Michael S wrote: > > On Tue, 30 Jan 2024 23:18:21 -0800 > > Tim Rentsch <tr.17687@z991.linuxsc.com> 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. 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. > >>> > >>> [...] > >> > >> Simple example (disclaimer: not tested): > >> > >> ssh foo 'cd blah ; tar -cf - . | gzip -c' | \ > >> (mkdir foo.blah ; cd foo.blah ; gunzip -c | tar -xf -) > >> > >> Of the five main programs in this command, four are using > >> standard out to send binary data: > >> > >> tar -cf - . > >> gzip -c > >> ssh foo [...] > >> gunzip -c > >> > >> The tar -xf - at the end reads binary data on standard in > >> but doesn't output any (or anything else for that matter). > >> > >> It is FAR more cumbersome to accomplish what this command > >> is doing without sending binary data through standard out. > > > > If I am not mistaken, tar, gzip and gunzip do not write binary data > > to standard output by default. They should be specifically told to > > do so. For ssh I don't know. Anyway, ssh is not a "normal" program > > so it's not surprising when textuality of ssh output is the same as > > textuality of the command it carries. > > > >> Anyone who doesn't understand this doesn't understand Unix. > > > > Frankly, Unix redirection racket looks like something hacked > > together rather than designed as result of the solid thinking > > process. As long as there were only standard input and output it > > was sort of logical. But when they figured out that it is > > insufficient, they had chosen a quick hack instead of constructing > > a solution that wouldn't offend engineering senses of any > > non-preconditioned observer. > It was designed for very memory constrained systems which handled > text on a line by line basis. So one line of a long file wuld be > processed and passed down the pipeline, and you wouldn't need > temporary disk files or large amounts of memory. I'm sure it worked > quite well for that. > > A concept of pipes is fine. I was not talking about that side. My objection is with each program having exactly 1 special input and exactly 2 special outputs. Instead of having, say, up to 5 of each, fully interchangeable with the first of the five being special only in that that it is a default and as such allows for shorter syntax in the shell. I would be surprised if something like that was not done by somebody. I would be even more surprised if idea did not cross the mind of Unix pioneers. However they decided to add stderr and to stop here. Most likely, because they didn't take themselves as seriously as few posters here take them 45-50 years later.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 15:49 +0000 |
| Message-ID | <WZtuN.273518$Wp_8.264429@fx17.iad> |
| In reply to | #381345 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 31 Jan 2024 12:15:23 +0000 >Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> It was designed for very memory constrained systems which handled >> text on a line by line basis. So one line of a long file wuld be >> processed and passed down the pipeline, and you wouldn't need >> temporary disk files or large amounts of memory. I'm sure it worked >> quite well for that. >> >> > >A concept of pipes is fine. I was not talking about that side. > >My objection is with each program having exactly 1 special input and >exactly 2 special outputs. Instead of having, say, up to 5 of each, >fully interchangeable with the first of the five being special only in >that that it is a default and as such allows for shorter syntax in the >shell. Each program has 1024 (on my system - it's configurable on a per-process basis) fully interchangable "inputs" and "outputs" (also known as files). $ application 5> /tmp/file5 will redirect file descriptor five to the specified file. There's nothing special about stdin, stdout or stderr other than that they are tags applied to the first three file descriptors. There is a convention the that the first file descriptor is used for input, the second for output and the third for diagnostic output. But it's just a convention
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-01-31 18:04 +0200 |
| Message-ID | <20240131180429.000038bf@yahoo.com> |
| In reply to | #381358 |
On Wed, 31 Jan 2024 15:49:10 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Wed, 31 Jan 2024 12:15:23 +0000 > >Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > > >> It was designed for very memory constrained systems which handled > >> text on a line by line basis. So one line of a long file wuld be > >> processed and passed down the pipeline, and you wouldn't need > >> temporary disk files or large amounts of memory. I'm sure it worked > >> quite well for that. > >> > >> > > > >A concept of pipes is fine. I was not talking about that side. > > > >My objection is with each program having exactly 1 special input and > >exactly 2 special outputs. Instead of having, say, up to 5 of each, > >fully interchangeable with the first of the five being special only > >in that that it is a default and as such allows for shorter syntax > >in the shell. > > Each program has 1024 (on my system - it's configurable on a > per-process basis) fully interchangable "inputs" and "outputs" (also > known as files). > > $ application 5> /tmp/file5 > > will redirect file descriptor five to the specified file. > > > There's nothing special about stdin, stdout or stderr other than > that they are tags applied to the first three file descriptors. > > There is a convention the that the first file descriptor > is used for input, the second for output and the third > for diagnostic output. But it's just a convention I don't understand. Are not descriptors 0,1 and 2 special in that that they are already open (I don't know if by OS or by shell) when the program starts and the rest of them, if ever used, have to be opened by the program code? On only remotely related note, what happens on your system when you want more than 1024 files to be open by one program simultaneously?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 16:54 +0000 |
| Message-ID | <OWuuN.57041$U1cc.43539@fx04.iad> |
| In reply to | #381363 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 31 Jan 2024 15:49:10 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >On Wed, 31 Jan 2024 12:15:23 +0000 >> >Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: >> >> >> It was designed for very memory constrained systems which handled >> >> text on a line by line basis. So one line of a long file wuld be >> >> processed and passed down the pipeline, and you wouldn't need >> >> temporary disk files or large amounts of memory. I'm sure it worked >> >> quite well for that. >> >> >> >> >> > >> >A concept of pipes is fine. I was not talking about that side. >> > >> >My objection is with each program having exactly 1 special input and >> >exactly 2 special outputs. Instead of having, say, up to 5 of each, >> >fully interchangeable with the first of the five being special only >> >in that that it is a default and as such allows for shorter syntax >> >in the shell. >> >> Each program has 1024 (on my system - it's configurable on a >> per-process basis) fully interchangable "inputs" and "outputs" (also >> known as files). >> >> $ application 5> /tmp/file5 >> >> will redirect file descriptor five to the specified file. >> >> >> There's nothing special about stdin, stdout or stderr other than >> that they are tags applied to the first three file descriptors. >> >> There is a convention the that the first file descriptor >> is used for input, the second for output and the third >> for diagnostic output. But it's just a convention > >I don't understand. >Are not descriptors 0,1 and 2 special in that that they are already >open (I don't know if by OS or by shell) when the program starts and the >rest of them, if ever used, have to be opened by the program code? That's a contract between a shell and an application. A shell doesn't need to provide POSIX semantics, although it will likely do so just to maintain compataiblity with existing applications. Applications like daemons usually are disconnected from stdin/stdout/stderr completely, as they're not designed for interactive use. Using the fork and exec (or posix_spawn) system calls, an application can invoke another application without the shell and any number of file descriptors can be left open for the child to use in any way. It's a contract between the two applications. > >On only remotely related note, what happens on your system when you >want more than 1024 files to be open by one program simultaneously? > $ ulimit -f 2048 Will increase the limit, to any arbitrary value, subject to system wide limits configured by the superuser (system manager). There's a system call (setrlimit) that an application can use as well, and the limit will be inherited by child processes. One might argue that there are few cases (absent network daemons) where more than 2k files will need to be open simultaneously. For each resource (address space size, core file size, max cpu time, file size, open files, et cetera, et alia) there are two values; a hard limit (which a process can never exceed) and a soft limit. A process can increase the soft limit up to the hard limit. In my case, the hard limit is 8192 and the soft limit is 1024. $ ulimit -aH address space limit (Kibytes) (-M) unlimited core file size (blocks) (-c) unlimited cpu time (seconds) (-t) unlimited data size (Kibytes) (-d) unlimited file size (blocks) (-f) unlimited locks (-x) unlimited locked address space (Kibytes) (-l) 64 message queue size (Kibytes) (-q) 800 nice (-e) 0 nofile (-n) 8192 nproc (-u) 63878 pipe buffer size (bytes) (-p) 4096 max memory size (Kibytes) (-m) unlimited rtprio (-r) 0 socket buffer size (bytes) (-b) 4096 sigpend (-i) 63878 stack size (Kibytes) (-s) unlimited swap size (Kibytes) (-w) not supported threads (-T) not supported process size (Kibytes) (-v) unlimited $ ulimit -aS address space limit (Kibytes) (-M) unlimited core file size (blocks) (-c) 0 cpu time (seconds) (-t) unlimited data size (Kibytes) (-d) unlimited file size (blocks) (-f) unlimited locks (-x) unlimited locked address space (Kibytes) (-l) 64 message queue size (Kibytes) (-q) 800 nice (-e) 0 nofile (-n) 1024 nproc (-u) 1024 pipe buffer size (bytes) (-p) 4096 max memory size (Kibytes) (-m) unlimited rtprio (-r) 0 socket buffer size (bytes) (-b) 4096 sigpend (-i) 63878 stack size (Kibytes) (-s) 8192 swap size (Kibytes) (-w) not supported threads (-T) not supported process size (Kibytes) (-v) unlimited
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2024-01-31 09:16 -0800 |
| Message-ID | <87ttmts9ro.fsf@nosuchdomain.example.com> |
| In reply to | #381377 |
scott@slp53.sl.home (Scott Lurndal) writes:
> Michael S <already5chosen@yahoo.com> writes:
[...]
>>On only remotely related note, what happens on your system when you
>>want more than 1024 files to be open by one program simultaneously?
>>
>
> $ ulimit -f 2048
>
> Will increase the limit, to any arbitrary value, subject to system
> wide limits configured by the superuser (system manager).
That sets the limit for file size. I think you mean "ulimit -n 2048".
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Medtronic
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 17:21 +0000 |
| Message-ID | <ykvuN.94321$STLe.72942@fx34.iad> |
| In reply to | #381381 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: >scott@slp53.sl.home (Scott Lurndal) writes: >> Michael S <already5chosen@yahoo.com> writes: >[...] >>>On only remotely related note, what happens on your system when you >>>want more than 1024 files to be open by one program simultaneously? >>> >> >> $ ulimit -f 2048 >> >> Will increase the limit, to any arbitrary value, subject to system >> wide limits configured by the superuser (system manager). > >That sets the limit for file size. I think you mean "ulimit -n 2048". Yes, thank you.
[toc] | [prev] | [next] | [standalone]
| From | Malcolm McLean <malcolm.arthur.mclean@gmail.com> |
|---|---|
| Date | 2024-01-31 15:53 +0000 |
| Message-ID | <updqd7$1j22q$1@dont-email.me> |
| In reply to | #381345 |
On 31/01/2024 15:03, Michael S wrote: > On Wed, 31 Jan 2024 12:15:23 +0000 > Malcolm McLean <malcolm.arthur.mclean@gmail.com> wrote: > >> On 31/01/2024 10:43, Michael S wrote: >>> On Tue, 30 Jan 2024 23:18:21 -0800 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> 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. 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. >>>>> >>>>> [...] >>>> >>>> Simple example (disclaimer: not tested): >>>> >>>> ssh foo 'cd blah ; tar -cf - . | gzip -c' | \ >>>> (mkdir foo.blah ; cd foo.blah ; gunzip -c | tar -xf -) >>>> >>>> Of the five main programs in this command, four are using >>>> standard out to send binary data: >>>> >>>> tar -cf - . >>>> gzip -c >>>> ssh foo [...] >>>> gunzip -c >>>> >>>> The tar -xf - at the end reads binary data on standard in >>>> but doesn't output any (or anything else for that matter). >>>> >>>> It is FAR more cumbersome to accomplish what this command >>>> is doing without sending binary data through standard out. >>> >>> If I am not mistaken, tar, gzip and gunzip do not write binary data >>> to standard output by default. They should be specifically told to >>> do so. For ssh I don't know. Anyway, ssh is not a "normal" program >>> so it's not surprising when textuality of ssh output is the same as >>> textuality of the command it carries. >>> >>>> Anyone who doesn't understand this doesn't understand Unix. >>> >>> Frankly, Unix redirection racket looks like something hacked >>> together rather than designed as result of the solid thinking >>> process. As long as there were only standard input and output it >>> was sort of logical. But when they figured out that it is >>> insufficient, they had chosen a quick hack instead of constructing >>> a solution that wouldn't offend engineering senses of any >>> non-preconditioned observer. >> It was designed for very memory constrained systems which handled >> text on a line by line basis. So one line of a long file wuld be >> processed and passed down the pipeline, and you wouldn't need >> temporary disk files or large amounts of memory. I'm sure it worked >> quite well for that. >> >> > > A concept of pipes is fine. I was not talking about that side. > > My objection is with each program having exactly 1 special input and > exactly 2 special outputs. Instead of having, say, up to 5 of each, > fully interchangeable with the first of the five being special only in > that that it is a default and as such allows for shorter syntax in the > shell. > > I would be surprised if something like that was not done by somebody. > I would be even more surprised if idea did not cross the mind of Unix > pioneers. However they decided to add stderr and to stop here. Most > likely, because they didn't take themselves as seriously as few posters > here take them 45-50 years later. > > The BabyX resource compiler taes images, fonts, etc and outputs C source. So it writes the source to standard outout to make it a bit easier for scripts to integrate it. Whether anyone has actually done that I don't know - always just redirect the iutout to a pipe and so there's nor real advantage over using a filename. However I recently modified the program to also output an associated header. Now the ASCII way to do that is to send an ETX to separate the outputs. That's never going work in an integration. So in fact I write to a .h file which I open internally. And so there's now very little point in having the main .c resuts on stnadard output. -- 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-01-31 17:29 +0100 |
| Message-ID | <updshb$1jka5$1@dont-email.me> |
| In reply to | #381345 |
On 31.01.2024 16:03, Michael S wrote: > > My objection is with each program having exactly 1 special input and > exactly 2 special outputs. Instead of having, say, up to 5 of each, > fully interchangeable with the first of the five being special only in > that that it is a default and as such allows for shorter syntax in the > shell. The first three are pre-assigned and read to use for application. You can redirect, close, or open them on shell level with a set of redirection commands, and you can do such things also on OS-level with the Unix system commands. I'm not sure why you mentioned 5, whether that's better or worse. There's naturally some limit on OS level on the number of parallel open file descriptors, but that limit is very high. Mind that you can always close unused ones. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-01-31 19:36 +0200 |
| Message-ID | <20240131193606.00007e96@yahoo.com> |
| In reply to | #381370 |
On Wed, 31 Jan 2024 17:29:30 +0100 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > > I'm not sure why you mentioned 5, whether that's better or worse. > There's naturally some limit on OS level on the number of parallel > open file descriptors, but that limit is very high. Mind that you > can always close unused ones. > > Janis > Five of each sort, i.e. five inputs and five outputs, sound good to me. Much more than five of each sort pre-opened by shell sound like too much. If there exist a need for more than five channels for communication between complex of programs then this complex of programs very likely was designed to work together and only together. And then any intervention of the user into communication between them will likely do more harm than good. Of course, I fully expect that usefully using more than three predefined channels of any particular direction would be very rare, but I still like five, or at least four, better than three. As to not using predefined direction and instead just providing a pool of up to 10 pre-open descriptors, this idea didn't cross my mind in those particular five minutes that I was writing my initial (yes, provocative, yes intentionally so) post. Right now I don't want to think whether I like it or not, because I see no good reasons to think deeply about this particular water under bridge.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-31 19:47 +0100 |
| Message-ID | <upe4kg$1l2fv$1@dont-email.me> |
| In reply to | #381385 |
On 31.01.2024 18:36, Michael S wrote:
> On Wed, 31 Jan 2024 17:29:30 +0100
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote:
>>
>> I'm not sure why you mentioned 5, whether that's better or worse.
>> There's naturally some limit on OS level on the number of parallel
>> open file descriptors, but that limit is very high. Mind that you
>> can always close unused ones.
>
> Five of each sort, i.e. five inputs and five outputs, sound good to me.
Well, to me it sounds like an arbitrary number, like four or seven.
But how are these pre-opened FDs then used? To which devices assigned?
We already have what most folks seem to use pre-opened: 0, 1, 2
When I need a new one I couple it with an existing one
exec 3>&1 4>&1 5>&1 ## but why open it in advance per default?
or to a file (where we may have a concrete demand for a second channel)
exec 3< ./my_input
exec 4> /tmp/my_output
and still using channel 0 and 1 (here still connected to the default)
in parallel.
>
> Much more than five of each sort pre-opened by shell sound like too
> much. If there exist a need for more than five channels for
> communication between complex of programs then this complex of programs
> very likely was designed to work together and only together. And then
> any intervention of the user into communication between them will
> likely do more harm than good.
>
> Of course, I fully expect that usefully using more than three
> predefined channels of any particular direction would be very rare, but
> I still like five, or at least four, better than three.
You should have an idea, though, to what they should initially point
to, and why you want them differentiated.
>
> As to not using predefined direction and instead just providing a pool
> of up to 10 pre-open descriptors, this idea didn't cross my mind in
> those particular five minutes that I was writing my initial (yes,
> provocative, yes intentionally so) post. Right now I don't want to
> think whether I like it or not, because I see no good reasons to
> think deeply about this particular water under bridge.
I don't think I understand what you wanted to say here.
(A pool is there, the shell manages it for you.)
As an amendment, in ksh there's also the feature to not manually
assign file descriptor numbers but automatically get them from
the shell by prepending '{var}' to the redirection; here some FD
greater than 10 will be chosen by that shell and it's number
stored in 'var'. This may be useful for applications that may
e.g. serve a couple equivalent communication partners.
Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 15:25 +0000 |
| Message-ID | <gDtuN.273514$Wp_8.83091@fx17.iad> |
| In reply to | #381319 |
Michael S <already5chosen@yahoo.com> writes: >On Tue, 30 Jan 2024 23:18:21 -0800 >Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Anyone who doesn't understand this doesn't understand Unix. > >Frankly, Unix redirection racket looks like something hacked together >rather than designed as result of the solid thinking process. It seems you don't understand Unix. >As long as there were only standard input and output it was sort of >logical. But when they figured out that it is insufficient, they had >chosen a quick hack instead of constructing a solution that wouldn't >offend engineering senses of any non-preconditioned observer. You mean like exec 3< /path/to/input/file read -u3 line_from_input file How does that offend your engineering senses?
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-31 16:33 +0100 |
| Message-ID | <updp8p$1j1i5$1@dont-email.me> |
| In reply to | #381353 |
On 31.01.2024 16:25, Scott Lurndal wrote: > Michael S <already5chosen@yahoo.com> writes: >> [...] > > You mean like > > exec 3< /path/to/input/file > read -u3 line_from_input file Careful with non-standard extensions like '-u'. > > How does that offend your engineering senses? It probably would if the standard redirection pattern would have been used here. It's certainly more "cryptic" than '-u3'. ;-) Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-01-31 17:42 +0200 |
| Message-ID | <20240131174249.00006e06@yahoo.com> |
| In reply to | #381353 |
On Wed, 31 Jan 2024 15:25:00 GMT scott@slp53.sl.home (Scott Lurndal) wrote: > Michael S <already5chosen@yahoo.com> writes: > >On Tue, 30 Jan 2024 23:18:21 -0800 > >Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > > >> Anyone who doesn't understand this doesn't understand Unix. > > > >Frankly, Unix redirection racket looks like something hacked together > >rather than designed as result of the solid thinking process. > > It seems you don't understand Unix. > That's likely. I learned it during short course ~30 years ago, then read 2 or 3 books about it and then used it quite sporadically. > >As long as there were only standard input and output it was sort of > >logical. But when they figured out that it is insufficient, they had > >chosen a quick hack instead of constructing a solution that wouldn't > >offend engineering senses of any non-preconditioned observer. > > You mean like > > exec 3< /path/to/input/file > read -u3 line_from_input file > > How does that offend your engineering senses? > That was not in 2-3 books that I had read. I can't say that I understand what is going on, what environment we are and whether what you show is generic or specific to 'exec' and 'read'.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 15:58 +0000 |
| Message-ID | <e6uuN.273591$Wp_8.219866@fx17.iad> |
| In reply to | #381357 |
Michael S <already5chosen@yahoo.com> writes: >On Wed, 31 Jan 2024 15:25:00 GMT >scott@slp53.sl.home (Scott Lurndal) wrote: >> You mean like >> >> exec 3< /path/to/input/file >> read -u3 line_from_input file >> >> How does that offend your engineering senses? >> > >That was not in 2-3 books that I had read. I can't say that I understand >what is going on, what environment we are and whether what you show is >generic or specific to 'exec' and 'read'. It is acutally specific to a shell which provides internal 'exec' and 'read' commands. There are dozens of shells available to suit the end-users requirements (bourne shell, korn shell, C shell et alia), many of them implement a common subset of commands defined by POSIX. From the unix kernel perspective, an application opens a file and a file descriptor is assigned (consecutively, starting at zero). There are no semantics associated with the fd which can refer to a terminal, pseudo-terminal, block device, character device, pipe, named fifo, or even a TCP connection to a remote host. Any semantics associated with the file descriptor are a contract between the shell and the application. One could certainly write a shell that doesn't use file descriptor zero as stdin (although that would be incompatable with applications written for the standard shells, all of which honor the convention that file descriptor zero is stdin). For portability between shells, POSIX has codified the relationship of stdin to fd 0, stdout to fd1, etc.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-31 17:05 +0100 |
| Message-ID | <updr44$1jcmu$1@dont-email.me> |
| In reply to | #381357 |
On 31.01.2024 16:42, Michael S wrote: > On Wed, 31 Jan 2024 15:25:00 GMT > scott@slp53.sl.home (Scott Lurndal) wrote: >> >> You mean like >> >> exec 3< /path/to/input/file >> read -u3 line_from_input file >> >> How does that offend your engineering senses? > > That was not in 2-3 books that I had read. I can't say that I understand > what is going on, what environment we are and whether what you show is > generic or specific to 'exec' and 'read'. '-u' is obviously an option of read. Various shells support it; at least ksh since 30 years, and bash meanwhile as well. But it's not in POSIX. Other redirections are standard, and these should certainly be known by anyone who had visited a course and read any book on the Unix shell. The syntax is not difficult, follows rules, and certainly not arbitrary. The one in above code is assigning the file descriptor 3 to the given file for reading. You can let a FD point to the channel another one is pointing to, like in the "well known" '2>&1' (where stderr is connected to the same channel than stdin currently points to). Similar you can in above example use the standard form 'read line_from_input_file <&3', which may certainly appear more cryptic than an option '-u3', but it's essential to any shell programmer. Janis
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-01-31 18:18 +0200 |
| Message-ID | <20240131181820.00007acc@yahoo.com> |
| In reply to | #381364 |
On Wed, 31 Jan 2024 17:05:23 +0100 Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > On 31.01.2024 16:42, Michael S wrote: > > On Wed, 31 Jan 2024 15:25:00 GMT > > scott@slp53.sl.home (Scott Lurndal) wrote: > >> > >> You mean like > >> > >> exec 3< /path/to/input/file > >> read -u3 line_from_input file > >> > >> How does that offend your engineering senses? > > > > That was not in 2-3 books that I had read. I can't say that I > > understand what is going on, what environment we are and whether > > what you show is generic or specific to 'exec' and 'read'. > > '-u' is obviously an option of read. Various shells support it; at > least ksh since 30 years, and bash meanwhile as well. But it's not in > POSIX. > The books were talking about Bourne shell and C shell. They acknowledged an existence of ksh, but didn't go into details. I don't remember if bash was mentioned at all. Of course, in practice in this century I used bash almost exclusively, but never learned it formally, by book, from start to finish. The same as over 90% of bash users, I'd guess. > Other redirections are standard, and these should certainly be known > by anyone who had visited a course and read any book on the Unix > shell. The syntax is not difficult, follows rules, and certainly not > arbitrary. > > The one in above code is assigning the file descriptor 3 to the given > file for reading. You can let a FD point to the channel another one is > pointing to, like in the "well known" '2>&1' (where stderr is > connected to the same channel than stdin currently points to). > Similar you can in above example use the standard form 'read > line_from_input_file <&3', which may certainly appear more cryptic > than an option '-u3', but it's essential to any shell programmer. > > Janis > I did understand '3<' by association with '2>' that was in the book, but more importantly, is something I use regularly. However I had never seen '3<' in the books.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-31 17:47 +0100 |
| Message-ID | <updtj6$1jqdh$1@dont-email.me> |
| In reply to | #381366 |
On 31.01.2024 17:18, Michael S wrote: > On Wed, 31 Jan 2024 17:05:23 +0100 > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > > The books were talking about Bourne shell and C shell. They acknowledged > an existence of ksh, but didn't go into details. I don't remember if > bash was mentioned at all. So that's understandable then. The C shell is not really suited for programming (and commonly depreciated; "C shell considered harmful"). And Bourne sh is indeed very restricted. > Of course, in practice in this century I used bash almost exclusively, > but never learned it formally, by book, from start to finish. In case that bash is still part of your working environment I suggest to update your knowledge by reading some good bash tutorial. It's really a huge gain if compared to Bourne sh. In case, though, you want to do _portable_ shell programming then take some book that clearly indicates what is POSIX and what is some extension. > The same as over 90% of bash users, I'd guess. Well, I think you have to differentiate the levels. Quite many users of bash take this shell as "quasi-standard"; which is mostly okay in a Linux world. And know exactly that universe. If you happen to work in a larger Unix universe that might be a hindrance. (Thus POSIX, or use of ksh, which is even more powerful than bash, or zsh, supplemented with its own but some more coherent concepts.) > > I did understand '3<' by association with '2>' that was in the book, > but more importantly, is something I use regularly. > However I had never seen '3<' in the books. It's just the numbers of file descriptors and whether it's an input > or output < channel, or even a read/write channel <> . That's why in books (or man pages) you regularly see the building blocks, not the complete enumeration. (See for example 'man ksh' Section "Input/Output". But careful; ksh has additional non-standard additions. So a peek into the POSIX docs might serve you better.) Janis
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2024-01-31 17:20 +0000 |
| Message-ID | <yjvuN.94320$STLe.5998@fx34.iad> |
| In reply to | #381376 |
Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >On 31.01.2024 17:18, Michael S wrote: >> On Wed, 31 Jan 2024 17:05:23 +0100 >> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: >(See for example 'man ksh' Section "Input/Output". But careful; ksh >has additional non-standard additions. So a peek into the POSIX docs >might serve you better.) FWIW, the POSIX shell language was based on a subset of ksh88.
[toc] | [prev] | [next] | [standalone]
| From | Janis Papanagnou <janis_papanagnou+ng@hotmail.com> |
|---|---|
| Date | 2024-01-31 20:11 +0100 |
| Subject | [OT] Unix shells and POSIX shell (was Re: iso646.h) |
| Message-ID | <upe60i$1latn$1@dont-email.me> |
| In reply to | #381383 |
On 31.01.2024 18:20, Scott Lurndal wrote: > Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes: >> On 31.01.2024 17:18, Michael S wrote: >>> On Wed, 31 Jan 2024 17:05:23 +0100 >>> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> wrote: > >> (See for example 'man ksh' Section "Input/Output". But careful; ksh >> has additional non-standard additions. So a peek into the POSIX docs >> might serve you better.) > > FWIW, the POSIX shell language was based on a subset of ksh88. Yes. POSIX was based pretty much on ksh88. The differences are not very large. If you're interested to know about the few differences have a look into the book of Bolsky and Korn (it's in the appendix). For more than three decades, though, there's ksh93 around. This is what we typically mean when we speak about ksh. (But careful, since the first version of ksh93 there had been a lot changes until now.) Quite some time passed, though, until the commercial Unixes changed their default ksh to ksh93. (I haven't any more access to commercial Unixes, so I cannot tell about the current state.) See what you get. On Linux you got only a ksh clone, first basically based on ksh88 (but I anyway never used it but downloaded the original AT&T ksh93). Meanwhile, I think, you should get a ksh93 on Linux per default. But I suggest to use the ksh93u+m (the version maintained by Martijn Dekker), instead; it has a lot errors fixed. A lot has changed between ksh88 and ksh93 already, and the current ksh93 version developed even further. (Its man page shows details.) Janis
[toc] | [prev] | [next] | [standalone]
Page 25 of 33 — ← Prev page 1 … 23 24 [25] 26 27 … 33 Next page →
Back to top | Article view | comp.lang.c
csiph-web