Review of SRFI 170 through 3.2 I/O
hga@xxxxxx
(22 Apr 2020 17:13 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
John Cowan
(22 Apr 2020 20:42 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Lassi Kortela
(22 Apr 2020 20:53 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
John Cowan
(22 Apr 2020 21:29 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Lassi Kortela
(22 Apr 2020 21:36 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Lassi Kortela
(22 Apr 2020 21:43 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
John Cowan
(23 Apr 2020 03:38 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
hga@xxxxxx
(22 Apr 2020 23:58 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Lassi Kortela
(23 Apr 2020 07:02 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Lassi Kortela
(23 Apr 2020 07:05 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Göran Weinholt
(23 Apr 2020 10:54 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Marc Feeley
(23 Apr 2020 11:09 UTC)
|
Per-thread umask
Lassi Kortela
(23 Apr 2020 11:30 UTC)
|
Re: Per-thread umask
Marc Feeley
(23 Apr 2020 11:44 UTC)
|
Re: Per-thread umask
Lassi Kortela
(23 Apr 2020 11:47 UTC)
|
Re: Per-thread umask
Marc Feeley
(23 Apr 2020 11:59 UTC)
|
Re: Per-thread umask
John Cowan
(23 Apr 2020 15:03 UTC)
|
Re: Per-thread umask
Marc Feeley
(23 Apr 2020 15:20 UTC)
|
Re: Per-thread umask
Lassi Kortela
(23 Apr 2020 16:02 UTC)
|
Re: Per-thread umask
John Cowan
(23 Apr 2020 16:03 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O Lassi Kortela (23 Apr 2020 11:14 UTC)
|
current directory and openat() et al
Lassi Kortela
(23 Apr 2020 11:27 UTC)
|
Re: current directory and openat() et al
Marc Feeley
(23 Apr 2020 13:56 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Marc Feeley
(23 Apr 2020 11:33 UTC)
|
Normalizing the current directory
Lassi Kortela
(23 Apr 2020 11:39 UTC)
|
Re: Normalizing the current directory
Marc Feeley
(23 Apr 2020 11:55 UTC)
|
Re: Normalizing the current directory
Lassi Kortela
(23 Apr 2020 12:10 UTC)
|
Using paths that are searchable but not completely readable
hga@xxxxxx
(23 Apr 2020 12:30 UTC)
|
Per-thread working directory and umask proposal
John Cowan
(23 Apr 2020 14:13 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Feeley
(23 Apr 2020 14:16 UTC)
|
Re: Per-thread working directory and umask proposal
John Cowan
(23 Apr 2020 16:07 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Nieper-Wißkirchen
(23 Apr 2020 16:14 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Feeley
(23 Apr 2020 16:25 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Nieper-Wißkirchen
(23 Apr 2020 17:26 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Feeley
(23 Apr 2020 17:55 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Nieper-Wißkirchen
(23 Apr 2020 18:55 UTC)
|
Re: Per-thread working directory and umask proposal
John Cowan
(23 Apr 2020 20:12 UTC)
|
Re: Per-thread working directory and umask proposal
Shiro Kawai
(23 Apr 2020 22:17 UTC)
|
Re: Per-thread working directory and umask proposal
Lassi Kortela
(24 Apr 2020 08:43 UTC)
|
Re: Per-thread working directory and umask proposal
Shiro Kawai
(24 Apr 2020 11:27 UTC)
|
Re: Per-thread working directory and umask proposal
Lassi Kortela
(24 Apr 2020 11:37 UTC)
|
Re: Per-thread working directory and umask proposal
Shiro Kawai
(24 Apr 2020 12:22 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Feeley
(24 Apr 2020 12:28 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Nieper-Wißkirchen
(26 Apr 2020 09:19 UTC)
|
Re: Per-thread working directory and umask proposal
John Cowan
(27 Apr 2020 22:46 UTC)
|
Re: Per-thread working directory and umask proposal
Shiro Kawai
(27 Apr 2020 23:42 UTC)
|
Re: Per-thread working directory and umask proposal
John Cowan
(28 Apr 2020 00:42 UTC)
|
Re: Per-thread working directory and umask proposal
Shiro Kawai
(28 Apr 2020 00:56 UTC)
|
os-working-directory
Lassi Kortela
(29 Apr 2020 09:23 UTC)
|
Re: os-working-directory
Duy Nguyen
(29 Apr 2020 09:28 UTC)
|
current-umask
Lassi Kortela
(29 Apr 2020 09:43 UTC)
|
Windows
Lassi Kortela
(29 Apr 2020 09:47 UTC)
|
Re: Windows
Lassi Kortela
(29 Apr 2020 09:49 UTC)
|
Re: Windows
John Cowan
(29 Apr 2020 14:53 UTC)
|
Re: current-umask
hga@xxxxxx
(29 Apr 2020 13:14 UTC)
|
Re: current-umask
Lassi Kortela
(29 Apr 2020 13:25 UTC)
|
Re: current-umask
Marc Feeley
(29 Apr 2020 13:31 UTC)
|
Re: current-umask
Marc Feeley
(29 Apr 2020 13:45 UTC)
|
Re: current-umask
Lassi Kortela
(29 Apr 2020 14:12 UTC)
|
Re: current-umask
hga@xxxxxx
(29 Apr 2020 16:21 UTC)
|
Re: current-umask
Lassi Kortela
(29 Apr 2020 16:44 UTC)
|
Re: current-umask
John Cowan
(30 Apr 2020 04:02 UTC)
|
Re: os-working-directory
John Cowan
(30 Apr 2020 02:49 UTC)
|
Re: os-working-directory
Lassi Kortela
(30 Apr 2020 06:12 UTC)
|
Re: os-working-directory
Sebastien Marie
(30 Apr 2020 07:19 UTC)
|
Re: os-working-directory
Sebastien Marie
(30 Apr 2020 07:53 UTC)
|
Should the SRFI mandate current-directory per thread?
Lassi Kortela
(30 Apr 2020 12:14 UTC)
|
Re: Should the SRFI mandate current-directory per thread?
Sebastien Marie
(30 Apr 2020 17:00 UTC)
|
Re: Per-thread working directory and umask proposal
hga@xxxxxx
(28 Apr 2020 01:03 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Feeley
(28 Apr 2020 01:42 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Nieper-Wißkirchen
(30 Apr 2020 07:11 UTC)
|
Re: Per-thread working directory and umask proposal
Marc Feeley
(30 Apr 2020 11:33 UTC)
|
Re: Per-thread working directory and umask proposal
John Cowan
(23 Apr 2020 18:38 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Sebastien Marie
(23 Apr 2020 13:32 UTC)
|
Definition of working directory
Lassi Kortela
(23 Apr 2020 13:51 UTC)
|
Re: Definition of working directory
Marc Feeley
(23 Apr 2020 14:07 UTC)
|
Re: Definition of working directory
Sebastien Marie
(23 Apr 2020 15:31 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
Marc Nieper-Wißkirchen
(23 Apr 2020 15:24 UTC)
|
Separate high-level and low-level APIs
Lassi Kortela
(23 Apr 2020 15:38 UTC)
|
Re: Separate high-level and low-level APIs
Marc Nieper-Wißkirchen
(23 Apr 2020 15:44 UTC)
|
Re: Separate high-level and low-level APIs
Lassi Kortela
(23 Apr 2020 15:48 UTC)
|
Re: Separate high-level and low-level APIs
hga@xxxxxx
(23 Apr 2020 16:19 UTC)
|
Re: Separate high-level and low-level APIs
Lassi Kortela
(23 Apr 2020 16:42 UTC)
|
Re: Review of SRFI 170 through 3.2 I/O
hga@xxxxxx
(23 Apr 2020 15:41 UTC)
|
>> The kernel translates relative pathnames to absolute ones anyway. It >> shouldn't be a problem if we translate one step earlier, on the Scheme side. > > I'd like if it were possible to keep a current working directory per > thread, fiber or whatever. That's the exact purpose of this proposal :) Gambit and Kawa would like it as well. > Are you aware of the *at() syscalls? From the Linux openat(2) manpage: > > Second, openat() allows the implementation of a per-thread > "current working directory", via file descriptor(s) maintained > by the application. (This functionality can also be obtained > by tricks based on the use of /proc/self/fd/dirfd, but less > efficiently.) > > These types of syscalls are also in POSIX-1.2008, AFAICT. Yes. The latest edition of POSIX has these ones: faccessat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/faccessat.html fchmodat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/fchmodat.html fchownat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/fchownat.html fstatat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/fstatat.html linkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/linkat.html mkdirat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkdirat.html mkfifoat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/mkfifoat.html mknodat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/mknodat.html openat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/openat.html readlinkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/readlinkat.html renameat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/renameat.html symlinkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/symlinkat.html unlinkat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/unlinkat.html utimensat() https://pubs.opengroup.org/onlinepubs/9699919799/functions/utimensat.html (excerpted from <https://github.com/lassik/emacs-posix-manual/blob/master/posix-manual-data.el>) > I suspect that if the current working directory is specified in terms > of parameter-like semantics then it should be possible to make use of > openat() etc behind the scenes Gambit does some of this; I suggest grepping the source code > while implementors who can't use such > syscalls can still have a current working directory parameter that is > more or less just a string (plus a check to see that the new directory > exists, I guess). AFAICT it should work as you say. OS kernels checks for existence of pathnames, so it's probably more reliable to defer existence checks to them and do only syntactic manipulation (merging the pathnames) on the Scheme side. Or did you mean specifically that setting the `working-directory` parameter should cause an error in case the directory does not exist, thereby matching the behavior of the chdir() syscall? That's a clever point that didn't occur to me. I guess it could use access() to check it, which is quite fast.