Re^2: %ENV vs C's setenv

Env::C's explanation is that the glue code doesn't translate one to the other, but I'm not going to try to pick apart SWIG internals to find out why not.

Instead, my solution was to do this:

create a function on the C++ side that returned everything in the 'environ' list (defined by unistd.h) as a single string

add this function to the perl side:

sub sync_env_settings_from_c {

   my $env_string = CCode::getEnvSettings();

   # in addition to grabbing changed settings, we also need
   # to remove deleted settings, so we reset the %ENV
   # hash.  Note: do it *after* the call to getEnvSettings
   # or else $env_string will be empty.
   undef %ENV;

   foreach my $block (split($SEPARATOR, $env_string)) {

      next if (!$block);  # first one's empty because I'm lazy

      # each one looks like "key=value":
      my ($key, $value) = split(m{=}, $block, 2);
      $ENV{$key} = $value;
   }

   return;
}

call that function after I know %ENV has been messed with.

I'm sure the efficiency is questionable, but at least it seems to be correct.

Comment on Re^2: %ENV vs C's setenv

Replies are listed 'Best First'.
Re^3: %ENV vs C's setenv by afoken (Chancellor) on Oct 31, 2009 at 08:31 UTC
Environment variable values may contain every character except ASCII NUL (`"\0"`), because they are defined as ASCII NUL terminated C strings. I wonder how you define `$SEPARATOR` when the code on the C/C++ side returns a single string also terminated with ASCII NUL. The only clean way to stuff the entire environment into a single C/C++ string is to use some kind of encoding, not a simple join. You need either a length information before each part of the environment, so that you do not need the trailing ASCII NUL after each key-value-pair; or you replace the trailing ASCII NUL after the pairs with an escape sequence (e.g. the characters "\" and "0"), and replace every occurance of the escape character in the key or value with a second escape sequence (e.g. by using the escape character twice). Of course, the Perl code has to read the length information and use `substr` accordingly resp. undo those escaping. Perl uses "counted" strings that can contain ASCII NUL, so unescaping simply means replacing \\ with \ and \0 with ASCII NUL at the same time, followed by splitting at ASCII NUL. Alexander -- Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: %ENV vs C's setenv
by afoken (Chancellor) on Oct 31, 2009 at 08:31 UTC

Environment variable values may contain every character except ASCII NUL ("\0"), because they are defined as ASCII NUL terminated C strings. I wonder how you define $SEPARATOR when the code on the C/C++ side returns a single string also terminated with ASCII NUL.

The only clean way to stuff the entire environment into a single C/C++ string is to use some kind of encoding, not a simple join. You need either a length information before each part of the environment, so that you do not need the trailing ASCII NUL after each key-value-pair; or you replace the trailing ASCII NUL after the pairs with an escape sequence (e.g. the characters "\" and "0"), and replace every occurance of the escape character in the key or value with a second escape sequence (e.g. by using the escape character twice).

Of course, the Perl code has to read the length information and use substr accordingly resp. undo those escaping. Perl uses "counted" strings that can contain ASCII NUL, so unescaping simply means replacing \\ with \ and \0 with ASCII NUL at the same time, followed by splitting at ASCII NUL.

Alexander

--
Today I will gladly share my knowledge and experience, for there are no sweeter words than "I told you so". ;-)

[reply]
[d/l]
[select]