Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #393426 > unrolled thread
| Started by | "Paul Edwards" <mutazilah@gmail.com> |
|---|---|
| First post | 2025-05-20 16:06 +1000 |
| Last post | 2025-05-24 22:10 -0700 |
| Articles | 20 on this page of 343 — 23 participants |
Back to article view | Back to comp.lang.c
encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 16:06 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-20 07:27 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:33 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:10 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:23 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:37 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:00 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 06:49 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 07:02 +0000
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 21:04 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-08-18 00:30 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-08-19 18:09 -0400
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-21 19:51 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 05:04 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 14:13 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 22:46 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 19:07 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 23:15 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 09:26 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 00:44 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-24 02:26 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 20:10 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:08 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-23 19:29 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-24 00:08 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-31 08:20 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-31 21:42 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-01 07:58 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-01 07:43 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-02 09:35 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-02 15:24 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-06-02 19:14 -0400
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-02 23:54 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-03 01:02 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-03 19:41 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-03 18:25 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 10:29 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-06 14:10 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 19:10 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-06 17:24 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-06 19:26 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-07 04:04 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 06:24 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-07 19:58 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 18:31 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 02:43 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 21:22 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 03:56 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-07 23:57 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 10:06 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-08 08:55 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:02 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-08 15:08 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:18 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-09 09:20 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 12:58 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-08 16:55 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-08 17:45 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 03:21 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:07 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 07:13 +0800
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-09 10:21 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 13:01 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-08 22:52 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:06 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 00:28 +0800
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:05 +0200
Re: encapsulating directory operations wij <wyniijj5@gmail.com> - 2025-06-09 06:51 +0800
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-09 07:59 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 13:04 +0200
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-06-07 23:12 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 17:11 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-08 16:58 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-08 11:48 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-08 22:09 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 14:01 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 17:24 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 15:53 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 19:45 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-09 18:33 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-09 20:39 +0200
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-10 07:21 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-10 13:19 +0000
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-06-10 14:46 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-10 12:08 -0700
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-06-10 20:22 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-06-09 19:22 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-09 18:59 -0700
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 09:51 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-03 00:37 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 14:07 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-10 14:36 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-10 16:40 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-10 16:52 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-10 23:33 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-11 07:07 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-11 05:34 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-11 13:41 +0000
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-06-11 17:33 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-12 01:33 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 02:18 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 10:33 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:45 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 13:42 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 13:55 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 15:05 +0100
Re: encapsulating directory operations Muttley@DastardlyHQ.org - 2025-05-20 14:09 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:15 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:48 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 16:02 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 01:28 +1000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 05:43 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 14:27 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:32 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-24 06:54 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-28 05:41 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-28 14:10 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-11 20:15 -0700
Re: encapsulating directory operations Peter 'Shaggy' Haywood <phaywood@alphalink.com.au> - 2025-05-26 15:19 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-27 16:23 +0200
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-27 18:10 +0300
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-27 19:24 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-27 16:16 -0700
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-28 16:04 +0300
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-28 22:54 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-29 10:21 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:16 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-06 17:26 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-27 16:18 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 19:36 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 14:23 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-20 23:47 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 15:37 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 01:11 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 16:43 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:15 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 22:50 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:11 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-20 22:40 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 05:50 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:06 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 09:27 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-20 18:19 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 17:43 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 17:14 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 18:20 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 17:51 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 19:50 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 19:34 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:09 +0200
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 16:51 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 16:58 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 18:09 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-20 17:48 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-20 19:34 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:51 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 05:31 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:08 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 11:28 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 17:00 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 16:37 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 16:03 +0000
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-21 20:21 +0300
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-22 06:37 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-22 17:53 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 10:27 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:46 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-21 16:46 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 07:41 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 15:02 -0700
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:23 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:21 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 15:06 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:41 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 08:09 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 00:12 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:25 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:03 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-01-06 17:58 -0800
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-20 13:53 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 00:12 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 14:41 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 08:38 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 09:09 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 16:22 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 00:18 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 10:31 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 01:02 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 16:18 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 09:57 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 22:41 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:41 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:06 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:22 -0700
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 20:58 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:10 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 15:32 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 09:16 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 18:38 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:12 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-25 15:34 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 09:01 +1000
Re: encapsulating directory operations gazelle@shell.xmission.com (Kenny McCormack) - 2025-05-25 23:25 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:28 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 21:27 -0700
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-23 07:08 +0200
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 22:20 -0700
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-23 07:43 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 07:54 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-25 15:29 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:40 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-26 03:29 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 11:46 +1000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-26 09:43 -0400
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-26 17:16 +0000
Re: encapsulating directory operations vallor <vallor@cultnix.org> - 2025-05-26 04:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 08:31 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-26 03:37 +0200
Re: encapsulating directory operations Richard Harnden <richard.harnden@gmail.invalid> - 2025-05-23 16:09 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 17:50 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 16:57 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 18:00 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 17:22 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-23 11:10 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 20:27 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 21:35 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 21:10 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-23 23:13 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:22 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-24 06:46 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:27 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 09:39 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 09:37 +0000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 06:11 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 13:41 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 15:08 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 17:36 +0100
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-29 17:18 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 18:51 +0100
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 14:31 -0700
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-05-29 14:29 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 13:38 +0100
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-29 12:55 -0400
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 18:48 +0100
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 03:10 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 11:20 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 11:54 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 16:02 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 16:26 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 17:42 +0200
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:39 +0100
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-07-01 10:09 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-30 18:04 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-29 21:24 +0200
Re: encapsulating directory operations Michael S <already5chosen@yahoo.com> - 2025-05-29 23:24 +0300
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 21:27 +0100
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 13:45 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 22:09 +0100
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-29 21:19 +0000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-29 22:40 +0100
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:18 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 22:10 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-04 19:23 +1000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 13:05 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 00:00 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-04 17:30 +0200
Re: encapsulating directory operations Josef Möllers <josef@invalid.invalid> - 2025-06-04 20:48 +0200
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 21:09 +0000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-05 08:18 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 04:58 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-04 19:19 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 05:24 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-04 21:30 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 22:38 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 19:31 +1000
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-06-05 08:32 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 19:28 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-06-05 20:25 +1000
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-06-06 03:26 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-06-04 23:22 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-06-04 23:48 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 07:18 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-29 14:50 -0700
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 00:05 +0100
Re: encapsulating directory operations David Brown <david.brown@hesbynett.no> - 2025-05-30 17:37 +0200
Re: encapsulating directory operations Richard Harnden <richard.nospam@gmail.invalid> - 2025-05-30 17:25 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:39 +0100
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-30 17:32 +0100
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-05-30 02:46 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-30 03:42 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-30 07:34 +0000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-23 21:10 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 21:31 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-23 22:05 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-24 01:27 -0700
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-06-10 08:52 -0700
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 13:35 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-10 21:34 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 15:09 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 01:16 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-06-10 19:11 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 15:23 +0000
Re: encapsulating directory operations "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2025-06-11 11:57 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-06-11 15:32 +0000
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-02-03 04:39 -0800
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 08:44 +1000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 08:06 +1000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-22 18:24 -0700
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-23 02:19 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 19:31 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:45 +1000
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 13:59 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-23 07:52 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 01:18 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 09:48 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-26 00:15 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-26 11:50 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-29 07:26 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-30 18:47 +1000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 02:21 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-20 22:49 -0700
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 20:44 +1000
Re: encapsulating directory operations Richard Heathfield <rjh@cpax.org.uk> - 2025-05-21 12:06 +0100
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 11:15 -0700
Re: encapsulating directory operations scott@slp53.sl.home (Scott Lurndal) - 2025-05-21 21:02 +0000
Re: encapsulating directory operations Kaz Kylheku <643-408-1753@kylheku.com> - 2025-05-21 19:49 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:38 +1000
Re: encapsulating directory operations James Kuyper <jameskuyper@alumni.caltech.edu> - 2025-05-20 22:26 -0400
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-21 03:32 +0000
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:50 +1000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 00:03 +0000
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-05-22 02:20 +0200
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-22 02:53 +0000
Re: encapsulating directory operations Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2025-05-21 22:14 -0700
Re: encapsulating directory operations Jakob Bohm <egenagwemdimtapsar@jbohm.dk> - 2025-08-17 22:34 +0200
Re: encapsulating directory operations antispam@fricas.org (Waldek Hebisch) - 2025-05-21 21:19 +0000
Re: encapsulating directory operations Lawrence D'Oliveiro <ldo@nz.invalid> - 2025-05-23 01:17 +0000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-21 04:35 +0200
Re: encapsulating directory operations "Paul Edwards" <mutazilah@gmail.com> - 2025-05-21 19:45 +1000
Re: encapsulating directory operations Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2025-05-21 17:07 +0200
Re: encapsulating directory operations Bonita Montero <Bonita.Montero@gmail.com> - 2025-05-22 20:34 +0200
Re: encapsulating directory operations Tim Rentsch <tr.17687@z991.linuxsc.com> - 2025-05-24 22:10 -0700
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-24 02:26 +0000 |
| Message-ID | <100rao1$fv52$2@dont-email.me> |
| In reply to | #393551 |
On Fri, 23 May 2025 09:26:47 +1000, Paul Edwards wrote: > I've made multiple attempts to install WINE. Only one of them, > years ago, worked. Yes, with enough work, I could likely have > got it to work. Or you could pay money to someone with the smarts to do it properly. Look at Valve’s Steam Deck, for example: it uses WINE (actually Proton, which is built on top of WINE) to run a large enough chunk of Windows- specific games to be a successful commercial product. SteamOS is actually built on Arch Linux, of all things -- you know the geek meme “by the way, I use Arch”? Yes, *that* Arch. Are the Steam Deck buyers geeks? Of course not -- they’re the complete opposite, just ordinary folk who want to run their favourite games, nothing more. They want an appliance that you can just switch on and go, without having to fiddle about. Not something you can really say about Windows, is it ... ?
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-05-22 20:10 -0400 |
| Message-ID | <100oed9$3nor5$1@dont-email.me> |
| In reply to | #393549 |
On 5/22/25 19:15, Kaz Kylheku wrote: ... > POSIX is fairly decently supported on Windows by Cygwin. Ignoring for the moment the different between "fairly decently" and "fully, Does everyone who uses Windows do so, 100% of the time, through Cygwin? I believe not - so POSIX is not in universal use.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-23 02:08 +0000 |
| Message-ID | <20250522185758.895@kylheku.com> |
| In reply to | #393552 |
On 2025-05-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 5/22/25 19:15, Kaz Kylheku wrote: > ... >> POSIX is fairly decently supported on Windows by Cygwin. > > Ignoring for the moment the different between "fairly decently" and > "fully, Does everyone who uses Windows do so, 100% of the time, through > Cygwin? I believe not - so POSIX is not in universal use. It doesn't matter because you can ship the POSIX run-time with your solution; you don't have to rely on Windows having that pre-installed. POSIX is a kind of language: C language extension libraries as well as some utilities built on them. (The utilities are not always of interest in the context of a C program being ported to a platform via POSIX.) No computer speaks POSIX natively; something must be installed. It's just another language run-time. Some systems integrate the POSIX run time; they are built around it from ground up. Some systems need an extran run-time for it. Windows doens't come with Java either; that doesn't prevent Java application delivery targeting Windows. Speaking of which, I have better application delivery than Java on Windows than with Cygwin-based libraries. It's just .exe and .dll files: native Windows stuff, self-contained in its own installation directory. Java programs usually ask users to install Java first, which is ugly and unprofessional. (Write once, nag everywhere?) -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-05-23 19:29 -0400 |
| Message-ID | <100r0d5$a4lc$1@dont-email.me> |
| In reply to | #393558 |
On 5/22/25 22:08, Kaz Kylheku wrote: > On 2025-05-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 5/22/25 19:15, Kaz Kylheku wrote: >> ... >>> POSIX is fairly decently supported on Windows by Cygwin. >> >> Ignoring for the moment the different between "fairly decently" and >> "fully, Does everyone who uses Windows do so, 100% of the time, through >> Cygwin? I believe not - so POSIX is not in universal use. ... > No computer speaks POSIX natively; something must be installed. Yes, and POSIX could not be properly referred to as "Universal" unless it was universally installed - which it isn't. I can't believe that this point is being debated.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-05-24 00:08 +0000 |
| Message-ID | <20250523165902.287@kylheku.com> |
| In reply to | #393579 |
On 2025-05-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: > On 5/22/25 22:08, Kaz Kylheku wrote: >> On 2025-05-23, James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On 5/22/25 19:15, Kaz Kylheku wrote: >>> ... >>>> POSIX is fairly decently supported on Windows by Cygwin. >>> >>> Ignoring for the moment the different between "fairly decently" and >>> "fully, Does everyone who uses Windows do so, 100% of the time, through >>> Cygwin? I believe not - so POSIX is not in universal use. > ... >> No computer speaks POSIX natively; something must be installed. > > Yes, and POSIX could not be properly referred to as "Universal" unless > it was universally installed - which it isn't. I can't believe that this > point is being debated. The point requires no debate if we are talking about the POSIX environment, where if someone has such a thing, we can give them a #!/bin/sh script that will work in that environment. (And conversely, if they don't have such an environment, the script is of no use). The POSIX run-time for C programs is not in the same category. We can make programs which carry such a thing as their bundled run-time, and transparently use it. The user doesn't see any POSIX; just a program running on their host platform. It's the same why we don't care that malloc or printf are not universal. If we have a way to write hosted C for a platform and deliver programs, that delivery mechanism will somehow ensure that malloc and printf are there for our program, without the user having to install anything from a third party. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-05-31 08:20 +0200 |
| Message-ID | <101e738$vrrm$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393427 |
Am 20.05.2025 um 09:27 schrieb Lawrence D'Oliveiro: > On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote: > >> And in essence, when you read from a directory, the only thing you get >> is the filename. > > You want at least the type of entry as well, surely. > > <https://manpages.debian.org/readdir(3)> Easier to handle: https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-05-31 21:42 +0000 |
| Message-ID | <101ft3d$1feqh$2@dont-email.me> |
| In reply to | #393686 |
On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote: > Am 20.05.2025 um 09:27 schrieb Lawrence D'Oliveiro: >> >> On Tue, 20 May 2025 16:06:19 +1000, Paul Edwards wrote: >> >>> And in essence, when you read from a directory, the only thing you get >>> is the filename. >> >> You want at least the type of entry as well, surely. >> >> <https://manpages.debian.org/readdir(3)> > > Easier to handle: > https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html If you’re wanting language-specific facilities, then see if you can beat this <https://docs.python.org/3/library/os.html#os.walk>. For one thing, notice how it gives you the choice of whether to follow symlinks or not? Oh, and also notice os.fwalk(), which supports dirfds.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-01 07:58 +0200 |
| Message-ID | <101gq6l$1rdgj$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393692 |
Am 31.05.2025 um 23:42 schrieb Lawrence D'Oliveiro: > On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote: >> Easier to handle: >> https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html > If you’re wanting language-specific facilities, then see if you can beat > this <https://docs.python.org/3/library/os.html#os.walk>. > For one thing, notice how it gives you the choice of whether to follow > symlinks or not? Sth. like this: for( directory_entry const &de : recursive_directory_iterator( "\\", directory_options::follow_directory_symlink ) ) cout << de.path() << endl;
[toc] | [prev] | [next] | [standalone]
| From | Lawrence D'Oliveiro <ldo@nz.invalid> |
|---|---|
| Date | 2025-06-01 07:43 +0000 |
| Message-ID | <101h0an$1tkqk$1@dont-email.me> |
| In reply to | #393694 |
On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote: > Am 31.05.2025 um 23:42 schrieb Lawrence D'Oliveiro: > >> On Sat, 31 May 2025 08:20:33 +0200, Bonita Montero wrote: > >>> Easier to handle: >>> https://en.cppreference.com/w/cpp/filesystem/directory_iterator.html > >> If you’re wanting language-specific facilities, then see if you can >> beat this <https://docs.python.org/3/library/os.html#os.walk>. For >> one thing, notice how it gives you the choice of whether to follow >> symlinks or not? > > Sth. like this: > > for( directory_entry const &de : recursive_directory_iterator( "\\", > directory_options::follow_directory_symlink ) ) > cout << de.path() << endl; You need the dirfd functions to avoid certain potential security holes on operations with symlinks.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-02 09:35 +0200 |
| Message-ID | <101jk7i$34erh$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393695 |
Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: > On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote: >> Sth. like this: >> >> for( directory_entry const &de : recursive_directory_iterator( "\\", >> directory_options::follow_directory_symlink ) ) >> cout << de.path() << endl; > You need the dirfd functions to avoid certain potential security holes > on operations with symlinks. Which security holes ?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-02 15:24 +0000 |
| Message-ID | <1nj%P.3454$mAv4.2422@fx34.iad> |
| In reply to | #393696 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: > >> On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote: > >>> Sth. like this: >>> >>> for( directory_entry const &de : recursive_directory_iterator( "\\", >>> directory_options::follow_directory_symlink ) ) >>> cout << de.path() << endl; > >> You need the dirfd functions to avoid certain potential security holes >> on operations with symlinks. > >Which security holes ? > The fchownat() function shall be equivalent to the chown() and lchown() functions except in the case where path specifies a relative path. In this case the file to be changed is determined relative to the directory associated with the file descriptor fd instead of the current working directory. If the access mode of the open file description associated with the file descriptor is not O_SEARCH, the function shall check whether directory searches are permitted using the current permissions of the directory underlying the file descriptor. If the access mode is O_SEARCH, the function shall not perform the check. Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2025-06-02 19:14 -0400 |
| Message-ID | <101lb81$3irlj$1@dont-email.me> |
| In reply to | #393697 |
On 6/2/25 11:24, Scott Lurndal wrote: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: >> ... >>> You need the dirfd functions to avoid certain potential security holes >>> on operations with symlinks. >> >> Which security holes ? >> > > The fchownat() function shall be equivalent to the chown() and lchown() > functions except in the case where path specifies a relative path. In > this case the file to be changed is determined relative to the directory > associated with the file descriptor fd instead of the current working > directory. If the access mode of the open file description associated > with the file descriptor is not O_SEARCH, the function shall check > whether directory searches are permitted using the current permissions > of the directory underlying the file descriptor. If the access mode is > O_SEARCH, the function shall not perform the check. > > Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia. That describes what the functions do, it doesn't explain the potential security holes that they avoid. The hole might seem obvious to you, but it's certainly not obvious to me - probably because writing code to traverse directories is something I've almost never had to do.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-02 23:54 +0000 |
| Message-ID | <hRq%P.12208$Yx54.177@fx40.iad> |
| In reply to | #393698 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: >On 6/2/25 11:24, Scott Lurndal wrote: >> Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: >>> >... >>>> You need the dirfd functions to avoid certain potential security holes >>>> on operations with symlinks. >>> >>> Which security holes ? >>> >> >> The fchownat() function shall be equivalent to the chown() and lchown() >> functions except in the case where path specifies a relative path. In >> this case the file to be changed is determined relative to the directory >> associated with the file descriptor fd instead of the current working >> directory. If the access mode of the open file description associated >> with the file descriptor is not O_SEARCH, the function shall check >> whether directory searches are permitted using the current permissions >> of the directory underlying the file descriptor. If the access mode is >> O_SEARCH, the function shall not perform the check. >> >> Similiter for fstatat, faccessat, fchownat, openat, readlinkat et alia. > >That describes what the functions do, it doesn't explain the potential >security holes that they avoid. The hole might seem obvious to you, but >it's certainly not obvious to me - probably because writing code to >traverse directories is something I've almost never had to do. > > From the posix standard: "The purpose of the fstatat() function is to obtain the status of files in directories other than the current working directory without exposure to race conditions. Any part of the path of a file could be changed in parallel to a call to stat(), resulting in unspecified behavior. By opening a file descriptor for the target directory and using the fstatat() function it can be guaranteed that the file for which status is returned is located relative to the desired directory."
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <643-408-1753@kylheku.com> |
|---|---|
| Date | 2025-06-03 01:02 +0000 |
| Message-ID | <20250602174720.211@kylheku.com> |
| In reply to | #393699 |
On 2025-06-02, Scott Lurndal <scott@slp53.sl.home> wrote: > From the posix standard: > > "The purpose of the fstatat() function is to obtain the status > of files in directories other than the current working directory > without exposure to race conditions. Any part of the path of a > file could be changed in parallel to a call to stat(), resulting > in unspecified behavior. By opening a file descriptor for the target > directory and using the fstatat() function it can be guaranteed that > the file for which status is returned is located relative to the desired directory." The security guarantee you want is that when you follow some path /a/b/c/d/.., that none of the path components "a", "b", "c", "d", ... are under the control of an adversary. Adversary means any other user who is not you or root. (If you are root, any other user, therefore). If, say "c" is under the control of an adversary, then the adversary can make it a symlink, so that "d" is then anything whatsoever in any location whatsoever. I've developed an experimental security library called safepath which tries to validate a path for this kind of safety. https://www.kylheku.com/cgit/safepath/about/ Caveat: note the lack of a test suite in this project! It doesn't rely on these functions because, it's not necesary. If you know that /a/b/c is safe, then by induction you can proceed to /a/b/c/d. For instance if you are root, and non-root is not able to tamper with /a/b/c, then, generally speaking, there is no race condition to worry about in making two accesses to c: one to check its permissions and ownership, and another to traverse it. -- TXR Programming Language: http://nongnu.org/txr Cygnal: Cygwin Native Application Library: http://kylheku.com/cygnal Mastodon: @Kazinator@mstdn.ca
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-03 19:41 +0200 |
| Message-ID | <101nc3o$5pjd$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393697 |
Am 02.06.2025 um 17:24 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: >> >>> On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote: >> >>>> Sth. like this: >>>> >>>> for( directory_entry const &de : recursive_directory_iterator( "\\", >>>> directory_options::follow_directory_symlink ) ) >>>> cout << de.path() << endl; >> >>> You need the dirfd functions to avoid certain potential security holes >>> on operations with symlinks. >> >> Which security holes ? >> > > The fchownat() function shall be equivalent to the chown() and lchown() > functions except in the case where path specifies a relative path. In > this case the file to be changed is determined relative to the directory > associated with the file descriptor fd instead of the current working > directory. If the access mode of the open file description associated > with the file descriptor is not O_SEARCH, the function shall check > whether directory searches are permitted using the current permissions > of the directory underlying the file descriptor. If the access mode is > O_SEARCH, the function shall not perform the check. And why is this relevant for directory_iterator or recursive_directory_iterator ?
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-03 18:25 +0000 |
| Message-ID | <h6H%P.676329$McHf.348392@fx15.iad> |
| In reply to | #393703 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 02.06.2025 um 17:24 schrieb Scott Lurndal: >> Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: >>> >>>> On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote: >>> >>>>> Sth. like this: >>>>> >>>>> for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>> directory_options::follow_directory_symlink ) ) >>>>> cout << de.path() << endl; >>> >>>> You need the dirfd functions to avoid certain potential security holes >>>> on operations with symlinks. >>> >>> Which security holes ? >>> >> >> The fchownat() function shall be equivalent to the chown() and lchown() >> functions except in the case where path specifies a relative path. In >> this case the file to be changed is determined relative to the directory >> associated with the file descriptor fd instead of the current working >> directory. If the access mode of the open file description associated >> with the file descriptor is not O_SEARCH, the function shall check >> whether directory searches are permitted using the current permissions >> of the directory underlying the file descriptor. If the access mode is >> O_SEARCH, the function shall not perform the check. > >And why is this relevant for directory_iterator or >recursive_directory_iterator ? Why are you asking this question on comp.lang.c?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-06 10:29 +0200 |
| Message-ID | <101u8sb$25g28$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393704 |
Am 03.06.2025 um 20:25 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 02.06.2025 um 17:24 schrieb Scott Lurndal: >>> Bonita Montero <Bonita.Montero@gmail.com> writes: >>>> Am 01.06.2025 um 09:43 schrieb Lawrence D'Oliveiro: >>>> >>>>> On Sun, 1 Jun 2025 07:58:54 +0200, Bonita Montero wrote: >>>> >>>>>> Sth. like this: >>>>>> >>>>>> for( directory_entry const &de : recursive_directory_iterator( "\\", >>>>>> directory_options::follow_directory_symlink ) ) >>>>>> cout << de.path() << endl; >>>> >>>>> You need the dirfd functions to avoid certain potential security holes >>>>> on operations with symlinks. >>>> >>>> Which security holes ? >>>> >>> >>> The fchownat() function shall be equivalent to the chown() and lchown() >>> functions except in the case where path specifies a relative path. In >>> this case the file to be changed is determined relative to the directory >>> associated with the file descriptor fd instead of the current working >>> directory. If the access mode of the open file description associated >>> with the file descriptor is not O_SEARCH, the function shall check >>> whether directory searches are permitted using the current permissions >>> of the directory underlying the file descriptor. If the access mode is >>> O_SEARCH, the function shall not perform the check. >> >> And why is this relevant for directory_iterator or >> recursive_directory_iterator ? > > Why are you asking this question on comp.lang.c? Because you can have it easier than with opendir() / readdir().
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-06 14:10 +0000 |
| Message-ID | <3FC0Q.931590$G6Lf.397684@fx17.iad> |
| In reply to | #393730 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 03.06.2025 um 20:25 schrieb Scott Lurndal: >>>> The fchownat() function shall be equivalent to the chown() and lchown() >>>> functions except in the case where path specifies a relative path. In >>>> this case the file to be changed is determined relative to the directory >>>> associated with the file descriptor fd instead of the current working >>>> directory. If the access mode of the open file description associated >>>> with the file descriptor is not O_SEARCH, the function shall check >>>> whether directory searches are permitted using the current permissions >>>> of the directory underlying the file descriptor. If the access mode is >>>> O_SEARCH, the function shall not perform the check. >>> >>> And why is this relevant for directory_iterator or >>> recursive_directory_iterator ? >> >> Why are you asking this question on comp.lang.c? > >Because you can have it easier than with opendir() / readdir(). Personally, I'd use nftw to iterate over a path. https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2025-06-06 19:10 +0200 |
| Message-ID | <101v7d7$2cudl$1@raubtier-asyl.eternal-september.org> |
| In reply to | #393731 |
Am 06.06.2025 um 16:10 schrieb Scott Lurndal: > Bonita Montero <Bonita.Montero@gmail.com> writes: >> Am 03.06.2025 um 20:25 schrieb Scott Lurndal: > >>>>> The fchownat() function shall be equivalent to the chown() and lchown() >>>>> functions except in the case where path specifies a relative path. In >>>>> this case the file to be changed is determined relative to the directory >>>>> associated with the file descriptor fd instead of the current working >>>>> directory. If the access mode of the open file description associated >>>>> with the file descriptor is not O_SEARCH, the function shall check >>>>> whether directory searches are permitted using the current permissions >>>>> of the directory underlying the file descriptor. If the access mode is >>>>> O_SEARCH, the function shall not perform the check. >>>> >>>> And why is this relevant for directory_iterator or >>>> recursive_directory_iterator ? >>> >>> Why are you asking this question on comp.lang.c? >> >> Because you can have it easier than with opendir() / readdir(). > > Personally, I'd use nftw to iterate over a path. > > https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html That would be much nicer with a lambda which can take the context of the calling function.
[toc] | [prev] | [next] | [standalone]
| From | scott@slp53.sl.home (Scott Lurndal) |
|---|---|
| Date | 2025-06-06 17:24 +0000 |
| Message-ID | <CvF0Q.1165311$McHf.1120306@fx15.iad> |
| In reply to | #393732 |
Bonita Montero <Bonita.Montero@gmail.com> writes: >Am 06.06.2025 um 16:10 schrieb Scott Lurndal: >> Bonita Montero <Bonita.Montero@gmail.com> writes: >>> Am 03.06.2025 um 20:25 schrieb Scott Lurndal: >> >>>>>> The fchownat() function shall be equivalent to the chown() and lchown() >>>>>> functions except in the case where path specifies a relative path. In >>>>>> this case the file to be changed is determined relative to the directory >>>>>> associated with the file descriptor fd instead of the current working >>>>>> directory. If the access mode of the open file description associated >>>>>> with the file descriptor is not O_SEARCH, the function shall check >>>>>> whether directory searches are permitted using the current permissions >>>>>> of the directory underlying the file descriptor. If the access mode is >>>>>> O_SEARCH, the function shall not perform the check. >>>>> >>>>> And why is this relevant for directory_iterator or >>>>> recursive_directory_iterator ? >>>> >>>> Why are you asking this question on comp.lang.c? >>> >>> Because you can have it easier than with opendir() / readdir(). >> >> Personally, I'd use nftw to iterate over a path. >> >> https://pubs.opengroup.org/onlinepubs/9799919799/functions/nftw.html > >That would be much nicer with a lambda which can take the context >of the calling function. > That's a matter of opinion. In any case, nftw is a C function and C doesn't support lamda functions. nftw can be used in any C++ code, it is not restricted to C++17 or higher, which makes it far more portable than std::filesystem::directory_iterator (not to mention much easier to type :-).
[toc] | [prev] | [next] | [standalone]
Page 2 of 18 — ← Prev page 1 [2] 3 4 … 18 Next page →
Back to top | Article view | comp.lang.c
csiph-web