Hi,
Jonathan Leffler schrieb:
> POSIX has a different view on the correct behaviour:
>
>
> NAME
>
> unsetenv - remove an environment variable
>
>
> SYNOPSIS
>
> |^[CX <javascript:open_code('CX')>] [Option Start] #include
> <stdlib.h
> <http://www.opengroup.org/onlinepubs/9699919799/basedefs/stdlib.h.html>>
>
> int unsetenv(const char */name/); [Option End]|
>
>
> DESCRIPTION
>
> The /unsetenv/() function shall remove an environment variable from
> the environment of the calling process. The /name/ argument points
> to a string, which is the name of the variable to be removed. The
> named argument shall not contain an '=' character. If the named
> variable does not exist in the current environment, the environment
> shall be unchanged and the function is considered to have completed
> successfully.
>
> If the application modifies /environ/ or the pointers to which it
> points, the behavior of /unsetenv/() is undefined. The /unsetenv/()
> function shall update the list of pointers to which /environ/ points.
>
> The /unsetenv/() function need not be thread-safe.
>
>
> RETURN VALUE
>
> Upon successful completion, zero shall be returned. Otherwise, -1
> shall be returned, /errno/ set to indicate the error, and the
> environment shall be unchanged.
>
>
> ERRORS
>
> The /unsetenv/() function shall fail if:
>
> [EINVAL]
> The /name/ argument is a null pointer, points to an empty
> string, or points to a string containing an '=' character.
>
>
>
> Note that unsetting a non-existent variable is explicitly documented as
> a successful no-op. This info from
>
> http://www.opengroup.org/onlinepubs/9699919799/functions/unsetenv.html
thanks very much for testing and the docu pointer!
Crazy that MacOSX documents its own way, but then actually seems to
behave posix-conform as desribed above :)
Got another mail that FreeBSD 7.2 behaves same too, so seems it makes no
sense to check for the return value; on NetWare I get -1 and errno 77
with a non-existent variable.
Gün.
