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.