Environment variables

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 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

[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

[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

[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

[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

[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

Standard libraries (Was: Environment variables)

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) 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. "

You could say the same of package Ada.Command_Line. The important point
is, IMHO, that a reasonable number of different platforms (Dos, Unix,
Windows, OS/2, Mac) which represent a significant share (90%?) of the
potential Ada users have this same problem. That is a good enough
reason to have some form of standard interface.

I do not say that this functionality (including Ada.Command_Line)
should be part of the standardized Ada language. Issues like these are
very well suited to less formal standardizing, like including extra
functionality in the GNAT standard libraries. These might perhaps be
separated from the Ada.* hierarchy in an Extra.* hierarchy.

Given the significant use of GNAT in proportion to other Ada-95
compilers, an initiative (supported) by the developers of GNAT in this
direction might be followed by others and become a de facto standard.

Important areas to be covered by such an extension would be:

* Terminal IO including cursor positioning commands and attribute
changes. Of course these should be stored with each Terminal_IO file
opened, so multiple tasks can maintain there own position/attributes
without interfering with other tasks using the same terminal.

* File-system support for changing current directory, querying
information about files in the current directory and 
deleting/renaming files.

* Network IO which would at least support (a subset of) populair
TCP/IP networking, so there is a common way of communicating
between computers connected to the Internet.


These are points that have very much in common on the major platforms
like Dos, Unix, OS/2, Macintosh and Windows, although not all platforms
will have standard support for all areas. 

This is no reason however to *not* make *any* attempt to standardize
on these very common external interfaces. Many programs only need
the very simple common features described above which can have good
portability between platforms. 

Is it really necessary that every Ada user invents his own
ANSI-emulator? Should everybody make his own platform-specific
procedure for deleting an external file? 
Is that what code reuse is all about?

I suggest that we, as Ada users and c.l.a. readers/writers, make
an effort to standardize on specifications for these interfaces.
Implementing them is easy enough.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Standard libraries (Was: Environment variables)

[Robert Dewar]

Geert says

"You could say the same of package Ada.Command_Line. The important point
is, IMHO, that a reasonable number of different platforms (Dos, Unix,
Windows, OS/2, Mac) which represent a significant share (90%?) of the
potential Ada users have this same problem. That is a good enough
reason to have some form of standard interface.

I do not say that this functionality (including Ada.Command_Line)
should be part of the standardized Ada language. Issues like these are
very well suited to less formal standardizing, like including extra
functionality in the GNAT standard libraries. These might perhaps be
separated from the Ada.* hierarchy in an Extra.* hierarchy."


Can you please explain why the approved IEEE POSIX-Ada binding, which has
this functionality, as well as all the other functionality you go on to
describe in your note, does not EXACTLY meet this requirement, in EXACTLY
the manner that you recommend?

Re: Standard libraries (Was: Environment variables)

[Geert Bosch]

Robert Dewar wrote:
  "Can you please explain why the approved IEEE POSIX-Ada binding, which has
   this functionality, as well as all the other functionality you go on to
   describe in your note, does not EXACTLY meet this requirement, in EXACTLY
   the manner that you recommend? "

As far as I have seen (looking at forest, I don't have the standard you
mention as it is not public) this binding is very Unix specific and
only meant for Unix systems.  So rather than defining an interface that
defines a consistent subset of the functionality most common platforms
have, it takes one (Unix) and wraps a thin layer around the standard C
library so it can be used in Ada.

Instead of providing functions to set a file to read-only or read-write
permissions, you can only set group, user and others access bits a-la
Unix.

If I want to write a cross-platform application that write-protects a file
(for example during compilation) I want a way to specify that somehow.
Having to use a group/owner/others set of permissions just doesn't make
sense on other platforms. However it *does* make sense to write-protect
a file in Unix, or to reset the rights to read/write. In the first case
the Unix file mode is set like "chmod a-r" and in the second case file
attributes are reset to the defaults as determined by the environment
(UMASK in Unix).

What I want is to have an interface that *increases* portability by
specifying the common functionality of several major platforms. That
way I know that I'm using a portable subset. If I need platform-specific
features like sending a process a -SIGSTOP signal, then I could use
the POSIX library. What does it mean to Unlink a file? 

The POSIX standard just is based on Unix implementation details like
the Unix file-system using group/user/world permissions and i-nodes,
It will be really hard to write a program using for example forest and
not relying on a Unix implementation. 

Maybe I'm wrong and POSIX means Portable Operating System Interface for
Computer Environments after all. But a comment in the Available
Ada Bindings report from the AI&C tells more about the standard:
   "The POSIX program grew from the effort by Unix users to develop 
    a "standard" definition of the Unix system interface. "

I don't think it has grown much beyond that.  There is a *huge* gap
between the very clear, cross-platform standard Ada library that uses
good Ada-style abstractions and the C-oriented Unix API put into an Ada
coat.

Don't get me wrong, I really like it that there is at least a good
interface for Unix programs available, which maybe even might run on
other systems using a Unix-emulation layer. Using the Unix API for
writing programs that should also run in DOS however is abstraction
inversion IMHO. You'll get a program that is barely readable and hard
to maintain, because it relies very much on implementation details of
Unix and the Unix-emulation layer.

Regards,
   Geert
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Standard libraries (Was: Environment variables)

[Robert Dewar]

Geert said

'As far as I have seen (looking at forest, I don't have the standard you
mention as it is not public) this binding is very Unix specific and
only meant for Unix systems.  So rather than defining an interface that
defines a consistent subset of the functionality most common platforms
have, it takes one (Unix) and wraps a thin layer around the standard C
library so it can be used in Ada."


Well it is POSIX specific rather than Unix specific, many non-Unix systems
have promised Posix compliance (including incidentally at one point OS/2).
Certainly for example NT provides POSIX compliance and so does VMS.

Yes, it is not necessarily portable to arbitrary non-POSIX compliant
environments but this discussion arose in the context of environment
variables, which are particular to Unix and Unix-like systems in any case.

Re: Standard libraries (Was: Environment variables)

[Geert Bosch]

Robert Dewar (dewar@merv.cs.nyu.edu) wrote:
  "Well it is POSIX specific rather than Unix specific, many non-Unix
   systems have promised Posix compliance (including incidentally at
   one point OS/2).  Certainly for example NT provides POSIX compliance
   and so does VMS."

I wasn't saying that it is not possible to have a POSIX-layer
(I called it POSIX-emulation) on different platforms, just that the
abstraction used is not very usable. It is just backwards to use 
very specific Unix calls which do not represent what you really want
to do and then have an emulation layer to translate the very specific
call to the more simple call that the underlying system provides.

For Ada it would be preferable to have simple extensions that use
the current standard library as a basis. Named pipes between processes
would be established by implementing a special File_Type that
can be be used as Ada.Streams.Root_Stream_Type'Class. There is a
reason that this is suggested in RM95 13.13(1). Certainly using the
Unix API standardized by POSIX is not EXACTLY the same.

Regards,
   Geert

PS. It would be straightforward to port forest to OS/2, as much as it
    is straightforward to post most Unix applications to OS/2.
-- 
E-Mail: geert@sun3.iaf.nl    

Re: Standard libraries (Was: Environment variables)

[Larry Kilgallen]

In article <56n7p5$7co@fozzie.sun3.iaf.nl>, geert@fozzie.sun3.iaf.nl (Geert Bosch) writes:

> I wasn't saying that it is not possible to have a POSIX-layer
> (I called it POSIX-emulation) on different platforms, just that the

No, it really is POSIX -- a set of interfaces defined to be capable
of implementation on Unix and non-Unix systems alike.

> abstraction used is not very usable. It is just backwards to use 
> very specific Unix calls which do not represent what you really want
> to do and then have an emulation layer to translate the very specific
> call to the more simple call that the underlying system provides.

If you look at the work various non-Unix vendors had to do to provide
POSIX support, you get an idea of the scope of effort required to get
"common" interfaces across operating systems.  I am not personally a
fan of the POSIX interfaces, but at least it has a chance to be common.

> For Ada it would be preferable to have simple extensions that use
> the current standard library as a basis. Named pipes between processes
> would be established by implementing a special File_Type that
> can be be used as Ada.Streams.Root_Stream_Type'Class. There is a
> reason that this is suggested in RM95 13.13(1). Certainly using the
> Unix API standardized by POSIX is not EXACTLY the same.

For an Ada vendor to implement named pipes without support from the
OS vendor seems to me highly unlikely to be efficient, secure and
correct.  I would prefer Ada implementors spent their time on the
quality of debugger support and interfaces to OS constructs which
are already well supported.

At some point, activities are just not portable.  I have seen many
programs perform horribly after porting because someone neglected
the _fact_ that an operation which is quite efficient on one
operating system may well be horribly inefficient on another.

Larry Kilgallen

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 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

[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

[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

[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

[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

[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

[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.