Re: getenv vs. locale

[higepon <higepon@xxxxxxxxx>]

Thank you for your suggestions.

> (a) Raises an exception (natural, but may be inconvenient in some cases)
> (b) Returns some value indicating such condition has happened
> (c) Allow an optional 'filter' argument.

I think (a) is good.
It is enough for my usage (CGI applications).

What cases are inconvenient?
Procedures return raw value(s) are necessary?

---
Taro Minowa(Higepon)

http://www.monaos.org/
http://code.google.com/p/mosh-scheme/

http://code.google.com/p/mosh-scheme/issues/list	


On Sun, Jul 20, 2008 at 4:20 PM, Shiro Kawai <shiro@xxxxxxxx> wrote:
> From: Ivan Shmakov <ivan@xxxxxxxxxxxxx>
> Subject: getenv vs. locale
> Date: Sat, 19 Jul 2008 00:46:56 +0700
>
>>       SRFI 98 reads:
>>
>> --cut--
>>     For obtaining the value of the environment value, getenv may use
>>     locale-setting information to encode the name, and decode the value
>>     of the environment variable.
>> --cut--
>>
>>       And it doesn't seem appropriate.
>>
>>       Historically, environment variables are used to specify
>>       filenames (either sole, or lists, as in the case of PATH.)
>>       However, filenames aren't actually ``strings'' on a number of
>>       the general purpose platforms currently in use, most notably on
>>       those of the POSIX flavour.
>
> Good point.  In principle, we should treat anything fed from
> the outside world as a binary vector until it goes through one of
> proper "gates" (e.g. ports).
>
> However, I guess almost all the time the caller of getenv would
> want to use the result as a string.  It would be inconvenient
> to insert conversion routine in every call.
> (BTW, R6RS's command-line procedure in (rnrs programs (6)) library
> is defined to return a list of strings, despite that the host
> operating system may pass a byte sequence that can't be converted
> to the implementation's string object.)
>
> I suggest to keep getenv returning a string, with additional
> specification when the actual environment value can't be converted.
> The resolution can be either:
>
> (a) Raises an exception (natural, but may be inconvenient in some cases)
> (b) Returns some value indicating such condition has happened
>    (not Schemey).
> (c) Allow an optional 'filter' argument.  If it is given, it should
>    be a procedure that takes one argument.  It is called with the
>    raw byte-vector value, and its return value is the result of
>    get-environment-variable.  The filter procedure is usually
>    supposed to return a string, but it may be an identity function
>    if the caller wants the raw byte-vector value.  It can raise
>    an exception if the raw value can't be converted to a string,
>    or can return some special value indicating the situation.
>
> If we take (a) or (b), we could add another procedures that
> return the raw value(s), in case the caller wants to process them.
>
> I think (c) is reasonably general, but it raises another issue:
> If we aim at r6rs, the filter procedure would take r6rs bytevector.
> If we look at r5rs compatibility, srfi-4 u8vector would be a
> natural choice.  Which way should we go?
>
> --shiro
>
>
>
>
>
>
>
>
>
>