arndt@ZYX.SE (Arndt Jonasson) (08/21/88)
Does anyone have a PD implementation of C functions to manipulate a program's environment? The operations that should be supported are: Function Already exists getenv in libc.a library in System V and BSD. setenv in libc.a in System V under the name 'putenv'. unsetenv in neither System V nor BSD. I am probably going to write these myself, but it would be nice if they already existed somewhere. Does Posix include these? -- Arndt Jonasson, ZYX Sweden AB, Styrmansgatan 6, 114 54 Stockholm, Sweden email address: arndt@zyx.SE or <backbone>!mcvax!enea!zyx!arndt
karish@denali.stanford.edu (Chuck Karish) (08/22/88)
In article <2969@zyx.ZYX.SE> arndt@zyx.SE (Arndt Jonasson) writes: > >Does anyone have a PD implementation of C functions to manipulate a >program's environment? The operations that should be supported are: [ getenv(), setenv(), unsetenv() ] >Does Posix include these? As of Draft 12.3, the POSIX 1003.1 standard includes only getenv(). It's pretty simple to write the others; all you have to do is to change the contents of the strings pointed to by the `environ' pointers. This may entail using realloc() where strings get longer, and re- assigning pointers to pointers (unsetenv()). Chuck Karish ARPA: karish@denali.stanford.edu BITNET: karish%denali@forsythe.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041
jr@oglvee.UUCP (Jim Rosenberg) (08/25/88)
From article <23335@labrea.Stanford.EDU>, by karish@denali.stanford.edu (Chuck Karish): > As of Draft 12.3, the POSIX 1003.1 standard includes only getenv(). > It's pretty simple to write the others; all you have to do is to ^^^^ ^^^^^^ ^^^^^^ ^^ ^^^^^ ^^^ ^^^^^^ > change the contents of the strings pointed to by the `environ' pointers. > This may entail using realloc() where strings get longer, and re- > assigning pointers to pointers (unsetenv()). OPINION ON: Sure it's simple, but that's not the point. The environment is something pretty basic. Isn't it about time we started dealing with as many such basic things as possible through a layer of primitives?? It is quite surprising how many vendors of quite diverse operating systems are either talking about or actually promising POSIX compatibility, even though the underlying kernels don't look even vaguely like UNIX. (VMS, OS/2, ...) What are these people supposed to do? If the primitive to set an environment variable isn't in the standard then you will get just the kind of problems with variant versions and portability troubles that the standard is supposed to prevent. -- Jim Rosenberg pitt Oglevee Computer Systems >--!amanue!oglvee!jr 151 Oglevee Lane cgh Connellsville, PA 15425 #include <disclaimer.h>
mcdonald@uxe.cso.uiuc.edu (08/27/88)
>Sure it's simple, but that's not the point. The environment is something >pretty basic. Isn't it about time we started dealing with as many such basic >things as possible through a layer of primitives?? It is quite surprising how >many vendors of quite diverse operating systems are either talking about or >actually promising POSIX compatibility, even though the underlying kernels >don't look even vaguely like UNIX. (VMS, OS/2, ...) What are these people >supposed to do? If the primitive to set an environment variable isn't in the >standard then you will get just the kind of problems with variant versions and >portability troubles that the standard is supposed to prevent. - POSIX and similar standards are not intended as definition of a useable system. They are intended for such purposes as allowing the government to specify an operating system in a procurement spec without generating lawsuits. Real operating systems will always need lots of extensions .
karish@denali.stanford.edu (Chuck Karish) (08/29/88)
In article <47800015@uxe.cso.uiuc.edu> mcdonald@uxe.cso.uiuc.edu writes: > [ Answering my explanation of how to implement setenv() and unsetenv(), [citation lost] wrote: ] >>Sure it's simple, but that's not the point. The environment is something >>pretty basic. Isn't it about time we started dealing with as many such basic >>things as possible through a layer of primitives?? It is quite surprising how >>many vendors of quite diverse operating systems are either talking about or >>actually promising POSIX compatibility, even though the underlying kernels >>don't look even vaguely like UNIX. (VMS, OS/2, ...) What are these people >>supposed to do? If the primitive to set an environment variable isn't in the >>standard then you will get just the kind of problems with variant versions and >>portability troubles that the standard is supposed to prevent. The 1003.1 standard says that the environment is stored in an array of character pointers, with a NULL pointer to mark the end of the array. Each member of the array is of the form "tag=value". The amount of memory available for combined environment and command-line arguments is given as a constant that's available from the OS. Isn't this sufficiently explicit that you can write portable code? I'll grant that implementations may differ in their interfaces to provide the setenv()/unsetenv() functionality, but if you're worried about this, you can write completely portable versions of your own, and use them anywhere. >POSIX and similar standards are not intended as definition of a useable >system. They are intended for such purposes as allowing the government >to specify an operating system in a procurement spec without >generating lawsuits. Real operating systems will always need lots >of extensions . The second sentence describes the POSIX FIPS (Federal Information Processing Standard) better than it does POSIX. The FIPS is, however, intended to describe a complete, usable operating system. If you think that it's likely to be deficient in this, it may be worthwhile to express your concerns to the people at the National Bureau of Standards who are responsible for deveoping the FIPS. Each POSIX standard is meant to provide a concise description of a portable subset of an operating system. The implementor still has the responsibility to provide the hardware and software environment (processor, memory, device drivers, a file system, maintenance programs) that's needed to support the portable features. I assume that setenv() and unsetenv() were left out on the grounds of conciseness, not because of inherent portability considerations. Chuck Karish ARPA: karish@denali.stanford.edu UUCP: {decvax,hplabs!hpda}!mindcrf!karish USPS: 1825 California St. #5 Mountain View, CA 94041