Memory for enviroment variables?

[Andreas D. Skjervold]

Hi
We have are developing av script that reads values from files and set these as enviroment variables to be used later in the script.

Have run into problems everytime the values that is put into the file is large.
When reducing the size of these values; everything runs smoothly.

Is there a parameter restricting the memory usage for enviroment variables?

Andreas

[Dan Hetzel]

Hi Andreas,

What do you mean by "large value".
Are you dealing with integers or with character strings?

Could you give us a sample working/non-working input?

Dan

[Andreas D. Skjervold]

The values are character strings that represents filesystem paths and filenames to datafiles that is to be read later.

Eks:
8 variables with approx 40 char length
and 10 short lenght variables (<10 char)
and:
IEF_SB_FILE=/<37 char path>/<49 char filename>

when the last one is shortened down, everything works fine.


Andreas

[RikTytgat]

Hi,

I have developped scripts that use environment variables of several thousands of characters and never encountered a problem.

Maybe the variable you have problems with contains strange characters (whitespace, ...). Try quoting the variable when you assign/use it.

Does the problem occur when assigning the variable, or when using it the first time?

Try adding 'set -xv' at the top of the script to see what is actually happening.

If you can't find the cause, add the output of the '-xv' output to this thread and I'll have a look at it.


Bye,
Rik

[Dan Hetzel]

Hi Andreas,

The size of the variables you're using shouldn't be a problem as far as the shell is concerned.
Have a look at your $PATH or $MANPATH variables and you'll see that an environment variable could be 'quite long'. ;-)

Could the code actually using the variables enforce a filename length limit? 'tar' does, for example.

Did you try echoing the variables from within your shell script? Are they printing OK?


Dan

[Andreas D. Skjervold]

Hi again!
I'm afraid I have been misleading you a bit here.
The case turns out to be like this:

The "script" is a C program and the variables is set using putenv() and this gives a return code 0 in both cases, so it seems OK.

A subsequent getenv() returns null when the variable is set:
IEF_SB_FILE=/bico/company/v2.3/test/bico/ops/input/NordTele8_000000000000000001_000000000000000029_001_n
and then the program fails.

when the variable is set:
IEF_SB_FILE=/bico/company/v2.3/test/bico/ops/input/Nor_000000000000000001_000000000000000029_001_n
getenv() returns the value and the programs works.

Hope this cleared things up a little.

Andreas

[RikTytgat]

Hi,

After using the getenv call, be sure to strcpy the result into a string because 'getenv() returns a pointer to static data which can be overwritten by subsequent calls'.

Also be sure to strcpy it to a variable that is long enough to hold the result. Otherwise, it will be truncated!!!

char strMyString[64] will be too small. Try char strMyLongString[1024] instead (this is too much, but try it for this test).


Hope this helps,
Rik

[Dan Hetzel]

Hi Andreas,

Yes, it's clearer !
The only problem is that there isn't any known bug about getenv() - not that I know, at least !

Is this the way you're calling getenv?

char *ief_sb_file;
ief_sb_file=getenv("IEF_SB_FILE");

Keep in mind that getenv() returns a pointer to data which could be overwritten.
If you want to reuse the data later on, you should copy it to a safe variable with strcpy() or sprintf().

Best regards,

Dan

[Andreas D. Skjervold]

Hi guys.
Unfortunately this problem can't be solved at this stage as the system test phase has to continue.
The chosen "solution" is to shorten the directory structures that holds the data and thus keeping the values for these variables at at low enough value.

When the system is in production we will return to the testsytem and continue on solving this permanently, and your input will be kept to use.
Perhaps a new thread will be posted at that time.

Thanks !
Andreas