Zsh Mailing List Archive
Messages sorted by:
Re: ideas, questions, and bugs (?)
- X-seq: zsh-users 1081
- From: TGAPE! <tgape@xxxxxxxxxxxxx>
- To: Tim.Writer@xxxxxxxxxx (Tim Writer)
- Subject: Re: ideas, questions, and bugs (?)
- Date: Sat, 11 Oct 1997 00:08:04 +0000 (GMT)
- Approved: Just in case a router decides to do so anyway.
- Cc: tgape@xxxxxxxxxxxxxxxxxxxxxxxxx, zefram@xxxxxxxxx, quinn@xxxxxxxxxxxxxxxxxxxxx, zsh-users@xxxxxxxxxxxxxxx
- In-reply-to: <m3d8lehl9b.fsf@xxxxxxxxxxxxxxxxx> from "Tim Writer" at Oct 9, 97 01:57:52 pm
Tim Writer wrote:
> TGAPE! <tgape@xxxxxxxxxxxxxxxxxxxxxxxxx> 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
>> 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.
Messages sorted by: