leading '=' in enviroment variable truncated

leading '=' in enviroment variable truncated

[Jacob Lowe]

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

Hey all,

First off thanks for making/maintaining ZSH. Its a awesome project, and has
been my default shell for 3 plus years.

I recently ran into a unique thing that ZSH does that cause a bug that was
filed on a project I help maintain.

https://github.com/motdotla/dotenv/issues/140

It is a javascript module that loads environment variables into the process
for the node program to use. I noticed the module was parsing the the env
ok and the bug only occurred while preloading the script. I tried to load
in the env via the command line straight into the node program as well.

TEST='=FOO' node -e 'console.log(process.env.TEST)'


This spits out "FOO" with no leading "=".

So I filed and issue on nodejs repo thinking this had to do with the way it
was handling the environment variables.

https://github.com/nodejs/node/issues/6627

>From the feedback in the ticket, it seems this is happening in ZSH only and
when logging into bash the command works as expected. I also tried
something very similar in ruby and got the same result.

TEST='=test' ruby -e 'puts ENV["TEST"]'


This also spits out "FOO" with no leading "=".

Is this intended behavior? and thanks again.

Re: leading '=' in enviroment variable truncated

[Jacob Lowe]

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

Sorry realized I sent this out missing a key piece of info. My current
version of *zsh is** 5.0.8 (x86_64-apple-darwin15.0)*. Also the last
example I posted spits out "test" not "FOO".

On Sat, May 7, 2016 at 9:21 AM Jacob Lowe <jacoblowe2.0@gmail.com> wrote:

> Hey all,
>
> First off thanks for making/maintaining ZSH. Its a awesome project, and
> has been my default shell for 3 plus years.
>
> I recently ran into a unique thing that ZSH does that cause a bug that was
> filed on a project I help maintain.
>
> https://github.com/motdotla/dotenv/issues/140
>
> It is a javascript module that loads environment variables into the
> process for the node program to use. I noticed the module was parsing the
> the env ok and the bug only occurred while preloading the script. I tried
> to load in the env via the command line straight into the node program as
> well.
>
> TEST='=FOO' node -e 'console.log(process.env.TEST)'
>
>
> This spits out "FOO" with no leading "=".
>
> So I filed and issue on nodejs repo thinking this had to do with the way
> it was handling the environment variables.
>
> https://github.com/nodejs/node/issues/6627
>
> From the feedback in the ticket, it seems this is happening in ZSH only
> and when logging into bash the command works as expected. I also tried
> something very similar in ruby and got the same result.
>
> TEST='=test' ruby -e 'puts ENV["TEST"]'
>
>
> This also spits out "FOO" with no leading "=".
>
> Is this intended behavior? and thanks again.
>

Re: leading '=' in enviroment variable truncated

[Bart Schaefer]

On May 7,  4:21pm, Jacob Lowe wrote:
}
} https://github.com/motdotla/dotenv/issues/140
} 
} TEST='=FOO' node -e 'console.log(process.env.TEST)'
} 
} This spits out "FOO" with no leading "=".

As mentioned in the dotenv issue, this happens only on OSX.  I've just
confirmed that it's a problem either with the library implementations
of setenv() / unsetenv(), or with zsh's use of them.  If I comment out
HAVE_SETENV / HAVE_UNSETENV from config.h and rebuild zsh, I am no
longer able to reproduce the problem.

Re: leading '=' in enviroment variable truncated

[Peter Stephenson]

On Sun, 8 May 2016 10:59:49 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:

> On May 7,  4:21pm, Jacob Lowe wrote:
> }
> } https://github.com/motdotla/dotenv/issues/140
> } 
> } TEST='=FOO' node -e 'console.log(process.env.TEST)'
> } 
> } This spits out "FOO" with no leading "=".
> 
> As mentioned in the dotenv issue, this happens only on OSX.  I've just
> confirmed that it's a problem either with the library implementations
> of setenv() / unsetenv(), or with zsh's use of them.  If I comment out
> HAVE_SETENV / HAVE_UNSETENV from config.h and rebuild zsh, I am no
> longer able to reproduce the problem.

This appears to be a feature.

https://developer.apple.com/library/ios/documentation/System/Conceptual/ManPages_iPhoneOS/man3/setenv.3.html

  These functions set, unset and fetch environment variables from the host
  environment list.  For compatibility with differing environment
  conven-tions, conventions, the given arguments name and value may be
  appended and prepended, respectively, with an equal sign ``=''.

Very useful, if I may say so.

pws

Re: leading '=' in enviroment variable truncated

[Bart Schaefer]

On May 8,  8:12pm, Peter Stephenson wrote:
} Subject: Re: leading '=' in enviroment variable truncated
}
} On Sun, 8 May 2016 10:59:49 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} 
} > As mentioned in the dotenv issue, this happens only on OSX.  I've just
} > confirmed that it's a problem either with the library implementations
} > of setenv() / unsetenv(), or with zsh's use of them.
} 
}   These functions set, unset and fetch environment variables from the host
}   environment list.  For compatibility with differing environment
}   conven-tions, conventions, the given arguments name and value may be
}   appended and prepended, respectively, with an equal sign ``=''.
} 
} Very useful, if I may say so.

Astounding.

The Open Group spec for "setenv" explicitly prohibits "=" in the name,
and says nothing about the value.  The source code for setenv.c on
opensource.apple.com does nothing special with name or value.

How about this?


diff --git a/Src/zsh_system.h b/Src/zsh_system.h
index 811340d..17c4c64 100644
--- a/Src/zsh_system.h
+++ b/Src/zsh_system.h
@@ -728,7 +728,7 @@ extern char **environ;
  * We always need setenv and unsetenv in pairs, because
  * we don't know how to do memory management on the values set.
  */
-#if defined(HAVE_SETENV) && defined(HAVE_UNSETENV)
+#if defined(HAVE_SETENV) && defined(HAVE_UNSETENV) && !defined(__APPLE__)
 # define USE_SET_UNSET_ENV
 #endif
 

Re: leading '=' in enviroment variable truncated

[Peter Stephenson]

[apologies for duplicates, I think I sent the last reply to Bart.]

On Sun, 8 May 2016 13:24:06 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> Astounding.
> 
> The Open Group spec for "setenv" explicitly prohibits "=" in the name,
> and says nothing about the value.  The source code for setenv.c on
> opensource.apple.com does nothing special with name or value.
> 
> How about this?

This tries to be smarter, but I don't know if it's worth it... it's
untested on the target system.

diff --git a/Src/zsh_system.h b/Src/zsh_system.h
index 811340d..4f3330b 100644
--- a/Src/zsh_system.h
+++ b/Src/zsh_system.h
@@ -729,7 +729,9 @@ extern char **environ;
  * we don't know how to do memory management on the values set.
  */
 #if defined(HAVE_SETENV) && defined(HAVE_UNSETENV)
-# define USE_SET_UNSET_ENV
+# ifndef SETENV_MANGLES_EQUALS
+#  define USE_SET_UNSET_ENV
+# endif
 #endif
 
 
diff --git a/configure.ac b/configure.ac
index 9ce3a45..b5be67f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -3031,6 +3031,27 @@ if test "x$dynamic" = xyes; then
   fi
 fi
 
+AH_TEMPLATE([SETENV_MANGLES_EQUALS],
+[Define to 1 if setenv removes a leading =])
+if test x$ac_cv_func_setsnv = xyes; then
+AC_CACHE_CHECK([if setenv removes a leading =],
+ zsh_cv_c_setenv_mangles_equals,
+ [AC_TRY_RUN([
+#include <string.h>
+   main()
+   {
+      setenv("NAME", "=VALUE", 1);
+      return strcmp((char *)getenv("NAME"), "=VALUE");
+   }
+   ],
+   zsh_cv_c_setenv_mangles_equals=yes,
+   zsh_cv_c_setenv_mangles_equals=no,
+   zsh_cv_c_setenv_mangles_equals=no)])
+   if test x$zsh_cv_c_setenv_mangles_equals = xyes; then
+     AC_DEFINE(SETENV_MANGLES_EQUALS)
+   fi
+fi
+
 if test "x$dynamic" = xyes; then
   zsh_SYS_DYNAMIC_CLASH
   zsh_SYS_DYNAMIC_GLOBAL

Re: leading '=' in enviroment variable truncated

[Bart Schaefer]

On May 8,  9:28pm, Peter Stephenson wrote:
} 
} On Sun, 8 May 2016 13:24:06 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > Astounding.
} > 
} > The Open Group spec for "setenv" explicitly prohibits "=" in the name,
} > and says nothing about the value.  The source code for setenv.c on
} > opensource.apple.com does nothing special with name or value.
} > 
} > How about this?
} 
} This tries to be smarter, but I don't know if it's worth it... it's
} untested on the target system.

If we're going to go so far as to have a configure test, shouldn't we
include a check that setenv is in fact defined before attempting to
run a test that uses it?

Re: leading '=' in enviroment variable truncated

[Bart Schaefer]

On Sun, May 8, 2016 at 2:58 PM, Bart Schaefer <schaefer@brasslantern.com> wrote:
>
> If we're going to go so far as to have a configure test, shouldn't we
> include a check that setenv is in fact defined before attempting to
> run a test that uses it?

Never mind.  You included the test but spelled "setenv" wrong, and I
missed that you'd tested anything at all.

However, even if I change the "setsnv" to "setenv" the test still gets
the wrong results.

conftest.c:259:4: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
   main()
   ^~~~
conftest.c:261:7: warning: implicit declaration of function 'setenv'
is invalid in C99 [-Wimplicit-function-declaration]
      setenv("NAME", "=VALUE", 1);
      ^
conftest.c:262:29: warning: implicit declaration of function 'getenv'
is invalid in C99 [-Wimplicit-function-declaration]
      return strcmp((char *)getenv("NAME"), "=VALUE");
                            ^
conftest.c:262:21: warning: cast to 'char *' from smaller integer type
'int' [-Wint-to-pointer-cast]
      return strcmp((char *)getenv("NAME"), "=VALUE");
                    ^
4 warnings generated.
configure:12601: $? = 0
configure:12601: ./conftest
./configure: line 1719: 90473 Segmentation fault: 11  (core dumped)
./conftest$ac_exeext

Re: leading '=' in enviroment variable truncated

[Bart Schaefer]

On May 7,  4:21pm, Jacob Lowe wrote:
}
} From the feedback in the ticket, it seems this is happening in ZSH only and
} when logging into bash the command works as expected. I also tried
} something very similar in ruby and got the same result.
} 
} TEST='=test' ruby -e 'puts ENV["TEST"]'

Peter's discovery that this is a documented feature of iOS / OSX "setenv"
points to the obvious workaround:

TEST='==test' ruby -e 'puts ENV["TEST"]'


-- 
Barton E. Schaefer

Re: leading '=' in enviroment variable truncated

[Jacob Lowe]

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

Thank you Barton for help and information. I think there is simple
workarounds for this that we can document in dotenv, and luckily this is
just osx issue.

On Sun, May 8, 2016, 7:14 PM Bart Schaefer <schaefer@brasslantern.com>
wrote:

> On May 7,  4:21pm, Jacob Lowe wrote:
> }
> } From the feedback in the ticket, it seems this is happening in ZSH only
> and
> } when logging into bash the command works as expected. I also tried
> } something very similar in ruby and got the same result.
> }
> } TEST='=test' ruby -e 'puts ENV["TEST"]'
>
> Peter's discovery that this is a documented feature of iOS / OSX "setenv"
> points to the obvious workaround:
>
> TEST='==test' ruby -e 'puts ENV["TEST"]'
>
>
> --
> Barton E. Schaefer
>

Re: leading '=' in enviroment variable truncated

[Peter Stephenson]

On Sun, 08 May 2016 15:16:46 -0700
Bart Schaefer <schaefer@brasslantern.com> wrote:
> However, even if I change the "setsnv" to "setenv" the test still gets
> the wrong results.

Mostly that's headers, but it doesn't look it's trivial to fix in
general without access to the system.  You could try #include <stdlib.h>
if you felt like it, but probably not worth it.

pws

Re: leading '=' in enviroment variable truncated

[Bart Schaefer]

On May 9, 10:11am, Peter Stephenson wrote:
}
} On Sun, 08 May 2016 15:16:46 -0700
} Bart Schaefer <schaefer@brasslantern.com> wrote:
} > However, even if I change the "setsnv" to "setenv" the test still gets
} > the wrong results.
} 
} Mostly that's headers, but it doesn't look it's trivial to fix in
} general without access to the system.  You could try #include <stdlib.h>
} if you felt like it, but probably not worth it.

If anybody else wants to take a stab at this, please do, otherwise I'm
going to push the simpler patch with !defined(__APPLE__).