Environment Variables

Environment Variables

[John M. Greer]

Does anyone know how to access environment variables from Ada code?  
Specifically, Unix/Linux CGI environment variables from the latest 
version of GNAT.  (Yes, I'm writing CGI in Ada.  Please don't write me 
and remind me that every newline requires a New_Line, as that seems to be 
a popular response to this question locally :-)

On an unrelated note (and this is a classroom question, but it's not 
doing my homework for me), my professor commented that using WITH, though 
common in Ada-83, is frowned upon by the industry in Ada 95.  Any 
specific reason for that?  (I'm assuming name collisions with types that 
look similar to the compiler, but I've only been in this class for about 
a month, so . . .)

Thanks for the assist . . .

John Greer
(who vastly prefers Put to Ada.Text_IO.Put)

Re: Environment Variables

[Matthew Heaney]

In article <5c1nf9$d3q@ultranews.duc.auburn.edu>, greerjo@mail.auburn.edu
(John M. Greer) wrote:

>Does anyone know how to access environment variables from Ada code?  
>Specifically, Unix/Linux CGI environment variables from the latest 
>version of GNAT.

Is POSIX supported on your machine.  Did your compiler come with POSIX
bindings?  If so, then environment variables are available via
POSIX_Process_Environment.

>On an unrelated note (and this is a classroom question, but it's not 
>doing my homework for me), my professor commented that using WITH, though 
>common in Ada-83, is frowned upon by the industry in Ada 95.  Any 
>specific reason for that?  (I'm assuming name collisions with types that 
>look similar to the compiler, but I've only been in this class for about 
>a month, so . . .)


I'm not sure what you mean here.  You *must* with other library units to
use the resources they provide.  (Except of course for package Standard.)

When there's a name collision, Ada forces you the programmer to name the
unit containing the declaration so as to resolve the ambiguity.  Ada never
makes a "default choice."  (Though that's a bit of a lie in the case of
root types.)

Perhaps he was refering to the "use" clause?  

Yes, this is a contentious issue in the Ada community.  It's been my
experience, though, that the use clause it either used too often, or not
enough.  There are a few techniques one can use that makes its use less
pernicious.

Your professor may have been refering to Ada 95's "use type" clause.  This
obviates one reason why programmers use use, which was to gain direct
visibility to the operators of the type.

For example, if I have

package P is
  
   type T is new Integer;

end;


with P;
procedure Proc is
   O : P.T;
begin
   O := O + 1;

The compiler complains because the "+" operator for the type isn't visible. 
So you had a few choices.

with P; use P;
procedure Proc is
   O : T;
begin
   O := O + 1;

This is probably what your professor was refering to.  If I'm in a scope
with a lot of variables and a lot of with's, then suddenly I don't know
where any of my types came from.  A real maintenance nightmare, committed
by unthoughtful programmers.

Shops often ban the use of use for that reason, but it's a really naive
solution to the problem.  So you have horrible code like this

with P;
procedure Proc is
   O : P.T;
begin
   O := P."+" (O, 1);

Ouch!  A better solution (still Ada 83), is to use a renames:

with P;
procedure Proc is
   O : P.T;
   function "+" (L, R : P.T) return P.T renames P."+";
begin 
   O := O + 1;

At least now, everything is documented.

But if you're using a lot of operators, then renames can be a bit of a
chore.  I like to localize the use clause, so at least I identify where the
type came from.

with P;
procedure Proc is
   O : P.T;
   use P;
begin
   O := O + 1;

The (primitive) operations for a type are declared in the same package as
the type declaration, so if I identify the package containing the type,
then I've implicitly said where the operations (and operators) came from
too.

In Ada 95, there's a use type clause that allows me to get direct
visibility to the operators only:

with P; use type P.T;
procedure Proc is 
   O : P.T;
begin
   O := O + 1;

Which seems to solve the problem to everyone's satisfaction.

The rules for use are as follows.  To resolve the reference to the
operation, the compiler looks in successively outer scopes for an explicit
operation declaration or rename, until it hits the unit containing the type
declaration (where presumably the operation is primitive).  The units named
in a use clause are considered only *after* this has been done.  

Localizing a use clause only limits the scope to which the use clause
applies; it doesn't give the operations in the named unit any kind of
"priority" when resolving the reference.  The operations of the unit named
in the use clause are still considered only after not finding explicit
declarations or renames, no matter how "near" it appears to the invokation
of the operation.

Few Ada programmers really understand the rules for use, which is partly
why it's use is so controversial.

Feel free to email me privately if you have any Ada questions. (Your
professor can email too, if he wants the opinion of an "industry
representative.") 

matt

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Environment Variables

[Robert Dewar]

i">Does anyone know how to access environment variables from Ada code?
>Specifically, Unix/Linux CGI environment variables from the latest
>version of GNAT.
"

look at gnat.os_lib.getenv

while you are at it, check the specs of gnat.xxx units in general, there
is some helpful stuff here.

Re: Environment Variables

[Mike Bishop]

John M. Greer wrote:
> 
> Does anyone know how to access environment variables from Ada code?
> Specifically, Unix/Linux CGI environment variables from the latest
> version of GNAT.  (Yes, I'm writing CGI in Ada.  Please don't write me
> and remind me that every newline requires a New_Line, as that seems to be
> a popular response to this question locally :-)

Have you looked at the Ada-to-CGI bindings, which can be found at
http://wuarchive.wustl.edu/languages/ada/swcomps/cgi/cgi.html? That may
help you out.
> 
> On an unrelated note (and this is a classroom question, but it's not
> doing my homework for me), my professor commented that using WITH, though
> common in Ada-83, is frowned upon by the industry in Ada 95.  Any
> specific reason for that?  (I'm assuming name collisions with types that
> look similar to the compiler, but I've only been in this class for about
> a month, so . . .)

Using "with" is frowned upon in Ada 95? Is he referring to using "with"
for something like Ada.Text_IO, for example? Maybe he's talking about
not using "use". Having a lot of "use"s can clutter up a name space.
Even if the compiler can resolve all of the types, the differences
between similar types in different packages may not be obvious to a
maintainer.

-- 
Mike Bishop (mikeb@wizard.unitedspacealliance.com)
United Space Alliance
---------------------
The comments and opinions expressed are my own and 
do not represent the views of United Space Alliance.

Re: Environment Variables

[Doug Smith]

In article <5c1nf9$d3q@ultranews.duc.auburn.edu>, greerjo@mail.auburn.edu (John M. Greer) wrote:

> Does anyone know how to access environment variables from Ada code?  
> Specifically, Unix/Linux CGI environment variables from the latest 
> version of GNAT.  (Yes, I'm writing CGI in Ada.  Please don't write me 
> and remind me that every newline requires a New_Line, as that seems to be 
> a popular response to this question locally :-)
[snip]
> 
> John Greer
> (who vastly prefers Put to Ada.Text_IO.Put)

Check out the latest CGI binding used by WebAda at:
 <http://sw-eng.falls-church.va.us/AdaIC/compilers/webada/source/cgi/>

Doug Smith
<mailto:dsmith@clark.net>

Frowining upon with clauses (was:Re: Environment Variables)

[Norman H. Cohen]

John M. Greer wrote:

> On an unrelated note (and this is a classroom question, but it's not
> doing my homework for me), my professor commented that using WITH, though
> common in Ada-83, is frowned upon by the industry in Ada 95.  Any
> specific reason for that? 

"Frowned upon" seems a bit overgeneral.  Certainly there are packages
that are most appropriately written as child packages in Ada 95, and in
Ada 83 such packages would have had to been written as independent
packages gain access to the facilities of the "parent package" through a
with clause.
 
-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Frowining upon with clauses (was:Re: Environment Variables)

[Robert Dewar]

Norman says, answering John

<<> On an unrelated note (and this is a classroom question, but it's not
> doing my homework for me), my professor commented that using WITH, though
> common in Ada-83, is frowned upon by the industry in Ada 95.  Any
> specific reason for that?

"Frowned upon" seems a bit overgeneral.  Certainly there are packages
that are most appropriately written as child packages in Ada 95, and in
Ada 83 such packages would have had to been written as independent
packages gain access to the facilities of the "parent package" through a
with clause.
>>


Surely John is confusing WITH with USE, I cannot imagine anyone who knows
anything at all about Ada saying tha the use of WITH is frowned upon, 
whereas it is quite true that many Ada programmers prefer to avoid USE (a
subject on which we do *not* need another thread I think!)

Re: Environment Variables

[David Emery]

Of course, if you want to be POSIX-compliant, you should use
POSIX_Process_Environment....

					dave
-- 
Note: if email to me bounces, use 'emery@grebyn.com'

Environment variables

[Christopher J Arnold]

Ok, some one please help me.

All I want to do is to be able to read the value of environment 
variables, such as PATH for example.  I've looked around at FAQ's and the 
adahome reference pages, but I haven't found anything.

Thanks in advance.

Chris Arnold,
carnold@runet.edu

Re: Environment variables

[David Taylor]

Christopher J Arnold wrote:
> 
> Ok, some one please help me.
> 
> All I want to do is to be able to read the value of environment
> variables, such as PATH for example.  I've looked around at FAQ's and the
> adahome reference pages, but I haven't found anything.
> 
> Thanks in advance.
> 
> Chris Arnold,
> carnold@runet.edu
try printenv, or for PATH, echo $PATH

dt

Re: Environment variables

[David Emery]

>All I want to do is to be able to read the value of environment 
>variables, such as PATH for example.  I've looked around at FAQ's and the 
>adahome reference pages, but I haven't found anything.

Of course, this is not a language issue, but an operating system
issue.  POSIX/Ada has services to do this, or you can 'roll your own'
via interface to C.  (do "man getenv")

				dave
--
<.sig is away on vacation>

Re: Environment variables

[Robert Dewar]

">All I want to do is to be able to read the value of environment
>variables, such as PATH for example.  I've looked around at FAQ's and the
>adahome reference pages, but I haven't found anything."

If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in file
g-os_lib.ads (there are lots of useful routines in this package :-)

Re: Environment variables

[Laurent Guerby]

Robert> If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in
Robert> file g-os_lib.ads (there are lots of useful routines in this
Robert> package :-)

   There's also Ada.Command_Line.Environment.

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Environment variables

[Keith Thompson]

In <ws94tjbhlg1.fsf@schonberg.cs.nyu.edu> guerby@gnat.com (Laurent Guerby) writes:
>    There's also Ada.Command_Line.Environment.

Remember that, though Ada.Command_Line is a language-defined package,
Ada.Command_Line.Environment is not.

-- 
Keith Thompson (The_Other_Keith) kst@thomsoft.com <*>
TeleSoft^H^H^H^H^H^H^H^H Alsys^H^H^H^H^H Thomson Software Products
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2706
FIJAGDWOL

Re: Environment variables

[David Shochat]

This whole thread is making me rather sick. I was recently involved with
an effort involving porting a good bit of Ada 83 code to Ada 95, in
which the necessary conversion of X-windows code from "AXI Bindings" to
"Intermetrics Bindings" was fairly massive and non-trivial.

My point is that things like reading environment variables should be
standardized. On our project we have tried to stick to the POSIX
packages (Forest for us -- the newer one wasn't available when we
started) for Unix interface functions which aren't standardized in the
RM. When a C programmer wants to read environment variables, she doesn't
have to choose among 6 different interfaces and worry about what happens
when she moves the code to a different vendor's compiler etc. I know
reading environment variables is an extremely exercise in pragma Import,
but this sort of thing should just be there to use. As it is for the C
programmer (regardless of whose compiler he is using).

..Sigh
-- David

Re: Environment variables

[Larry Kilgallen]

In article <327A32A3.2DD0@itg-sepg.logicon.com>, David Shochat <shochat@itg-sepg.logicon.com> writes:
> This whole thread is making me rather sick. I was recently involved with
> an effort involving porting a good bit of Ada 83 code to Ada 95, in
> which the necessary conversion of X-windows code from "AXI Bindings" to
> "Intermetrics Bindings" was fairly massive and non-trivial.
> 
> My point is that things like reading environment variables should be
> standardized. On our project we have tried to stick to the POSIX
> packages (Forest for us -- the newer one wasn't available when we
> started) for Unix interface functions which aren't standardized in the
> RM.

Although some may be able to limit use of their projects to running in a
Posix environment, not every project can live with that constraint.  Aside
from Unix systems, most Posix environments are separate environments from
the native environment for a platform, and often there are requirements to
use X-windows outside the Posix environment.  The particular example of
"environment variables" does not make sense outside Posix/Unix, so those
who have been bitten once by a portability issue should consider future
porting requirements as well.

Larry Kilgallen

Re: Environment variables

[Michael F Brenner]

Larry Kilgallen said:
    > The particular example of
    > "environment variables" does not make sense outside Posix/Unix, so those
    > who have been bitten once by a portability issue should consider future
    > porting requirements as well.

It might be good to consider that environment variables make sense in DOS,
DOS with PharLap extender, DOS with Desqview extender, DOS with Desqview/X
extender, Windows NT, OS/2, VxWorks, and other operating systems. Are there
any operating systems or remote target (embedded) runtime systems that 
do not provide environment variables?

Re: Environment variables

[Larry Kilgallen]

In article <55kmb1$3m6@top.mitre.org>, mfb@mbunix.mitre.org (Michael F Brenner) writes:
> Larry Kilgallen said:
>     > The particular example of
>     > "environment variables" does not make sense outside Posix/Unix, so those
>     > who have been bitten once by a portability issue should consider future
>     > porting requirements as well.
> 
> It might be good to consider that environment variables make sense in DOS,
> DOS with PharLap extender, DOS with Desqview extender, DOS with Desqview/X
> extender, Windows NT, OS/2, VxWorks, and other operating systems. Are there
> any operating systems or remote target (embedded) runtime systems that 
> do not provide environment variables?

VMS, MacOS and MVS do not have "environment variables" with their
native user environments.  Naturally they all have them in their
Posix environments (or Unix emulators).  But some requirements
may preclude running within those Posix/Unix subsystems.

Naturally all these operating systems have something "just as good
as" environment variables, but all subtly different.  In the case
of VMS, both the logical name mechanism and the DCL symbol mechanism
have some of the qualities of environment variables, but neither is
an exact match.

Are you sure that the non-Unix operating systems listed all ascribe
semantics to "environment variables" which have the same meaning and
scope as those for Unix ?  Certainly the goal is not to access just
any construct an operating system vendor might have named "environment
variables".

Larry Kilgallen

Re: Environment variables

[Robert Dewar]

Michael said

"It might be good to consider that environment variables make sense in DOS,
DOS with PharLap extender, DOS with Desqview extender, DOS with Desqview/X
extender, Windows NT, OS/2, VxWorks, and other operating systems. Are there
any operating systems or remote target (embedded) runtime systems that
do not provide environment variables?"

Very few remote target (embedded) runtime systems have environment
variables and many operating systems do not. If they were standard
they would be in the standard libraries.

They are standard in ANSI, but with entirely implementation defined
semantics.
ANSI => ANSI C

Re: Environment variables

[Norman H. Cohen]

Robert Dewar wrote:

> Very few remote target (embedded) runtime systems have environment
> variables and many operating systems do not. If they were standard
> they would be in the standard libraries.
> 
> They are standard in ANSI, but with entirely implementation defined
> semantics.
> ANSI => ANSI C

The ANSI C standard specifically acknowledges that the C standard
library need not be supported on an embedded target.  Section 2.1.2
defines two kinds of execution environments, "hosted" and
"freestanding".  Subsection 2.1.2.1 describes a freestanding environment
as follows:

        In a freestanding environment (in which C program execution 
     may take place without benefit of an operating system), the name
     and type of the function called at program startup are
     implementation-defined.  There are otherwise no reserved external
     identifiers.  Any library facilities available to a freestanding
     program are implementation-defined.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Environment variables

[Stephen Leake]

Laurent Guerby wrote:
> 
> Robert> If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in
> Robert> file g-os_lib.ads (there are lots of useful routines in this
> Robert> package :-)
> 
>    There's also Ada.Command_Line.Environment.
> 

This package is in gnat, but it does not seem to be in the RM, at least,
not in the index or appendix A. Is it Ada 95 standard, or a gnat
extension? The source doesn't say either; do the sources of gnat
extensions indicate that they are extensions?
-- 
- Stephe

Re: Environment variables

[Robert Dewar]

iStephen asks

"This package is in gnat, but it does not seem to be in the RM, at least,
not in the index or appendix A. Is it Ada 95 standard, or a gnat
extension? The source doesn't say either; do the sources of gnat
extensions indicate that they are extensions?

This is not an extension to the language. Any Ada compiler can provide
additional useful packages

Re: Environment variables

[Robert A Duff]

In article <dewar.846951642@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
>This is not an extension to the language. Any Ada compiler can provide
>additional useful packages

Robert, you have a strange definition of "extension".  I would say: This
*is* an extension to the language.  Any Ada compiler can provide
extensions of this nature (additional useful packages).  Other
extensions that are explicitly allowed by the RM are additional pragmas
and attributes.  Most extensions are of course DISallowed by the RM.

To the Ada programmer, this thing is an extension, in the sense that it
provides functionality available on GNAT, which may or may not be
available on some other compiler.  In practical terms, if you use a
different compiler, your program will stop working.

- Bob

Re: Environment variables

[Robert Dewar]

Bob said

"Robert, you have a strange definition of "extension".  I would say: This
*is* an extension to the language.  Any Ada compiler can provide
extensions of this nature (additional useful packages).  Other
extensions that are explicitly allowed by the RM are additional pragmas
and attributes.  Most extensions are of course DISallowed by the RM.

To the Ada programmer, this thing is an extension, in the sense that it
provides functionality available on GNAT, which may or may not be
available on some other compiler.  In practical terms, if you use a
different compiler, your program will stop working."


This is just a matter of terminology of course, but by your definition ANY
package provided with a compiler is an extension (there is nothing special
about calling a package Ada.xxxx.yyy from this point of view). I do not
find it useful to use the word extension in conjunction with packages (is
it an extension of C if you allow C programs to call sockets stuff?)

I would call additional pragmas and attributes cases of allowed extensions.
So, that's my definition. Additional packages that the compiler knows nothing
about but which are simply provided for use by users who want the facilities
in these packages I do not call extensions, additional pragmas or attributes
(or, getting into "non-permitted" areas) other language additions, I would
call extensions.

Sure, if you use packages that don't port, you are not portable, but the
distincition I make is a useful one. A package can be ported much more
easily than a pragma or attribute. It is true that a grandchild of
Ada is a little less portable, but it is easy to change its name.

Re: Environment variables

[Stephen Leake]

Bob Duff wrote:
> 
> "Robert, you have a strange definition of "extension".  I would say: This
> *is* an extension to the language.  Any Ada compiler can provide
> extensions of this nature (additional useful packages).  Other
> extensions that are explicitly allowed by the RM are additional pragmas
> and attributes.  Most extensions are of course DISallowed by the RM.
> 
> [snip]
> 
Robert Dewar wrote:

> This is just a matter of terminology of course, but by your definition ANY
> package provided with a compiler is an extension (there is nothing special
> about calling a package Ada.xxxx.yyy from this point of view). I do not
> find it useful to use the word extension in conjunction with packages (is
> it an extension of C if you allow C programs to call sockets stuff?)
> 
> [snip]

As the one that started this thread (by asking whether
Ada.Command_Line.Environment was an `extension'), I'd like to say I
agree with Robert Dewar's definition of `extension'; I was being sloppy.
On the other hand, I think it would be reasonable to say that
Ada.Command_Line.Environment is an extension of the "Ada 95 Predefined
Language Environment", which is defined in Annex A of the RM; obviously,
any package could be described this way, so it's not a very useful
description. 

In any case, as Laurent pointed, out, it IS possible to tell from the
sources that Ada.Command_Line.Environment is NOT defined by the Ada 95
RM, which is what I really wanted to know. However, it requires knowing
what the commenting style is in packages that are defined in the RM. I
think compiler-provided packages that are NOT defined by the RM should
be more clearly labeled as such, to make it easier to know when we are
being non-portable.

-- 
- Stephe

Re: Environment variables

[Larry Kilgallen]

In article <327DF7F2.2484@gsfc.nasa.gov>, Stephen Leake <Stephen.Leake@gsfc.nasa.gov> writes:

> In any case, as Laurent pointed, out, it IS possible to tell from the
> sources that Ada.Command_Line.Environment is NOT defined by the Ada 95
> RM, which is what I really wanted to know. However, it requires knowing
> what the commenting style is in packages that are defined in the RM. I
> think compiler-provided packages that are NOT defined by the RM should
> be more clearly labeled as such, to make it easier to know when we are
> being non-portable.

Presumably most such packages would not be so intertwined as to require
that they be a child package of Ada.

Larry Kilgallen

Re: Environment variables

[Robert Dewar]

Stephe said

"In any case, as Laurent pointed, out, it IS possible to tell from the
sources that Ada.Command_Line.Environment is NOT defined by the Ada 95
RM, which is what I really wanted to know. However, it requires knowing
what the commenting style is in packages that are defined in the RM. I
think compiler-provided packages that are NOT defined by the RM should
be more clearly labeled as such, to make it easier to know when we are
being non-portable."

Already done for the next release. Actually this was made a child package
of Ada.COmmand_Line with the thought of possible semi-standarization
(ACE?) in mind. Note that there is also a routine in GNAT.OS_Lib for
getting environment variables, which is more obviously a GNAT add on.

Re: Environment variables

[Tucker Taft]

Robert A Duff (bobduff@world.std.com) wrote:

: In article <dewar.846951642@merv>, Robert Dewar <dewar@merv.cs.nyu.edu> wrote:
: >This is not an extension to the language. Any Ada compiler can provide
: >additional useful packages

: Robert, you have a strange definition of "extension".  I would say: This
: *is* an extension to the language.  Any Ada compiler can provide
: extensions of this nature (additional useful packages).  Other
: extensions that are explicitly allowed by the RM are additional pragmas
: and attributes.  Most extensions are of course DISallowed by the RM.

: To the Ada programmer, this thing is an extension, in the sense that it
: provides functionality available on GNAT, which may or may not be
: available on some other compiler.  In practical terms, if you use a
: different compiler, your program will stop working.

I think the big difference with this kind of extension is that
you can write such packages yourself, without having to talk to the
compiler vendor.  On the other hand, other permissible "extensions"
like additional pragmas and attributes are almost always restricted
to the compiler implementor.

: - Bob

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Environment variables

[Laurent Guerby]

Laurent>  There's also Ada.Command_Line.Environment.

Stephen> This package is in gnat, but it does not seem to be in the
Stephen> RM, at least, not in the index or appendix A. Is it Ada 95
Stephen> standard, or a gnat extension? The source doesn't say either;
Stephen> do the sources of gnat extensions indicate that they are
Stephen> extensions?

   It's a GNAT extension. Note that, technically speaking, it's legal
for an implementation to provide a completly different
Ada.Command_Line than the one listed in the RM, as per RM-A.15(21):

RM> 			     Implementation Permissions
RM> 
RM> 21   An alternative declaration is allowed for package Command_Line if
RM> different functionality is appropriate for the external execution
RM> environment.

   You can tell if one source is coming from the standard or from GNAT
by looking at the header, the GNAT stuff is GPL'ed (plus extra
permission) and the RM stuff headers look like:

------------------------------------------------------------------------------
--                                                                          --
--                         GNAT RUNTIME COMPONENTS                          --
--                                                                          --
--                     A D A . C O M M A N D _ L I N E                      --
--                                                                          --
--                                 S p e c                                  --
--                                                                          --
--                            $Revision: 1.8 $                              --
--                                                                          --
-- This specification is adapted from the Ada Reference Manual for use with --
-- GNAT.  In accordance with the copyright of that document, you can freely --
-- copy and modify this specification,  provided that if you redistribute a --
-- modified version,  any changes that you have made are clearly indicated. --
--                                                                          --
------------------------------------------------------------------------------

-- 
Laurent Guerby <guerby@gnat.com>, Team Ada.
   "Use the Source, Luke. The Source will be with you, always (GPL)."

Re: Environment variables

[Robert Dewar]

Laurent said

'   It's a GNAT extension. Note that, technically speaking, it's legal
for an implementation to provide a completly different
Ada.Command_Line than the one listed in the RM, as per RM-A.15(21):"

This is true, but quite irrelevant. The issue here is providing 
implementation defined grandchildren of Ada, which is always permitted,
without needing to appeal to special provisions.

Re: Environment variables

[Robert A Duff]

In article <ws9aft1vgse.fsf@schonberg.cs.nyu.edu>,
Laurent Guerby <guerby@gnat.com> wrote:
>...Note that, technically speaking, it's legal
>for an implementation to provide a completly different
>Ada.Command_Line than the one listed in the RM, as per RM-A.15(21):

Only if it is "appropriate" to do so.  ;-)

>RM> 			     Implementation Permissions
>RM> 
>RM> 21   An alternative declaration is allowed for package Command_Line if
>RM> different functionality is appropriate for the external execution
>RM> environment.

- Bob

Re: Environment variables

[Norman H. Cohen]

Laurent Guerby wrote:
 
> Robert> If you are using GNAT, take a look at GNAT.OS_Lib.Getenv in
> Robert> file g-os_lib.ads (there are lots of useful routines in this
> Robert> package :-)
> 
>    There's also Ada.Command_Line.Environment.

Note (1) that this is a GNAT-only child of Ada.Command_Line and (2) that
this package only gives you access to a sequence of strings such as
"GNAT_DIR=D:\ADA\gnat304a", leaving you to do the work of finding a
string with a given name before the '=' and extracting the value after
the '='.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Environment variables

[David Emery]

Access to environment variables is included in POSIX/Ada 
(ISO 14519-1:1995/IEEE 1003.5-1992), in the package
POSIX_Process_Environment. 

			dave


-- 
<.sig is away on vacation>

Re: Environment variables

[James Rogers]

---------------------------------------------------------------------------
-- Test GNAT's ability to query the environment
---------------------------------------------------------------------------

with Ada.TExt_IO; use Ada.Text_io;
with Ada.Command_Line.Environment; use Ada.Command_Line.Environment;

procedure environ is

   set_count : constant natural := Environment_Count;

begin

   for Item in 1..positive(set_count) loop
      put_line(Environment_Value(Item));
   end loop;
end environ;

-- 
Jim Rogers
*************************************************************
Team Ada

Re: Environment variables

[Robert I. Eachus]

In article <55819q$mql@newslink.runet.edu> carnold@runet.edu (Christopher J Arnold) writes:

  > Ok, some one please help me.

  > All I want to do is to be able to read the value of environment 
  > variables, such as PATH for example.  I've looked around at FAQ's and the 
  > adahome reference pages, but I haven't found anything.

  > Thanks in advance.

   I won't claim credit for all this code.  I think part of the
Get_Enviroment code goes back to Dave Emery's POSIX work. (I will take
all of any blame though, since I recently modified Get_Enviroment to
be less dependant on any one compiler, and rewrote Set_Environment
from memory.)  This code has only been tested on a few compilers, but
should be very portable on Unix machines.

    Incidently notice that garbage collectors, conservative or
otherwise, can be dangerous to your health here.  The only retained
pointer to the string allocated in Set_Environment is in the OS, not
in your program.  (Yes, this is the behavior that Unix expects.  Since
the only processes which share the environment variable are children
of your process, you are safe unless you do an exec.  An exec after a
setenv in the same process is usually a BAD THING, since that
environment variable is likely to get overwritten.)

-----------------------------------------------------------------------------

with System; use System;
function Get_Environment(Variable : String) return String is
-- Return the value of the given environment variable.
-- If there's no such environment variable, return an empty string.
  type String_Pointer is access String(1..Integer'LAST);
  function getenv(Variable : System.Address) return String_Pointer;
  pragma Interface(C, getenv);
  -- getenv is a standard C library function; see K&R 2, 1988, page 253.
  -- it returns a pointer to the first character; do NOT free its results.
  Variable_In_C_Format : constant String := Variable&Ascii.Nul;
  Result_Ptr : String_Pointer := getenv(Variable_In_C_Format(1)'ADDRESS);
  function strlen(Pointer: in String_Pointer) return Integer;
  pragma Interface(C,strlen);
begin
  if Result_Ptr = null
  then return "";
  else return Result_Ptr(1..strlen(Result_Ptr));
  end if;
end Get_Environment;

with System; use System;
procedure Set_Environment(Str: String)is
-- Set the value of the given environment variable.
-- Str should be in the form Name=Value
  function putenv(String_Ptr : System.Address) return Integer;
  pragma Interface(C, putenv);
  type String_Pointer is access String;
  Str_In_C_Format : String_Pointer := new String'(Str&Ascii.Nul);
  Temp: Integer;
begin
  Temp := putenv(Str_In_C_Format(1)'Address);
  if Temp /= 0 then raise Program_Error; end if;
end Set_Environment;

-----------------------------------------------------------------------------
--

					Robert I. Eachus

with Standard_Disclaimer;
use  Standard_Disclaimer;
function Message (Text: in Clever_Ideas) return Better_Ideas is...

Re: Environment variables

[Doug Smith]

In article <55819q$mql@newslink.runet.edu> carnold@runet.edu (Christopher J Arnold) writes:

  > Ok, some one please help me.

  > All I want to do is to be able to read the value of environment 
  > variables, such as PATH for example.  I've looked around at FAQ's and the 
  > adahome reference pages, but I haven't found anything.

  > Thanks in advance.

I just put the latest version of WebAda's CGI binding here, other WebAda code is undergoing revision and is not ready for release. Specifically to the question, CGI.Environment provides access to environment variables.

<http://sw-eng.falls-church.va.us/AdaIC/compilers/webada/source/cgi>

Doug.
dsmith@clark.net

Re: Environment variables

[Matthew Heaney]

In article <EACHUS.96Oct30201754@spectre.mitre.org>,
eachus@spectre.mitre.org (Robert I. Eachus) wrote:


>with System; use System;
>function Get_Environment(Variable : String) return String is
>-- Return the value of the given environment variable.
>-- If there's no such environment variable, return an empty string.
>  type String_Pointer is access String(1..Integer'LAST);
>  function getenv(Variable : System.Address) return String_Pointer;
>  pragma Interface(C, getenv);
>  -- getenv is a standard C library function; see K&R 2, 1988, page 253.
>  -- it returns a pointer to the first character; do NOT free its results.
>  Variable_In_C_Format : constant String := Variable&Ascii.Nul;
>  Result_Ptr : String_Pointer := getenv(Variable_In_C_Format(1)'ADDRESS);
>  function strlen(Pointer: in String_Pointer) return Integer;
>  pragma Interface(C,strlen);
>begin
>  if Result_Ptr = null
>  then return "";
>  else return Result_Ptr(1..strlen(Result_Ptr));
>  end if;
>end Get_Environment;

This isn't a very good way to interface Ada string pointers to C, because
this example assumes the string access object designates the first
character of the string.  This is a very dangerous assumption, because a
string access object could be pointing to a string descriptor, not the
string itself.  In fact, this is how access types are implemented in DEC
Ada.

The issue is with pointers to unconstrained arrays.  A more portable way is
to make the string access type designate a constrained array; thay way, no
dope vector is required.

function Get_Environment (Variable : String) return String is

   type Character_Array is array (Positive) of Character;
   type String_Access is access Character_Array;    -- more portable
   pragma String_Access'Storage_Size = 0;

   Variable_In_C_Format : constant String := Variable & ASCII.NUL;

   function Getenv (S : System.Address) return String_Access;
   pragma Interface (C, Getenv);

   The_Environment_Value : constant String_Access :=
      Getenv (Variable_In_C_Format (1)'Address);
...

Generally, if the accessed type is constrained, no dope vector is required,
and access objects designate the array (in this case), not a descriptor, so
that the Ada string pointer matches the C string pointer.

And remember to set the storage_size of the pool to 0, to explicitly
indicate that no memory is being allocated by the Ada runtime environment.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
mheaney@ni.net
(818) 985-1271

Re: Environment variables

[Norman H. Cohen]

Christopher J Arnold wrote:

> All I want to do is to be able to read the value of environment
> variables, such as PATH for example.  I've looked around at FAQ's and the
> adahome reference pages, but I haven't found anything.

This happens to be the example used to illustrate the use of
Interfaces.C.Strings on page 989 of Ada as a Second Language.  It's only
a couple of dozen lines long, including comments.

For purposes of illustration, the example there returns a value of type
String--the empty string for undefined environment variables and the
value of the variable surrounded by '"' characters for defined
variables.  (This allows an undefined environment variable and an
environment variable defined to be the empty string to be represented by
two different values of type String.)  However, this is probably not the
most convenient interface to use.  The example is easily modified to
behave more like the C getenv function--returning a null access value
for an undefined environment variable and an access value pointing to
some String value for a defined environment variable.

-- 
Norman H. Cohen
mailto:ncohen@watson.ibm.com
http://www.research.ibm.com/people/n/ncohen

Re: Environment variables

[David Wheeler]

Christopher J Arnold wrote:
> All I want to do is to be able to read the value of environment
> variables, such as PATH for example.  I've looked around at FAQ's and the
> adahome reference pages, but I haven't found anything.

Norman H. Cohen said:
: This happens to be the example used to illustrate the use of
: Interfaces.C.Strings on page 989 of Ada as a Second Language.  It's only
: a couple of dozen lines long, including comments.

This is also an example in "Lovelace", lesson 16 (which discusses
interfacing to C).  The most portable approach to getting environment
variables I've found is assuming that there's a C library handy
(usually true), and since the C library includes a "getenv" function
just take advantage of that.

Yes, it'd be nice if there was a standard Ada function that did this for you,
but there are standard mechanisms for interfacing to C, so you don't
have to do a lot work.

--- David A. Wheeler
    dwheeler@ida.org

P.S. Here's the body of the version given in Lovelace.
Slap it into a package and you're ready to go:

with Interfaces.C.Strings; use Interfaces.C.Strings;
-- ...

 function Value_Without_Exception(S : chars_ptr) return String is
 -- Translate S from a C-style char* into an Ada String.
 -- If S is Null_Ptr, return "", don't raise an exception.
 begin
   if S = Null_Ptr then return "";
    else return Value(S);
   end if;
 end Value_Without_Exception;
 pragma Inline(Value_Without_Exception);
 
 function Get_Environment(Variable : String) return String is
 -- Return the value of the given environment variable.
 -- If there's no such environment variable, return an empty string.
 
   function getenv(Variable : chars_ptr) return chars_ptr;
   pragma Import(C, getenv);
   -- getenv is a standard C library function; see K&R 2, 1988, page 253.
   -- it returns a pointer to the first character; do NOT free its results.
 
   Variable_In_C_Format : chars_ptr := New_String(Variable);
   Result_Ptr : chars_ptr := getenv(Variable_In_C_Format);
   Result : String := Value_Without_Exception(Result_Ptr);
 
 begin
  Free(Variable_In_C_Format);
  return Result;
 end Get_Environment;

-- .. end of the body.


-- ... and here's a sample use:

  Request_Method_Text : String := Get_Environment("REQUEST_METHOD");

Re: Environment variables

[Christopher J Arnold]

I've now got my program to read environment variables.

I'd like to thank everyone for their help :>.

Chris,

Re: Environment variables

[Robert Dewar]

Dave Wheeler said

"Yes, it'd be nice if there was a standard Ada function that did this for you"

Hmmm! a bit dubious, given there are many systems on which the concept of
environment variable is either missing or is not clear. It seems to me that
Unix-related functions like this are better supplied via the Posix
interface.

But I agree this one is on the edge.