[BUG] Unicode variables can be exported and are exported metafied

[BUG] Unicode variables can be exported and are exported metafied

[ZyX]

Consider the following input (zsh -f, UTF-8 locale):

zyx-desktop% ус=1
zyx-desktop% export ус
zyx-desktop% env | grep '=1' | grep '^[^A-Z]'
у�с=1
zyx-desktop% env | grep '=1' | grep '^[^A-Z]' | hexdump -C
00000000  d1 83 a3 d1 81 3d 31 0a                           |.....=1.|
00000008
zyx-desktop% echo ус=1 | hexdump -C
00000000  d1 83 d1 81 3d 31 0a                              |....=1.|
00000007

You see here that variable named `ус` can be exported (not sure whether it is a bug or not), but its 0x83 byte which is the last byte of the first unicode codepoint that forms the variable name represented as UTF-8 is using zsh `Meta` escape in the `env` output (which clearly is a bug assuming the fact that unicode variable is exported is not).

Re: [BUG] Unicode variables can be exported and are exported metafied

[Peter Stephenson]

On Thu, 18 Dec 2014 21:19:25 +0300
ZyX <kp-pav@yandex.ru> wrote: 
> You see here that variable named `ус` can be exported (not sure
> whether it is a bug or not),

I *think* that's a "don't do that unless you actually need to..." but
feel free to present evidence otherwise.

> but its 0x83 byte which is the last byte of the first unicode
> codepoint that forms the variable name represented as UTF-8 is using
> zsh `Meta` escape in the `env` output (which clearly is a bug assuming
> the fact that unicode variable is exported is not).

Yes, indeed.

diff --git a/Src/params.c b/Src/params.c
index 79088d1..b87598a 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -4357,7 +4357,18 @@ arrfixenv(char *s, char **t)
 int
 zputenv(char *str)
 {
+    char *ptr;
     DPUTS(!str, "Attempt to put null string into environment.");
+    /*
+     * The environment uses NULL-terminated strings, so just
+     * unmetafy and ignore the length.
+     */
+    for (ptr = str; *ptr && *ptr != Meta; ptr++)
+	;
+    if (*ptr == Meta) {
+	str = dupstring(str);
+	unmetafy(str, NULL);
+    }
 #ifdef USE_SET_UNSET_ENV
     /*
      * If we are using unsetenv() to remove values from the
@@ -4366,7 +4377,6 @@ zputenv(char *str)
      * Unfortunately this is a slightly different interface
      * from what zputenv() assumes.
      */
-    char *ptr;
     int ret;
 
     for (ptr = str; *ptr && *ptr != '='; ptr++)

pws

Re: [BUG] Unicode variables can be exported and are exported metafied

[Peter Stephenson]

On Thu, 18 Dec 2014 19:29:17 +0000
Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> On Thu, 18 Dec 2014 21:19:25 +0300
> ZyX <kp-pav@yandex.ru> wrote: 
> > but its 0x83 byte which is the last byte of the first unicode
> > codepoint that forms the variable name represented as UTF-8 is using
> > zsh `Meta` escape in the `env` output (which clearly is a bug assuming
> > the fact that unicode variable is exported is not).
> 
> Yes, indeed.

And on import to the shell.

Currently averaging two patches per fix...

diff --git a/Src/params.c b/Src/params.c
index b87598a..1c51afd 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -641,7 +641,7 @@ split_env_string(char *env, char **name, char **value)
     if (!env || !name || !value)
 	return 0;
 
-    tenv = strcpy(zhalloc(strlen(env) + 1), env);
+    tenv = metafy(env, strlen(env), META_HEAPDUP);
     for (str = tenv; *str && *str != '='; str++)
 	;
     if (str != tenv && *str == '=') {

pws

Re: [BUG] Unicode variables can be exported and are exported metafied

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 744 bytes --]

On Dec 18, 2014 11:48 AM, "Peter Stephenson" <p.w.stephenson@ntlworld.com>
wrote:
>
> On Thu, 18 Dec 2014 19:29:17 +0000
> Peter Stephenson <p.w.stephenson@ntlworld.com> wrote:
> > On Thu, 18 Dec 2014 21:19:25 +0300
> > ZyX <kp-pav@yandex.ru> wrote:
> > > but its 0x83 byte which is the last byte of the first unicode
> > > codepoint that forms the variable name represented as UTF-8 is using
> > > zsh `Meta` escape in the `env` output (which clearly is a bug assuming
> > > the fact that unicode variable is exported is not).
> >
> > Yes, indeed.
>
> And on import to the shell.

Are we sure it's even "legal" to export Unicode variable names?  Internally
we can kinda ignore POSIX as we choose, but the environment crosses those
boundaries.

Re: [BUG] Unicode variables can be exported and are exported metafied

[Peter Stephenson]

On Thu, 18 Dec 2014 11:58:11 -0800
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Are we sure it's even "legal" to export Unicode variable names?  Internally
> we can kinda ignore POSIX as we choose, but the environment crosses those
> boundaries.

As far as I can see it's described as not portable, which is obviously
correct, but not actually a violation of anything.

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html

However...  AARGH we were already metafying and unmetafying the value, but
not the identifier...  So now we're doing it twice.

I will give it a bit more consideration before posting anything else.

pws

Fwd: Re: [BUG] Unicode variables can be exported and are exported metafied

[Bart Schaefer]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

Assuming it's OK to forward this.
---------- Forwarded message ----------
From: "Chet Ramey" <chet.ramey@case.edu>
Date: Dec 18, 2014 12:12 PM
Subject: Re: [BUG] Unicode variables can be exported and are exported
metafied
To: "Bart Schaefer" <schaefer@brasslantern.com>
Cc: <chet.ramey@case.edu>

On 12/18/14, 2:58 PM, Bart Schaefer wrote:

> Are we sure it's even "legal" to export Unicode variable names?
Internally
> we can kinda ignore POSIX as we choose, but the environment crosses those
> boundaries.

Yes, it is.

"Other characters may be permitted by an implementation; applications
shall tolerate the presence of such names."

http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap08.html#tag_08
--
``The lyf so short, the craft so long to lerne.'' - Chaucer
                 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

Re: [BUG] Unicode variables can be exported and are exported metafied

[Christoph (Stucki) von Stuckrad]

On Thu, 18 Dec 2014, Bart Schaefer wrote:

> Are we sure it's even "legal" to export Unicode variable names?  Internally
> we can kinda ignore POSIX as we choose, but the environment crosses those
> boundaries.

Independend of being 'legal' to me it seems dangerous!

Comparing the 'working as written' example:

~$ M='surprise; : ' MÄRCHEN=story sh -c 'echo $MÄRCHEN'
story

to running it with all the other shells I keep around
(bash, dash, ash, sash - untested ksh and csh)
you always get:

..................................vvvv
~$ M='surprise; : ' MÄRCHEN=story bash -c 'echo $MÄRCHEN'
surprise; : ÄRCHEN

Which gives interesting new ways to introduce security-sensitive
changes into environments by letting a Program check the
UTF8-named-Variable for its contents, but really inserting data
by the broken-part-name, which might be passed unchecked!

So PLEASE DO NOT EXPORT these !

Stucki


-- 
Christoph von Stuckrad      * * |nickname |Mail <stucki@mi.fu-berlin.de> \
Freie Universitaet Berlin   |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459|
Mathematik & Informatik EDV |\ *|if online|  (Di,Do,Fr):+49 30 77 39 6600|
Takustr. 9 / 14195 Berlin   * * |on IRCnet|Fax(home):   +49 30 77 39 6601/

Re: [BUG] Unicode variables can be exported and are exported metafied

[Christoph (Stucki) von Stuckrad]

On Thu, 18 Dec 2014, Bart Schaefer wrote:

> Are we sure it's even "legal" to export Unicode variable names?  Internally
> we can kinda ignore POSIX as we choose, but the environment crosses those
> boundaries.

Independend of being 'legal' to me it seems dangerous!

Comparing the 'working as written' example:

~$ M='surprise; : ' MÄRCHEN=story sh -c 'echo $MÄRCHEN'
story

to running it with all the other shells I keep around
(bash, dash, ash, sash - untested ksh and csh)
you always get:

..................................vvvv
~$ M='surprise; : ' MÄRCHEN=story bash -c 'echo $MÄRCHEN'
surprise; : ÄRCHEN

Which gives interesting new ways to introduce security-sensitive
changes into environments by letting a Program check the
UTF8-named-Variable for its contents, but really inserting data
by the broken-part-name, which might be passed unchecked!

So PLEASE DO NOT EXPORT these !

Stucki


-- 
Christoph von Stuckrad      * * |nickname |Mail <stucki@mi.fu-berlin.de> \
Freie Universitaet Berlin   |/_*|'stucki' |Tel(Mo.,Mi.):+49 30 838-75 459|
Mathematik & Informatik EDV |\ *|if online|  (Di,Do,Fr):+49 30 77 39 6600|
Takustr. 9 / 14195 Berlin   * * |on IRCnet|Fax(home):   +49 30 77 39 6601/

Re: [BUG] Unicode variables can be exported and are exported metafied

[Павлов Николай Александрович]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

On December 19, 2014 9:17:37 PM EAT, "Christoph (Stucki) von Stuckrad" <stucki@mi.fu-berlin.de> wrote:
>On Thu, 18 Dec 2014, Bart Schaefer wrote:
>
>> Are we sure it's even "legal" to export Unicode variable names?
>Internally
>> we can kinda ignore POSIX as we choose, but the environment crosses
>those
>> boundaries.
>
>Independend of being 'legal' to me it seems dangerous!
>
>Comparing the 'working as written' example:
>
>~$ M='surprise; : ' MÄRCHEN=story sh -c 'echo $MÄRCHEN'
>story
>
>to running it with all the other shells I keep around
>(bash, dash, ash, sash - untested ksh and csh)
>you always get:
>
>..................................vvvv
>~$ M='surprise; : ' MÄRCHEN=story bash -c 'echo $MÄRCHEN'
>surprise; : ÄRCHEN
>
>Which gives interesting new ways to introduce security-sensitive
>changes into environments by letting a Program check the
>UTF8-named-Variable for its contents, but really inserting data
>by the broken-part-name, which might be passed unchecked!
>
>So PLEASE DO NOT EXPORT these !
>
>Stucki

I really do not see any problems here. If one has "surprise" in $M in an environment he runs typed scripts in then he already has much bigger problems.
-----BEGIN PGP SIGNATURE-----
Version: APG v1.1.1

iQJNBAEBCgA3BQJUlIbVMBwfMDI7PjIgHTg6PjswOSAQOzU6QTA9NEA+MjhHIDxr
cC1wYXZAeWFuZGV4LnJ1PgAKCRBu+P2/AXZZIuF9D/4oc9QkX4ziGW34IpiFzPmA
P4w5ZmbGFq8yV8IhYLX+SDukWSKP5j7K7CZgc6UU9Xftpr7RFbSXuRqyjTCWhzRM
mt6od3PeOI6+nEF+hizz+3WwqiHmrB/pagP7qed3gjX6t6y9qV7g+QCXdL7EPOQ/
uUKDoAjF0LPOc0JUtKXVJNZzE6YsCmVL/hwdeGG7pNQ7tOUeKEeS02XwNphAdUw4
5tuwE/UBRxtcPyCE3pVsV9vXa+1cyREuyY50uH/lMRGR8FuyjNmPslvRfDmzWkxw
x5OgxiyukBdxY4YLjiXuVLAVh/JqVmnZvMy2o6uqxESmv3tX8yOIjelFbwo6hZhz
L7RAdsXdw23OFBqxTrHxnSbImQuCn2yS2CrmQmBe3adilj84XIpqlpQCKy/LdXm7
LQyCGrI8gUwKLmpeqvaHrp3SbFfUZIbtMOaccQwPGBfH67JA0CUr+HZv3fJ/Iijm
F0LSsJTiQIgfeXXwk0nxHXUj/0yr5MEJUnVwFNY7C/tgOKRpDpwA5u2jgAvcYpUn
YHJddwyHryeghp2JpiECprUEd1nGRj4ijbGb4uolbs7CxVpR6z+IadEzsSg5bd2y
r499ADpGsuXM0U09unQUTMqsCaxW9y7VOeTqORSv/1jOG7O8vZIRIgLuyi+JYXsU
vMCYECRmzPKvIdYOsbQ7Gg==
=d7xB
-----END PGP SIGNATURE-----

Re: [BUG] Unicode variables can be exported and are exported metafied

[Peter Stephenson]

On Fri, 19 Dec 2014 19:17:37 +0100
"Christoph (Stucki) von Stuckrad" <stucki@mi.fu-berlin.de> wrote:
> On Thu, 18 Dec 2014, Bart Schaefer wrote:
> 
> > Are we sure it's even "legal" to export Unicode variable names?
> > Internally we can kinda ignore POSIX as we choose, but the
> > environment crosses those boundaries.
> 
> Independend of being 'legal' to me it seems dangerous!

Well, this seems to be controversial.  But it's not clear how useful such
variables are anyway.

This backs off yesterday's mess and ignores environment variable names
with characters with the top bit set.  We'll see if anyone trips over it.

pws

diff --git a/Src/params.c b/Src/params.c
index 1c51afd..b8e0c42 100644
--- a/Src/params.c
+++ b/Src/params.c
@@ -641,9 +641,17 @@ split_env_string(char *env, char **name, char **value)
     if (!env || !name || !value)
 	return 0;
 
-    tenv = metafy(env, strlen(env), META_HEAPDUP);
-    for (str = tenv; *str && *str != '='; str++)
-	;
+    tenv = strcpy(zhalloc(strlen(env) + 1), env);
+    for (str = tenv; *str && *str != '='; str++) {
+	if (STOUC(*str) >= 128) {
+	    /*
+	     * We'll ignore environment variables with names not
+	     * from the portable character set since we don't
+	     * know of a good reason to accept them.
+	     */
+	    return 0;
+	}
+    }
     if (str != tenv && *str == '=') {
 	*str = '\0';
 	*name = tenv;
@@ -4357,18 +4365,7 @@ arrfixenv(char *s, char **t)
 int
 zputenv(char *str)
 {
-    char *ptr;
     DPUTS(!str, "Attempt to put null string into environment.");
-    /*
-     * The environment uses NULL-terminated strings, so just
-     * unmetafy and ignore the length.
-     */
-    for (ptr = str; *ptr && *ptr != Meta; ptr++)
-	;
-    if (*ptr == Meta) {
-	str = dupstring(str);
-	unmetafy(str, NULL);
-    }
 #ifdef USE_SET_UNSET_ENV
     /*
      * If we are using unsetenv() to remove values from the
@@ -4377,11 +4374,21 @@ zputenv(char *str)
      * Unfortunately this is a slightly different interface
      * from what zputenv() assumes.
      */
+    char *ptr;
     int ret;
 
-    for (ptr = str; *ptr && *ptr != '='; ptr++)
+    for (ptr = str; *ptr && STOUC(*ptr) < 128 && *ptr != '='; ptr++)
 	;
-    if (*ptr) {
+    if (STOUC(*ptr) >= 128) {
+	/*
+	 * Environment variables not in the portable character
+	 * set are non-standard and we don't really know of
+	 * a use for them.
+	 *
+	 * We'll disable until someone complains.
+	 */
+	return 1;
+    } else if (*ptr) {
 	*ptr = '\0';
 	ret = setenv(str, ptr+1, 1);
 	*ptr = '=';

Re: [BUG] Unicode variables can be exported and are exported metafied

[ZyX]

20.12.2014, 00:54, "Peter Stephenson" <p.w.stephenson@ntlworld.com>:
> On Fri, 19 Dec 2014 19:17:37 +0100
> "Christoph (Stucki) von Stuckrad" <stucki@mi.fu-berlin.de> wrote:
>>  On Thu, 18 Dec 2014, Bart Schaefer wrote:
>>>  Are we sure it's even "legal" to export Unicode variable names?
>>>  Internally we can kinda ignore POSIX as we choose, but the
>>>  environment crosses those boundaries.
>>  Independend of being 'legal' to me it seems dangerous!
>
> Well, this seems to be controversial.  But it's not clear how useful such
> variables are anyway.
>
> This backs off yesterday's mess and ignores environment variable names
> with characters with the top bit set.  We'll see if anyone trips over it.

According to

> "Other characters may be permitted by an implementation; applications
> shall tolerate the presence of such names."

> … shall tolerate …

such environment variables can be used for testing software for standard conformance.

I think though that for such testing `env` is more likely to be used because zsh support for such environment variables is not only locale-dependent, but also restricted to whatever libc thinks is alphanumeric character:

 zyx  ~  env «»=10 python -c 'import os; print(os.environ["«»"])'
10
 zyx  ~  «»=10 python -c 'import os; print(os.environ["«»"])'
zsh: command not found: «»=10

(something weird like `$'\n'` also works as an “environment variable name” for `env`).

---

By the way, support status for shells found on my system:

code:

    абв=1 $SHELL -c 'echo $абв'

tcsh: Illegal variable name
ksh: echoes 1
mksh: echoes $абв
fish: echoes 1
busybox with ash: echoes $абв
busybox with hush (commit ad0d009e0c1968a14f17189264d3aa8008ea2e3b): echoes $абв
rcsh: syntax error near (decimal -48)
bash: echoes $абв
dash: echoes $абв
zsh: echoes 1

    абв=1 $SHELL /c 'echo %абв%'

wine cmd.exe: echoes ^[[?1h^[=1 followed by CRNL

Summary:

Syntax error: tcsh, rcsh
$абв: mksh, busybox ash, busybox hush, bash, dash
1: ksh, fish, zsh, wine cmd.exe

>
> pws
>
> diff --git a/Src/params.c b/Src/params.c
> index 1c51afd..b8e0c42 100644
> --- a/Src/params.c
> +++ b/Src/params.c
> @@ -641,9 +641,17 @@ split_env_string(char *env, char **name, char **value)
>      if (!env || !name || !value)
>          return 0;
>
> -    tenv = metafy(env, strlen(env), META_HEAPDUP);
> -    for (str = tenv; *str && *str != '='; str++)
> - ;
> +    tenv = strcpy(zhalloc(strlen(env) + 1), env);
> +    for (str = tenv; *str && *str != '='; str++) {
> + if (STOUC(*str) >= 128) {
> +    /*
> +     * We'll ignore environment variables with names not
> +     * from the portable character set since we don't
> +     * know of a good reason to accept them.
> +     */
> +    return 0;
> + }
> +    }
>      if (str != tenv && *str == '=') {
>          *str = '\0';
>          *name = tenv;
> @@ -4357,18 +4365,7 @@ arrfixenv(char *s, char **t)
>  int
>  zputenv(char *str)
>  {
> -    char *ptr;
>      DPUTS(!str, "Attempt to put null string into environment.");
> -    /*
> -     * The environment uses NULL-terminated strings, so just
> -     * unmetafy and ignore the length.
> -     */
> -    for (ptr = str; *ptr && *ptr != Meta; ptr++)
> - ;
> -    if (*ptr == Meta) {
> - str = dupstring(str);
> - unmetafy(str, NULL);
> -    }
>  #ifdef USE_SET_UNSET_ENV
>      /*
>       * If we are using unsetenv() to remove values from the
> @@ -4377,11 +4374,21 @@ zputenv(char *str)
>       * Unfortunately this is a slightly different interface
>       * from what zputenv() assumes.
>       */
> +    char *ptr;
>      int ret;
>
> -    for (ptr = str; *ptr && *ptr != '='; ptr++)
> +    for (ptr = str; *ptr && STOUC(*ptr) < 128 && *ptr != '='; ptr++)
>          ;
> -    if (*ptr) {
> +    if (STOUC(*ptr) >= 128) {
> + /*
> + * Environment variables not in the portable character
> + * set are non-standard and we don't really know of
> + * a use for them.
> + *
> + * We'll disable until someone complains.
> + */
> + return 1;
> +    } else if (*ptr) {
>          *ptr = '\0';
>          ret = setenv(str, ptr+1, 1);
>          *ptr = '=';

Re: [BUG] Unicode variables can be exported and are exported metafied

[Stephane Chazelas]

2014-12-20 01:44:10 +0300, ZyX:
[...]
[about making the shell syntax locale-dependant]
> bash: echoes $абв
[...]

You'd have gotten a different behaviour in a single-byte locale.

Related discussion:

http://thread.gmane.org/gmane.comp.shells.bash.bugs/22367

Personally, I think I'd rather shell variable names be limited
to ASCII [:alnum:]_.

Making the shell syntax locale dependant is a problem in scripts
(and we're already affected by that to some extent with
utilities) because there, it's the *author*'s locale that
matters, not the user's.

(Or else, you could do like rc and allow anything allowed in env
vars (rc allows any name as long as it's not empty and doesn't
contain `=`).

-- 
Stephane

Re: [BUG] Unicode variables can be exported and are exported metafied

[ZyX]

20.12.2014, 03:22, "Stephane Chazelas" <stephane.chazelas@gmail.com>:
> 2014-12-20 01:44:10 +0300, ZyX:
> [...]
> [about making the shell syntax locale-dependant]
>>  bash: echoes $абв
>
> [...]
>
> You'd have gotten a different behaviour in a single-byte locale.
>
> Related discussion:
>
> http://thread.gmane.org/gmane.comp.shells.bash.bugs/22367
>
> Personally, I think I'd rather shell variable names be limited
> to ASCII [:alnum:]_.
>
> Making the shell syntax locale dependant is a problem in scripts
> (and we're already affected by that to some extent with
> utilities) because there, it's the *author*'s locale that
> matters, not the user's.
>
> (Or else, you could do like rc and allow anything allowed in env
> vars (rc allows any name as long as it's not empty and doesn't
> contain `=`).

`абв=1 rcsh -c 'echo $абв'` emits “line 1: syntax error near (decimal -48)”. Is it the difference between “A reimplementation of the Plan 9 shell” (http://rc-shell.slackmatic.org/) version 1.7.2 that can be found in the main portage tree and the original Plan9 shell? Or maybe I should simply use different syntax (rcsh -c 'echo $PATH' works though)?

By the way, `env` allows empty name.

--

Found this syntax: `абв=1 rcsh -c 'echo $(абв)'` echoes 1. But `абв=1 rcsh -c 'env; абв=10; env; echo $(абв)'` shows that rcsh removes `абв` from the environment and places variable named `__d0__b0__d0__b1__d0__b2` there instead.

>
> --
> Stephane

Re: [BUG] Unicode variables can be exported and are exported metafied

[Stephane Chazelas]

2014-12-20 12:27:27 +0300, ZyX:
[...]
> > (Or else, you could do like rc and allow anything allowed in env
> > vars (rc allows any name as long as it's not empty and doesn't
> > contain `=`).
> 
> `абв=1 rcsh -c 'echo $абв'` emits “line 1: syntax error near
> (decimal -48)”. Is it the difference between “A
> reimplementation of the Plan 9 shell”
> (http://rc-shell.slackmatic.org/) version 1.7.2 that can be
> found in the main portage tree and the original Plan9 shell?
> Or maybe I should simply use different syntax (rcsh -c 'echo
> $PATH' works though)?
> 
> --
> 
> Found this syntax: `абв=1 rcsh -c 'echo $(абв)'` echoes 1. But
> `абв=1 rcsh -c 'env; абв=10; env; echo $(абв)'` shows that
> rcsh removes `абв` from the environment and places variable
> named `__d0__b0__d0__b1__d0__b2` there instead.
[...]

Sorry,

I should have tried. I suppose rc being from the 80s uses the
8th bit for parsing/tokening like other shells from that time as
well.

But the idea remains. In `rc`, you can do:

'my var
(with all sorts of characters)' = whatever
echo $'my var
(with all sorts of characters)'

And assuming it was extended to 8bit bytes, that means you can
have code that works regarless of the locale of the user since
all variable names are allowed. That also simplifies interaction
with env vars (though you still have problems with special
parameters like $1, $*...).

That would mean changing zsh syntax though and I don't think
it's really worth it.

> By the way, `env` allows empty name.

Yes, and you can pass env strings to execve() without `=` in
them.

-- 
Stephane