From mboxrd@z Thu Jan  1 00:00:00 1970
From: "Bart Schaefer" <schaefer@brasslantern.com>
Message-Id: <990205002814.ZM21584@candle.brasslantern.com>
Date: Fri, 5 Feb 1999 00:28:14 -0800
To: "Zsh users list" <zsh-users@sunsite.auc.dk>
Subject: Re: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-Mailing-List: <zsh-users@sunsite.auc.dk> 2100

On Feb 5,  9:40am, Andrej Borsenkow wrote:
} Subject: RE: Problem w/ ulimit killing compiles on sol 2.4&2.6 ...
}
} >
} >   The only file you can alter which is started with every zsh (unless
} >   you use the -f option) is .zshenv, so this is a good place to
} >   put things you want even if the shell is non-interactive: options for
} >   changing the the syntax, like EXTENDED_GLOB,
} 
} I totally disagree. Anybody doing this will inevitably end up writing
} nonportable zsh scripts, that, when used on other system(s), will not work
} in the best or will have unpredictable side effects in the worst case.

We've had some discussions before about options that change the syntax,
IIRC in the context of which options could be "on" by default to better
showcase the multitude of zsh's talents.  It was concluded that the only
safe options to play with were the ones that changed purely interactive
features, like completion.

Quite obviously system administrators should be strongly discouraged from
using options that change the shell syntax in *any* of the global init
files, without extremely good reason.  An example of such a good reason:
using CSH_JUNKIE_PAREN in global files for zsh 2.5, when an incompatible
syntax change was introduced in the shell itself, which broke everyone's
personal init files.  (That option is now gone and the syntax restored.)

However, given that options to change the syntax exist at all, I can't
find fault with whichever of a users *personal* init files contain those
options.  Most users are going to write scripts and shell functions using
commands that work in their own interactive environment, and then will
expect them to work the same way in non-interactive shells started with
e.g. "rsh host command".  The only way to assure that this works is to
put the necessary settings in .zshenv.

"Writing nonportable zsh scripts" is a complete red herring.  The only way 
to write a portable zsh script is to begin the script with

    emulate -R zsh
    setopt ...		# whatever options the script needs, if any

If those lines are missing, the script is going to break eventually.  If
they're present, the script is immune to options set in the init files.
That's why the "emulate zsh" command was added in the first place.

Of course, you could still get messed up by aliases or functions that have
the same names as utilities, or named directory hashing, or a bogus $path.  
That's what you get for using an interpreted language.  The paranoid may
begin all scripts with

	#!/bin/sh

Then even /etc/zshenv won't be sourced.

} Scripts should _not_ depend on particular option(s) preset or, for
} that matter, on particular function(s) being available.

This is an excellent rule when writing scripts for public consumption.
It's unrealistic to apply it to an average user writing scripts for his
own convenience.  (Heck, even /etc/rc.d/init.d/* depend on being having
certain variables set and on using functions that are loaded by `.'-ing
other files.)  Perhaps, however, the FAQ should make a stronger point
that there are possible unintended side-effects of using .zshenv.

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com