Re: New "base document" available


"Richard" <riplin@xxxxxxxxxxxx> wrote in message
news:1175551275.527091.185090@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
On Apr 2, 1:51 pm, "Pete Dashwood"
<dashw...@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote:

I understand what you are saying and thanks for the example.

It seems to me you are second guessing what the implementor will do.
While
most Unix compiler writers will probably use C, there is no guarantee
that
that is so, and neither should we assume that because a C header file
doesn't provide support for pointers to the environment, it is therefore
impossible to implement. All that proves is that it cannot be done
DIRECTLY
in C, on that platform. There are many ways to skin a cat and compiler
writers are notoriously imaginative. Although I don't claim expertise in
Unix, I did some quick searching and found the following:

"The PRINTENV command is used to display environment variable
definitions.
If it is given with no arguments then all environmental variables wil be
displayed. You can also give the command with a single argument, which is
the name of an environmental variable without a dollar sign. Then the
definition of that variable is displayed. "

As far as I can establish, PRINTENV is available across ALL UNIX
platforms

Environment variables are a feature of the shell, not of the OS. The
behaviour of these and the means of setting and reading them may vary
between different shells (ge sh, bash, csh, zsh).

It happens that 'printenv' (note lower case) is an external program
that will list the environment variables and 'set' is built into bash.

These do not produce exactly the same results, in particular bash's
set will produce more information about the environment.


Thanks for that, Richard.

We are only interested in the actual values of the variables (and
their names); we don't HAVE to access the EVs directly.

We are actually only interested in what the user is attempting to get
the program to do. This may be by having the user fill in a dialog,
or it may be from having something set in an EV or from a command
line.

That was Rick's original position, I think.

I believe the action of GETTING parameters (from wherever, as you suggest)
should be separate from the action of USING parameters.

The point is that my programs needs to know what the user wants for
some particular setting. I want to use some name to call that setting
by but I neither know nor care whther it is in the environment, the
registry, on the command line or has to gotten via a dialog or from a
configuration file.

I want my application to 'call getparam using thisname uservalue'.
The getparam program should do whatever is necessary on the particular
OS following some (configurable?) priority.

For examply it could look at the command line for 'thisname=value'
then a configuration file, and then the environment or the registry.
I don't want a list of various values to sift through, that may be the
job of the 'black box' getparam.


Yes, I see your point.

Certainly some mechanism is required but it need not be part of the
standard because I can write a different 'getparam' for each OS, and
one for CGI and one for web services.


I think the idea is to avoid having to do that. If there is a COBOL
facility, it could be invoked from COBOL running anywhere... Web Service,
CGI, or desktop.

In each case the priority and method of determining the values may be
quite different.

Hmmm... it could, but that is probably undesirable... :-)



The bottom line is that if EVs can be accessed in ANY way, then the
solution
I suggested can be implemented by a compiler provider.

However, it is not the job of J4 to decide HOW COBOL facilities are
implemented. Reviews of proposals by vendors will establish if something
CANNOT be done, and that just means it can't be done in a certain
environment.

I don't want J4 to be involved at all in this particular issue.

Amen... I don't want them involved in ANY issue :-)

Unfortunately, it is impossible to get a facility added to COBOL unless they
are... :-)


1. We need to generate code (or a solution) to provide access to EVs at
run
time.

But it isn't the EV's that are required, it is the value of the
parameter that the user wants to specify. This may be in EVs on one
system, a registry in another, or a configuration file in others.


I agree that is a valid consideration. It would be MUCH harder for
implementors, who would have to know what the .ini file name is, which
Registry values are affected, and all of this complicates what has to be
passed to the facility. (unless they are separately configurable, and that
means more work... it might be possible to have some defaults, like
progname.ini... )

I see your point about requesting what you want, but this becomes tedious
when there are a number of things you want, in different "locations" around
the environment. It means multiple calls and is very much what we currently
have...

That's why I suggested two sets that hold everything as name/value pairs. I
admit, this doesn't cover .ini and registry entries; maybe it should, for
systems that have those facilities, but then we are getting into something
that is not so simple for implementors.

Pete.



.

Relevant Pages

  • Re: ENV variable NOT recognized ! Reboot really necessary ????
    ... this will only change the environment block for new processes created *after* the change. ... Existing processes will keep on using their current environment block, which is the same as it was before you made the change. ... But an application needs to be written to explicitly do this; there's no mechanism in the operating system to universally update environment variables on the fly for running processes. ... For example, say you had a command prompt open, and you run a SET command to display the current variables. ...
    (microsoft.public.windowsxp.help_and_support)
  • [REVS] Using Environment for Returning Into Lib C
    ... This article explains how to use the environment variables to successfully ... The environment will consequently be used to store it. ... It is easy to write a simple program to put the command directly into the ... declare -x COLORTERM="" ...
    (Securiteam)
  • Re: SSH environment variable passing
    ... has to be a capability of both the client and the server. ... to support only a couple of specific environment variables. ... I have been told that allowing unlimited environment variables to be set ... A parallel situation exists in telnet. ...
    (SSH)
  • Re: Multiple interpreters retaining huge amounts of memory
    ... environment variable separation for changes made unique to a sub ... you can make changes to environment variables ... extension module in different sub interpreters, ...
    (comp.lang.python)
  • Re: [Info-Ingres] getenv, NMgtAtt and OME
    ... that I can just toggle with an environment variable. ... It's all about context - your OME function is being called from the ... variable - just like how normal Ingres can look for user ... environment variables such as II_DATE_FORMAT etc... ...
    (comp.databases.ingres)