Many thanks to Dr Thomas Blinn
Original question with supplement elicited by Dr Thomas Blinn.
I've seen questions about this in the archives but haven't seen an answer
either in the archive or documentation. Anyone?
Apologies for the lack of clarity. Yes, this messages came from the shell
(ksh) as:
cap005 > env | wc -l
too many values in environment
421
The vast majority of the env vars are set by our development team. They are
migrating an application (RDMS) from
VMS to Tru64 and were looking for an alternative to VMS "logicals". Most of
these variables simply provide
a specific application path short cut. The reason being that the VMS code
used logicals of the same name
as these env vars and it has reduced the amount of work required in the
migration.
So, yes, the question is, what is the impact? How does this data store
operate FIFO? Stack? Are we going
to loose the ability to reference certain vars or does the problem only
arise when more than a set number are
referenced in one hit? What is the limit? Can it be increased?
Can you point me to an info source, I have looked but can find nothing in
the documentation. TIA.
Reply from Dr Thomas Blinn
I wonder if "printenv" elicits the same error message; for the case
you
cite it should do the same thing, that is, display the current set
of
environment variables and their values to standard output so you can
pipe it into "wc -l". Not that this solves your underlying problem,
which is too many defined variables.
It didn't - LS
cap005 > printenv | wc -l
421
I can't tell whether the message is coming out of the shell (ksh) or
out
of the "env" utility. But if I do this command:
strings `which env` | grep "too many"
it finds the string "too many values in environment" so I believe
that
the message is coming out of "env", not out of the shell.
It was :-)
cap005 > strings `which env` | grep "too many"
too many values in environment
Being that as it may, there are MANY ways to work around the limit
for
a specific application. For instance, if what the application needs
is file system paths, then pick some directory location and populate
it with symlinks where each symlink is named with the path to the
file
that the application needs, e.g.,
mkdir -p /user/app/app-paths
cd /user/app/app-paths
ln -s /user/app/datafiles/file1 FILE1
and so on, where the value of the symlink is the path to the file.
In fact, you can put other "logical names" in symlinks this way; in
general, you can put almost ANYTHING as the value of a symlink, even
things with embedded slashes; they can either be the path to an
object
in the file system, or an arbitrary string value. The
interpretation
depends on whether you use them to try to access an object in the
file
system as part of the path to the object (e.g., by opening the
symlink
as if it were a file), or whether you use the appropriate library
call
to retrieve the string value of the symlink (just as "ls -l" uses
when
it displays the value of the symlink).
For documentation on the limits on environment variables and
arguments
passed from one program to another (which is what "env" is designed
to
be used for, to explicitly control what arguments and environment is
passed to some program), see the "exec" reference page. It tells
you
that the combined size of the environment pairs (name and value) and
the arguments may not exceed a system limit called ARG_MAX:
[E2BIG] The number of bytes used by the new process image's
argument list
and environment list is greater than ARG_MAX bytes.
This is in the "errors" section -- there is an explicit error return
for the case where you try to exec a program and the combined size
of
the environment list and argument list is greater than ARG_MAX
bytes.
This is a POSIX compliance issue -- it can NOT be increased, it's a
system limit, if it were increased that would violate POSIX
standards
compliance and possibly break applications throughout the system.
OpenVMS doesn't have to be POSIX compliant, and OpenVMS logical
names
are not the exact equivalent of the UNIX process environment
variables.
Hope this helps. I believe that for what you are trying to do,
using
the symlink trick should be the best approach. There are no limits
of
practical value to the number of symlinks in a directory, and you
can
in fact just open the symlink as a file if that's what you really
want,
just like in OpenVMS.
Tom
Kind regards
Lawrie Smith
Capita Technical Services
West Malling
email: lawrie.smith_at_capita.co.uk
Tel: 01732 877266
www.capita.co.uk
Capita Group LTD Tel: +44 (0)8705-234567
********************** N O T I C E ********************************************
The information in this message is confidential. It is intended solely for the addressee. Access to this message by anyone else is unauthorised. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it is prohibited and may be unlawful.
We do not accept legal responsibility for the contents of this message and whilst any attachments to this message may have been checked for viruses, you should rely on your own virus checker and procedures.
If you contact us by e-mail, we will store your name and address to facilitate communications.
Any statements contained in this message are those of the individual and not the organisation.
*****************************************************************************
Received on Fri Dec 28 2001 - 14:48:37 NZDT