zsh-workers
 help / color / mirror / code / Atom feed
From: "Bart Schaefer" <schaefer@candle.brasslantern.com>
To: Adam Spiers <adam@spiers.net>,
	zsh workers mailing list <zsh-workers@sunsite.auc.dk>
Subject: Re: adding a toplevel zsh.spec.in file
Date: Mon, 17 Jul 2000 17:48:53 +0000	[thread overview]
Message-ID: <1000717174853.ZM22633@candle.brasslantern.com> (raw)
In-Reply-To: <20000717160933.B6739@thelonious.new.ox.ac.uk>

On Jul 17,  4:09pm, Adam Spiers wrote:
} Subject: Re: adding a toplevel zsh.spec.in file
}
} In /etc/zshenv:
} 
} What about setting of umask?  In the last discussion about this kind
} of stuff you suggested that umask setting was better done in zshrc.
} But shouldn't it be set correctly for non-interactive processes too?

I suggested that zshrc was better than zprofile (and that it should
be in only one or the other, and not both as it was).  Neither of those
catches non-interactive processes, so I wasn't addressing that at all.

In the case of RedHat's umask setting, which involves executing $(id -gn)
and several other tests, I'd say that avoiding the startup overhead is
more important for non-interactive shells.  If it's really a problem for
some reason, set umask conservatively in zshenv and then do the tests in
zshrc to relax the umask if appropriate.

} These don't do much harm either (quoted mostly straight from Bart
} anyway ;-)
} 
}   export USER=`id -un`
}   export LOGNAME=$USER
}   export HOSTNAME=$HOST
}   
}   # this only on appropriate boxes of course
}   export MAIL=/var/spool/mail/$USER

I agree that these don't do much harm, but this is bad:

}   HISTSIZE=1000
}   HISTFILE=~/.zshhistory
}   SAVEHIST=1000

Please don't mess with the shape of my history or the location of any of
my dotfiles.

} Is there any good reason why /sbin and /usr/sbin should not be on
} every user's path by default?  They're not under RedHat, which is
} infuriating when it comes to using traceroute, lsof etc.

Some system administrators believe in hiding system administration commands
from users who are not system administrators.  I don't care one way or the
other.

} Now here's a candidate for StartupFiles/RedHat/zshrc.  Anything badly
} wrong?

Yes.  Don't screw with my fpath and don't autoload functions for me.  I
very carefully set fpath and autoload functions in stages so that some
functions are available in non-interactive shells, and I don't use the
execute bit to mean anything nor should I be required to do so.  Your
assumptions about where under my home directory there might be functions
are wrong, and if your RPM is built correctly there shouldn't be anything
useful in /usr/doc/zsh*/Functions -- the only things that could be there
are leftovers from some 3.0.x-y RPM, which you don't want to pick up.

I won't call the aliases "badly" wrong, but I object to them anyway, and
I'd just as soon not have all that crap in my prompt, thanks.  Which I
guess means I think /etc/zshrc should be empty (except maybe for umask
as discussed above).

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

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   


  reply	other threads:[~2000-07-17 17:49 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2000-07-07 11:53 Adam Spiers
2000-07-07 12:45 ` Peter Stephenson
2000-07-07 16:15 ` Chmouel Boudjnah
2000-07-17 14:56   ` Adam Spiers
2000-07-07 17:18 ` Bart Schaefer
2000-07-07 17:44   ` Zefram
2000-07-07 18:18     ` Bart Schaefer
2000-07-17 15:09       ` Adam Spiers
2000-07-17 17:48         ` Bart Schaefer [this message]
2000-07-17 18:07           ` Adam Spiers
2000-07-17 21:05             ` Oliver Kiddle
2000-07-17 23:35               ` Adam Spiers
2000-07-18  2:32                 ` Trond Eivind Glomsrød
2000-07-18  6:01                 ` Bart Schaefer
2000-07-18  1:56         ` PATCH: " Zefram
2000-07-18  5:22           ` Bart Schaefer
2000-07-18  6:15             ` Wayne Davison
2000-07-18  8:31               ` How to distribute skeleton zshrc etc. (Re: PATCH: Re: adding a toplevel zsh.spec.in file) Bart Schaefer
2000-07-18 16:54             ` PATCH: Re: adding a toplevel zsh.spec.in file Trond Eivind Glomsrød
2000-07-18  6:25           ` Andrej Borsenkow
2000-07-18  9:42           ` Peter Stephenson
2000-07-18 18:22           ` Trond Eivind Glomsrød
2000-07-18 19:57             ` Zefram
2000-07-18 20:07               ` Trond Eivind Glomsrød
2000-07-18 20:37                 ` Zefram

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1000717174853.ZM22633@candle.brasslantern.com \
    --to=schaefer@candle.brasslantern.com \
    --cc=adam@spiers.net \
    --cc=zsh-workers@sunsite.auc.dk \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).