* Environment variables @ 1996-10-30 0:00 Christopher J Arnold 1996-10-30 0:00 ` David Taylor ` (4 more replies) 0 siblings, 5 replies; 45+ messages in thread From: Christopher J Arnold @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 Environment variables Christopher J Arnold @ 1996-10-30 0:00 ` David Taylor 1996-10-30 0:00 ` David Emery ` (3 subsequent siblings) 4 siblings, 0 replies; 45+ messages in thread From: David Taylor @ 1996-10-30 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 Environment variables Christopher J Arnold 1996-10-30 0:00 ` David Taylor @ 1996-10-30 0:00 ` David Emery 1996-10-30 0:00 ` Robert Dewar ` (6 more replies) 1996-10-31 0:00 ` James Rogers ` (2 subsequent siblings) 4 siblings, 7 replies; 45+ messages in thread From: David Emery @ 1996-10-30 0:00 UTC (permalink / raw) >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> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery @ 1996-10-30 0:00 ` Robert Dewar 1996-10-30 0:00 ` Laurent Guerby ` (5 subsequent siblings) 6 siblings, 0 replies; 45+ messages in thread From: Robert Dewar @ 1996-10-30 0:00 UTC (permalink / raw) ">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 :-) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery 1996-10-30 0:00 ` Robert Dewar @ 1996-10-30 0:00 ` Laurent Guerby 1996-11-02 0:00 ` Keith Thompson 1996-11-01 0:00 ` David Shochat ` (4 subsequent siblings) 6 siblings, 1 reply; 45+ messages in thread From: Laurent Guerby @ 1996-10-30 0:00 UTC (permalink / raw) 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)." ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` Laurent Guerby @ 1996-11-02 0:00 ` Keith Thompson 0 siblings, 0 replies; 45+ messages in thread From: Keith Thompson @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery 1996-10-30 0:00 ` Robert Dewar 1996-10-30 0:00 ` Laurent Guerby @ 1996-11-01 0:00 ` David Shochat 1996-11-02 0:00 ` Larry Kilgallen 1996-11-01 0:00 ` Environment variables Laurent Guerby ` (3 subsequent siblings) 6 siblings, 1 reply; 45+ messages in thread From: David Shochat @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-01 0:00 ` David Shochat @ 1996-11-02 0:00 ` Larry Kilgallen 1996-11-04 0:00 ` Michael F Brenner 0 siblings, 1 reply; 45+ messages in thread From: Larry Kilgallen @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-02 0:00 ` Larry Kilgallen @ 1996-11-04 0:00 ` Michael F Brenner 1996-11-04 0:00 ` Larry Kilgallen 1996-11-12 0:00 ` Robert Dewar 0 siblings, 2 replies; 45+ messages in thread From: Michael F Brenner @ 1996-11-04 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-04 0:00 ` Michael F Brenner @ 1996-11-04 0:00 ` Larry Kilgallen 1996-11-12 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Larry Kilgallen @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-04 0:00 ` Michael F Brenner 1996-11-04 0:00 ` Larry Kilgallen @ 1996-11-12 0:00 ` Robert Dewar 1996-11-13 0:00 ` Norman H. Cohen 1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch 1 sibling, 2 replies; 45+ messages in thread From: Robert Dewar @ 1996-11-12 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-12 0:00 ` Robert Dewar @ 1996-11-13 0:00 ` Norman H. Cohen 1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch 1 sibling, 0 replies; 45+ messages in thread From: Norman H. Cohen @ 1996-11-13 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Standard libraries (Was: Environment variables) 1996-11-12 0:00 ` Robert Dewar 1996-11-13 0:00 ` Norman H. Cohen @ 1996-11-14 0:00 ` Geert Bosch 1996-11-14 0:00 ` Robert Dewar 1 sibling, 1 reply; 45+ messages in thread From: Geert Bosch @ 1996-11-14 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Standard libraries (Was: Environment variables) 1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch @ 1996-11-14 0:00 ` Robert Dewar 1996-11-16 0:00 ` Geert Bosch 0 siblings, 1 reply; 45+ messages in thread From: Robert Dewar @ 1996-11-14 0:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Standard libraries (Was: Environment variables) 1996-11-14 0:00 ` Robert Dewar @ 1996-11-16 0:00 ` Geert Bosch 1996-11-16 0:00 ` Robert Dewar 0 siblings, 1 reply; 45+ messages in thread From: Geert Bosch @ 1996-11-16 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Standard libraries (Was: Environment variables) 1996-11-16 0:00 ` Geert Bosch @ 1996-11-16 0:00 ` Robert Dewar 1996-11-17 0:00 ` Geert Bosch 0 siblings, 1 reply; 45+ messages in thread From: Robert Dewar @ 1996-11-16 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Standard libraries (Was: Environment variables) 1996-11-16 0:00 ` Robert Dewar @ 1996-11-17 0:00 ` Geert Bosch 1996-11-18 0:00 ` Larry Kilgallen 0 siblings, 1 reply; 45+ messages in thread From: Geert Bosch @ 1996-11-17 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Standard libraries (Was: Environment variables) 1996-11-17 0:00 ` Geert Bosch @ 1996-11-18 0:00 ` Larry Kilgallen 0 siblings, 0 replies; 45+ messages in thread From: Larry Kilgallen @ 1996-11-18 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery ` (2 preceding siblings ...) 1996-11-01 0:00 ` David Shochat @ 1996-11-01 0:00 ` Laurent Guerby 1996-11-02 0:00 ` Robert A Duff 1996-11-02 0:00 ` Robert Dewar 1996-11-01 0:00 ` Stephen Leake ` (2 subsequent siblings) 6 siblings, 2 replies; 45+ messages in thread From: Laurent Guerby @ 1996-11-01 0:00 UTC (permalink / raw) 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)." ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-01 0:00 ` Environment variables Laurent Guerby @ 1996-11-02 0:00 ` Robert A Duff 1996-11-02 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Robert A Duff @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-01 0:00 ` Environment variables Laurent Guerby 1996-11-02 0:00 ` Robert A Duff @ 1996-11-02 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Robert Dewar @ 1996-11-02 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery ` (3 preceding siblings ...) 1996-11-01 0:00 ` Environment variables Laurent Guerby @ 1996-11-01 0:00 ` Stephen Leake 1996-11-02 0:00 ` Robert Dewar 1996-11-01 0:00 ` Norman H. Cohen 1996-11-05 0:00 ` David Emery 6 siblings, 1 reply; 45+ messages in thread From: Stephen Leake @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-01 0:00 ` Stephen Leake @ 1996-11-02 0:00 ` Robert Dewar 1996-11-03 0:00 ` Robert A Duff 0 siblings, 1 reply; 45+ messages in thread From: Robert Dewar @ 1996-11-02 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-02 0:00 ` Robert Dewar @ 1996-11-03 0:00 ` Robert A Duff 1996-11-03 0:00 ` Robert Dewar 1996-11-04 0:00 ` Tucker Taft 0 siblings, 2 replies; 45+ messages in thread From: Robert A Duff @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-03 0:00 ` Robert A Duff @ 1996-11-03 0:00 ` Robert Dewar 1996-11-04 0:00 ` Stephen Leake 1996-11-04 0:00 ` Tucker Taft 1 sibling, 1 reply; 45+ messages in thread From: Robert Dewar @ 1996-11-03 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-03 0:00 ` Robert Dewar @ 1996-11-04 0:00 ` Stephen Leake 1996-11-04 0:00 ` Larry Kilgallen 1996-11-04 0:00 ` Robert Dewar 0 siblings, 2 replies; 45+ messages in thread From: Stephen Leake @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-04 0:00 ` Stephen Leake @ 1996-11-04 0:00 ` Larry Kilgallen 1996-11-04 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Larry Kilgallen @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-04 0:00 ` Stephen Leake 1996-11-04 0:00 ` Larry Kilgallen @ 1996-11-04 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Robert Dewar @ 1996-11-04 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-03 0:00 ` Robert A Duff 1996-11-03 0:00 ` Robert Dewar @ 1996-11-04 0:00 ` Tucker Taft 1 sibling, 0 replies; 45+ messages in thread From: Tucker Taft @ 1996-11-04 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery ` (4 preceding siblings ...) 1996-11-01 0:00 ` Stephen Leake @ 1996-11-01 0:00 ` Norman H. Cohen 1996-11-05 0:00 ` David Emery 6 siblings, 0 replies; 45+ messages in thread From: Norman H. Cohen @ 1996-11-01 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 ` David Emery ` (5 preceding siblings ...) 1996-11-01 0:00 ` Norman H. Cohen @ 1996-11-05 0:00 ` David Emery 6 siblings, 0 replies; 45+ messages in thread From: David Emery @ 1996-11-05 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 Environment variables Christopher J Arnold 1996-10-30 0:00 ` David Taylor 1996-10-30 0:00 ` David Emery @ 1996-10-31 0:00 ` James Rogers 1996-10-31 0:00 ` Robert I. Eachus 1996-10-31 0:00 ` Norman H. Cohen 4 siblings, 0 replies; 45+ messages in thread From: James Rogers @ 1996-10-31 0:00 UTC (permalink / raw) --------------------------------------------------------------------------- -- 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 Environment variables Christopher J Arnold ` (2 preceding siblings ...) 1996-10-31 0:00 ` James Rogers @ 1996-10-31 0:00 ` Robert I. Eachus 1996-10-31 0:00 ` Doug Smith 1996-11-03 0:00 ` Matthew Heaney 1996-10-31 0:00 ` Norman H. Cohen 4 siblings, 2 replies; 45+ messages in thread From: Robert I. Eachus @ 1996-10-31 0:00 UTC (permalink / raw) 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... ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-31 0:00 ` Robert I. Eachus @ 1996-10-31 0:00 ` Doug Smith 1996-11-03 0:00 ` Matthew Heaney 1 sibling, 0 replies; 45+ messages in thread From: Doug Smith @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-31 0:00 ` Robert I. Eachus 1996-10-31 0:00 ` Doug Smith @ 1996-11-03 0:00 ` Matthew Heaney 1 sibling, 0 replies; 45+ messages in thread From: Matthew Heaney @ 1996-11-03 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-30 0:00 Environment variables Christopher J Arnold ` (3 preceding siblings ...) 1996-10-31 0:00 ` Robert I. Eachus @ 1996-10-31 0:00 ` Norman H. Cohen 1996-11-06 0:00 ` David Wheeler 4 siblings, 1 reply; 45+ messages in thread From: Norman H. Cohen @ 1996-10-31 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-10-31 0:00 ` Norman H. Cohen @ 1996-11-06 0:00 ` David Wheeler 1996-11-08 0:00 ` Christopher J Arnold 1996-11-09 0:00 ` Robert Dewar 0 siblings, 2 replies; 45+ messages in thread From: David Wheeler @ 1996-11-06 0:00 UTC (permalink / raw) 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"); ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-06 0:00 ` David Wheeler @ 1996-11-08 0:00 ` Christopher J Arnold 1996-11-09 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Christopher J Arnold @ 1996-11-08 0:00 UTC (permalink / raw) I've now got my program to read environment variables. I'd like to thank everyone for their help :>. Chris, ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment variables 1996-11-06 0:00 ` David Wheeler 1996-11-08 0:00 ` Christopher J Arnold @ 1996-11-09 0:00 ` Robert Dewar 1 sibling, 0 replies; 45+ messages in thread From: Robert Dewar @ 1996-11-09 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Environment Variables @ 1997-01-21 0:00 John M. Greer 1997-01-24 0:00 ` Mike Bishop ` (3 more replies) 0 siblings, 4 replies; 45+ messages in thread From: John M. Greer @ 1997-01-21 0:00 UTC (permalink / raw) 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) ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment Variables 1997-01-21 0:00 Environment Variables John M. Greer @ 1997-01-24 0:00 ` Mike Bishop 1997-01-24 0:00 ` Matthew Heaney ` (2 subsequent siblings) 3 siblings, 0 replies; 45+ messages in thread From: Mike Bishop @ 1997-01-24 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment Variables 1997-01-21 0:00 Environment Variables John M. Greer 1997-01-24 0:00 ` Mike Bishop @ 1997-01-24 0:00 ` Matthew Heaney 1997-01-25 0:00 ` Robert Dewar 1997-01-25 0:00 ` Doug Smith 1997-01-27 0:00 ` David Emery 3 siblings, 1 reply; 45+ messages in thread From: Matthew Heaney @ 1997-01-24 0:00 UTC (permalink / raw) 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 ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment Variables 1997-01-24 0:00 ` Matthew Heaney @ 1997-01-25 0:00 ` Robert Dewar 0 siblings, 0 replies; 45+ messages in thread From: Robert Dewar @ 1997-01-25 0:00 UTC (permalink / raw) 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. ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment Variables 1997-01-21 0:00 Environment Variables John M. Greer 1997-01-24 0:00 ` Mike Bishop 1997-01-24 0:00 ` Matthew Heaney @ 1997-01-25 0:00 ` Doug Smith 1997-01-27 0:00 ` David Emery 3 siblings, 0 replies; 45+ messages in thread From: Doug Smith @ 1997-01-25 0:00 UTC (permalink / raw) 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> ^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Environment Variables 1997-01-21 0:00 Environment Variables John M. Greer ` (2 preceding siblings ...) 1997-01-25 0:00 ` Doug Smith @ 1997-01-27 0:00 ` David Emery 3 siblings, 0 replies; 45+ messages in thread From: David Emery @ 1997-01-27 0:00 UTC (permalink / raw) 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' ^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~1997-01-27 0:00 UTC | newest] Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 1996-10-30 0:00 Environment variables Christopher J Arnold 1996-10-30 0:00 ` David Taylor 1996-10-30 0:00 ` David Emery 1996-10-30 0:00 ` Robert Dewar 1996-10-30 0:00 ` Laurent Guerby 1996-11-02 0:00 ` Keith Thompson 1996-11-01 0:00 ` David Shochat 1996-11-02 0:00 ` Larry Kilgallen 1996-11-04 0:00 ` Michael F Brenner 1996-11-04 0:00 ` Larry Kilgallen 1996-11-12 0:00 ` Robert Dewar 1996-11-13 0:00 ` Norman H. Cohen 1996-11-14 0:00 ` Standard libraries (Was: Environment variables) Geert Bosch 1996-11-14 0:00 ` Robert Dewar 1996-11-16 0:00 ` Geert Bosch 1996-11-16 0:00 ` Robert Dewar 1996-11-17 0:00 ` Geert Bosch 1996-11-18 0:00 ` Larry Kilgallen 1996-11-01 0:00 ` Environment variables Laurent Guerby 1996-11-02 0:00 ` Robert A Duff 1996-11-02 0:00 ` Robert Dewar 1996-11-01 0:00 ` Stephen Leake 1996-11-02 0:00 ` Robert Dewar 1996-11-03 0:00 ` Robert A Duff 1996-11-03 0:00 ` Robert Dewar 1996-11-04 0:00 ` Stephen Leake 1996-11-04 0:00 ` Larry Kilgallen 1996-11-04 0:00 ` Robert Dewar 1996-11-04 0:00 ` Tucker Taft 1996-11-01 0:00 ` Norman H. Cohen 1996-11-05 0:00 ` David Emery 1996-10-31 0:00 ` James Rogers 1996-10-31 0:00 ` Robert I. Eachus 1996-10-31 0:00 ` Doug Smith 1996-11-03 0:00 ` Matthew Heaney 1996-10-31 0:00 ` Norman H. Cohen 1996-11-06 0:00 ` David Wheeler 1996-11-08 0:00 ` Christopher J Arnold 1996-11-09 0:00 ` Robert Dewar -- strict thread matches above, loose matches on Subject: below -- 1997-01-21 0:00 Environment Variables John M. Greer 1997-01-24 0:00 ` Mike Bishop 1997-01-24 0:00 ` Matthew Heaney 1997-01-25 0:00 ` Robert Dewar 1997-01-25 0:00 ` Doug Smith 1997-01-27 0:00 ` David Emery
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox