Re: ideas, questions, and bugs (?)

[TGAPE! <tgape@xxxxxxxxxxxxx>]

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
>>>> 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