Path: utzoo!utgpu!water!watmath!clyde!att!alberta!ubc-cs!uw-beaver!cornell!mailrus!purdue!decwrl!labrea!denali!karish
From: karish@denali.stanford.edu (Chuck Karish)
Newsgroups: comp.unix.questions
Subject: Re: setenv/putenv/unsetenv.
Message-ID: <23385@labrea.Stanford.EDU>
Date: 28 Aug 88 20:09:11 GMT
References: <2969@zyx.ZYX.SE> <47800015@uxe.cso.uiuc.edu>
Sender: news@labrea.Stanford.EDU
Reply-To: karish@denali.stanford.edu (Chuck Karish)
Organization: Mindcraft, Inc.
Lines: 50

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