Email list hosting service & mailing list manager

Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (01 Dec 2020 12:27 UTC)
Re: [R7RS-small] get-environment-variables Lassi Kortela (01 Dec 2020 21:33 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (04 Dec 2020 19:17 UTC)
Re: [R7RS-small] get-environment-variables Lassi Kortela (04 Dec 2020 21:15 UTC)
Re: [R7RS-small] get-environment-variables Arthur A. Gleckler (04 Dec 2020 21:21 UTC)
Re: [R7RS-small] get-environment-variables Lassi Kortela (04 Dec 2020 21:24 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (04 Dec 2020 21:30 UTC)
Re: [R7RS-small] get-environment-variables Arthur A. Gleckler (04 Dec 2020 22:11 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (04 Dec 2020 22:22 UTC)
Re: [R7RS-small] get-environment-variables Arthur A. Gleckler (04 Dec 2020 22:31 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (04 Dec 2020 22:41 UTC)
Re: [R7RS-small] get-environment-variables Alex Shinn (05 Dec 2020 06:56 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (05 Dec 2020 11:51 UTC)
Re: [R7RS-small] get-environment-variables Shiro Kawai (05 Dec 2020 20:40 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (05 Dec 2020 22:58 UTC)
Re: [R7RS-small] get-environment-variables Shiro Kawai (06 Dec 2020 00:19 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (06 Dec 2020 15:54 UTC)
Re: [R7RS-small] get-environment-variables Alex Shinn (07 Dec 2020 00:52 UTC)
Re: [R7RS-small] get-environment-variables John Cowan (06 Dec 2020 04:42 UTC)
Re: [R7RS-small] get-environment-variables Alex Shinn (07 Dec 2020 00:28 UTC)
Re: [R7RS-small] get-environment-variables John Cowan (04 Dec 2020 23:19 UTC)
Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen (05 Dec 2020 11:17 UTC)
Re: [R7RS-small] get-environment-variables John Cowan (06 Dec 2020 05:03 UTC)

Re: [R7RS-small] get-environment-variables Marc Nieper-Wißkirchen 04 Dec 2020 19:17 UTC

Am Di., 1. Dez. 2020 um 22:33 Uhr schrieb Lassi Kortela <xxxxxx@lassi.io>:
>
> > PS: SRFI 170, which explicitly wants to implement a subset of POSIX, has
> > at least the same encoding problem by (mis)treating what are bytevectors
> > as strings.  For example, `directory-files` will break as soon as
> > filenames appear that cannot be interpreted in the current locale.  In
> > particular, this means that typical utilities like `ls` or `cp` cannot
> > be implemented with SRFI 170.
>
> This can be solved by either:
>
> 1. Adding an internal encoding tag to the Scheme implementation's string
> type, allowing a program to mix differently-encoded strings. If the
> environment variable encoding is unknown, a special encoding tag can be
> reserved to indicate that. This is quite non-ideal to require of all
> implementations of get-environment-variable.

I have thought along these lines as well, but I see two problems:

(a) A probably minor one: The encoding of an environment variable is
always unknown because there is conceptually none. It can only be
guessed.

(b) A bigger one: How should procedures like string-append act on
strings that are of different types? For example, one string may be a
string produced by utf8->string, another by, say, utf32->string, and
the third by `get-environment-variable` from a value that doesn't
encode a Unicode string.

> 2. If get-environment-variable is given the variable name as a
> bytevector instead of a string, return the value as a bytevector as
> well. Python 3 does this: compare the return value of os.listdir("/bin")
> and os.listdir(b"/bin").
>
> Pre-SRFI: https://github.com/pre-srfi/process-state-as-bytevectors

That's a nice solution (hack?) but it isn't a general solution. It
doesn't solve the problem for `command-line` or SRFI 170's
`current-directory`, for example.