Return to BSD News archive
Path: euryale.cc.adfa.oz.au!newshost.anu.edu.au!harbinger.cc.monash.edu.au!bunyip.cc.uq.oz.au!munnari.OZ.AU!news.hawaii.edu!ames!agate!news.ossi.com!pagesat.net!jolt.pagesat.net!news
From: "Roy A. Gilmore" <royg@pinsight.com>
Newsgroups: comp.unix.bsd.freebsd.misc
Subject: Re: /bin/sh isn't Bourne shell
Date: Tue, 06 Feb 1996 17:05:11 -0800
Organization: RAGged Software
Lines: 68
Distribution: world
Message-ID: <3117FAC7.1742@pinsight.com>
References: <4ekrik$rlf@eccles.dsbc.icl.co.uk> <4enl74$ifr@eccles.dsbc.icl.co.uk> <3111D553.39F4@pinsight.com> <4ets1o$rvu@nntp5.u.washington.edu> <4f5rv3$5jm@madeline.INS.CWRU.Edu>
NNTP-Posting-Host: 165.90.156.118
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
X-Mailer: Mozilla 2.0b6a (Win16; I)
Chet Ramey wrote:
>
> In article <4ets1o$rvu@nntp5.u.washington.edu>,
> William R. Somsky <somsky@dirac.phys.washington.edu> wrote:
> >Various people have been writing on the new, POSIX-ly correct /bin/sh
> >variances from the traditional sh behavior. Esp. in regards to $ENV and
> >aliases mangling the behavior of scripts such as MAKEDEV.
> >
> >What it sounds like is that with the addition of $ENV, sh needs a
> >command flag, similar to csh's '-f' flag, which would cause it to
> >ignore $ENV and _not_ source any special shell-initialization files.
>
> Not really. What's needed is to specify that $ENV is expanded and sourced
> only for interactive shells. (The times when interactive and
> non-interactive shells are started are fairly well nailed down, though
> POSIX.2 does not specify them very clearly.)
>
> The latest draft of POSIX 1003.2 that I have (1003.2b/D11 of May, 1995)
> specifes that $ENV is expanded and sourced only for interactive shells.
> It appears that the POSIX.2 committee has recognized the problem. Of
> course, the rationale says
>
> ``This standard does not define when noninteractive shells are
> invoked; therefore the behavior of and ENV file processed is
> unpredictable. The processing of the ENV file could have side
> effects that can be accounted for by a script writer.''
>
> --
> ``The lyf so short, the craft so long to lerne.'' - Chaucer
>
> Chet Ramey, Case Western Reserve University Internet: chet@po.CWRU.Edu
Chet,
One more time (not you specifically, just this thread). It doesn't REALLY
matter if the $ENV file is sourced for non-interactive shells (i.e.
'scripts'). The 'i' option flag is set on interactive shells. All you have
to do is conditionally include commands in your $ENV file based on the 'i'
option flag like this:
case $- in *i*)
# commands for interactive use only
...
esac
This is straight out of the sh(1) man page. You could bracket your entire
$ENV file like this; which, in effect, would not source your $ENV file for
non-interactive shells.
Now, time for a little soapbox ranting. Since few (if ANY) versions of
UN*X are 100% POSIX compliant, the POSIX standards mean very little.
Standardization is good. But, until EVERYONE complies, it's useless.
The reality is: REAL people have to use REAL OS's to do REAL work. If
that means finding 'work-arounds' to get around their OS's idiosyncrasies,
so be it.
Just my two cents,
RAG
/////////////////////////////////
// Roy A. Gilmore //
// //
// Internet: royg@pinsight.com //
// CompuServe: 72263,3075 //
// America Online: RAGged Roy //
// Prodigy: SMDR01B //
/////////////////////////////////