From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22816 invoked from network); 11 Oct 1997 18:29:59 -0000 Received: from math.gatech.edu (list@130.207.146.50) by ns1.primenet.com.au with SMTP; 11 Oct 1997 18:29:59 -0000 Received: (from list@localhost) by math.gatech.edu (8.8.5/8.8.5) id OAA11188; Sat, 11 Oct 1997 14:19:34 -0400 (EDT) Resent-Date: Sat, 11 Oct 1997 14:18:24 -0400 (EDT) From: TGAPE! Message-Id: <199710110008.AAA00577@dal-tsa5-1.cyberramp.net> Subject: Re: ideas, questions, and bugs (?) To: Tim.Writer@ftlsol.com (Tim Writer) Date: Sat, 11 Oct 1997 00:08:04 +0000 (GMT) Cc: tgape@dal-tsa6-26.cyberramp.net, zefram@tao.co.uk, quinn@envy.ugcs.caltech.edu, zsh-users@math.gatech.edu In-Reply-To: from "Tim Writer" at Oct 9, 97 01:57:52 pm X-Mailer: ELM [version 2.4 PL25] MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Resent-Message-ID: <"Ru1cY3.0.Tj2.mByFq"@math> Resent-From: zsh-users@math.gatech.edu X-Mailing-List: archive/latest/1081 X-Loop: zsh-users@math.gatech.edu X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Tim Writer wrote: > TGAPE! writes: > >>>> Also, is it better to stick vars in zlogin and export them so future >>>> shells inherit them, or put things like PATH, MANPATH, HOSTNAME, etc. in >>>> zshenv? >> >> Be sensible. EDITOR, HISTFILE, HISTSIZE, LESS, PAGER, VISUAL, and other >> such environment variables shouldn't be in zshenv - they can only be >> used in interactive shells. Of course, setting every environment > > Do you mean they belong in .zlogin? In my experience, this doesn't work very No, .zshrc is for interactive shells, according to the manpage. I haven't actually tested to make sure it's not run for scripts, but I cannot recall having seen its contens when I've run a script -x. Strangely, this removes almost all use for .profile... > well in a networked environment, consider: > > rsh thathost xterm -display thishost:0.0 Consider 'rsh therehost elm' - game over, man, game over. > The shell running inside xterm is interactive, but it's not a login shell, so > it won't have EDITOR, HISTFILE, etc. which is probably not what you want. Of > course, you can use "xterm -ls", but not everybody uses xterm and terminal > emulators such as shelltool don't have a similar option. Terminal emulators such as shelltool are broken, in many varied ways. If you use shelltool, you might as well have a broken /etc/zshenv, let alone one which is merely not obsessively optimized. Shoot, you might as well go whole-hog and use vile as your text editor, or maybe ed. I can't remember all the problems I've had using shelltool, but lately, since we've gotten the new people, I seem to recall saying, "I never figured out how to get around that problem in shelltool" a rather lot. I'll stop here before some router decides that I *really* meant to send this to alt.sysadmin.recovery, and redirects it for me. Sorry for interrupting your discussion with this unscheduled rant. >> variable I set takes less than a second; it doesn't hurt *that* much >> unless you have a *lot* of shell scripts that read /etc/zshenv. > > I agree with this. In practice, I find it's easier to put all this stuff in > /etc/zshenv or ~/.zshenv and leave ~/.zlogin for things that are *strictly* > part of logging in, starting X for example. Ugh. To each their own. (Though, admittedly, you're already thrice damned for using SunOS...) I maybe should point out that, while I once had a full /etc/zlogin, pretty much everything which was once there has moved to either ~/.z/.zlogin, ~/.z/.zprofile, or /etc/zprofile... >> (I do - my zshenv contains all of my setopts in it, and most zsh scripts >> want them.) >> >> Question: would it be possible to avoid this whole problem by re-writing >> /sbin/init as a zsh script? That way, it can export all of the variables, >> and so you don't need to worry about cron-executed programs having a >> different environment. > > What about environment variables set in ~/.zshenv? Why not just put "zsh -l" > in your crontab? Actually, my crontab doesn't appear to have any environment variable (or shell variable for that matter) referenced in it at all. Something *must* be wrong here. Ok, who am I, and where's the real Ed? Ah. Found them; they were hidden away in a script called by a script. But, the script set them before using them. I still want to know what I did with the real Ed. Ed